* [PATCH net-next 5/9] bonding: make ad_agg_selection_logic() use bond_for_each_slave()
From: Veaceslav Falico @ 2013-09-27 14:12 UTC (permalink / raw)
To: netdev; +Cc: nikolay, bhutchings, Veaceslav Falico, Jay Vosburgh,
Andy Gospodarek
In-Reply-To: <1380291125-5671-1-git-send-email-vfalico@redhat.com>
Convert all instances of
for (agg = __get_first_agg(); agg; agg = __get_next_port)
to the standard bond_for_each_slave(). Also, remove the useless checks
before calling bond_3ad_set_carrier() - if we have something NULL - it
would fire long ago, in __get_first/next_port(), per example.
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
---
drivers/net/bonding/bond_3ad.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index 1109d82..6cd1444 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -1484,19 +1484,23 @@ static int agg_device_up(const struct aggregator *agg)
static void ad_agg_selection_logic(struct aggregator *agg)
{
struct aggregator *best, *active, *origin;
+ struct bonding *bond = agg->slave->bond;
+ struct list_head *iter;
+ struct slave *slave;
struct port *port;
origin = agg;
active = __get_active_agg(agg);
best = (active && agg_device_up(active)) ? active : NULL;
- do {
+ bond_for_each_slave(bond, slave, iter) {
+ agg = &(SLAVE_AD_INFO(slave).aggregator);
+
agg->is_active = 0;
if (agg->num_of_ports && agg_device_up(agg))
best = ad_agg_selection_test(best, agg);
-
- } while ((agg = __get_next_agg(agg)));
+ }
if (best &&
__get_agg_selection_mode(best->lag_ports) == BOND_AD_STABLE) {
@@ -1534,8 +1538,8 @@ static void ad_agg_selection_logic(struct aggregator *agg)
best->lag_ports, best->slave,
best->slave ? best->slave->dev->name : "NULL");
- for (agg = __get_first_agg(best->lag_ports); agg;
- agg = __get_next_agg(agg)) {
+ bond_for_each_slave(bond, slave, iter) {
+ agg = &(SLAVE_AD_INFO(slave).aggregator);
pr_debug("Agg=%d; P=%d; a k=%d; p k=%d; Ind=%d; Act=%d\n",
agg->aggregator_identifier, agg->num_of_ports,
@@ -1583,13 +1587,7 @@ static void ad_agg_selection_logic(struct aggregator *agg)
}
}
- if (origin->slave) {
- struct bonding *bond;
-
- bond = bond_get_bond_by_slave(origin->slave);
- if (bond)
- bond_3ad_set_carrier(bond);
- }
+ bond_3ad_set_carrier(bond);
}
/**
--
1.8.4
^ permalink raw reply related
* [PATCH net-next 7/9] bonding: remove unused __get_next_agg()
From: Veaceslav Falico @ 2013-09-27 14:12 UTC (permalink / raw)
To: netdev; +Cc: nikolay, bhutchings, Veaceslav Falico, Jay Vosburgh,
Andy Gospodarek
In-Reply-To: <1380291125-5671-1-git-send-email-vfalico@redhat.com>
It has no users, so it's safe to remove it completely.
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
---
drivers/net/bonding/bond_3ad.c | 22 ----------------------
1 file changed, 22 deletions(-)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index 6dbb84d..c62606a 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -155,28 +155,6 @@ static inline struct aggregator *__get_first_agg(struct port *port)
return first_slave ? &(SLAVE_AD_INFO(first_slave).aggregator) : NULL;
}
-/**
- * __get_next_agg - get the next aggregator in the bond
- * @aggregator: the aggregator we're looking at
- *
- * Return the aggregator of the slave that is next in line of @aggregator's
- * slave in the bond, or %NULL if it can't be found.
- */
-static inline struct aggregator *__get_next_agg(struct aggregator *aggregator)
-{
- struct slave *slave = aggregator->slave, *slave_next;
- struct bonding *bond = bond_get_bond_by_slave(slave);
-
- // If there's no bond for this aggregator, or this is the last slave
- if (bond == NULL)
- return NULL;
- slave_next = bond_next_slave(bond, slave);
- if (!slave_next || bond_is_first_slave(bond, slave_next))
- return NULL;
-
- return &(SLAVE_AD_INFO(slave_next).aggregator);
-}
-
/*
* __agg_has_partner
*
--
1.8.4
^ permalink raw reply related
* [PATCH net-next 6/9] bonding: make bond_3ad_unbind_slave() use bond_for_each_slave()
From: Veaceslav Falico @ 2013-09-27 14:12 UTC (permalink / raw)
To: netdev; +Cc: nikolay, bhutchings, Veaceslav Falico, Jay Vosburgh,
Andy Gospodarek
In-Reply-To: <1380291125-5671-1-git-send-email-vfalico@redhat.com>
Convert all instances of
for (agg = __get_first_agg(); agg; agg = __get_next_port)
to the standard bond_for_each_slave().
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
---
drivers/net/bonding/bond_3ad.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index 6cd1444..6dbb84d 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -1936,6 +1936,9 @@ void bond_3ad_unbind_slave(struct slave *slave)
struct port *port, *prev_port, *temp_port;
struct aggregator *aggregator, *new_aggregator, *temp_aggregator;
int select_new_active_agg = 0;
+ struct bonding *bond = slave->bond;
+ struct slave *slave_iter;
+ struct list_head *iter;
// find the aggregator related to this slave
aggregator = &(SLAVE_AD_INFO(slave).aggregator);
@@ -1965,14 +1968,16 @@ void bond_3ad_unbind_slave(struct slave *slave)
// reason to search for new aggregator, and that we will find one
if ((aggregator->lag_ports != port) || (aggregator->lag_ports->next_port_in_aggregator)) {
// find new aggregator for the related port(s)
- new_aggregator = __get_first_agg(port);
- for (; new_aggregator; new_aggregator = __get_next_agg(new_aggregator)) {
+ bond_for_each_slave(bond, slave_iter, iter) {
+ new_aggregator = &(SLAVE_AD_INFO(slave_iter).aggregator);
// if the new aggregator is empty, or it is connected to our port only
if (!new_aggregator->lag_ports
|| ((new_aggregator->lag_ports == port)
&& !new_aggregator->lag_ports->next_port_in_aggregator))
break;
}
+ if (!slave_iter)
+ new_aggregator = NULL;
// if new aggregator found, copy the aggregator's parameters
// and connect the related lag_ports to the new aggregator
if ((new_aggregator) && ((!new_aggregator->lag_ports) || ((new_aggregator->lag_ports == port) && !new_aggregator->lag_ports->next_port_in_aggregator))) {
@@ -2032,8 +2037,8 @@ void bond_3ad_unbind_slave(struct slave *slave)
pr_debug("Unbinding port %d\n", port->actor_port_number);
// find the aggregator that this port is connected to
- temp_aggregator = __get_first_agg(port);
- for (; temp_aggregator; temp_aggregator = __get_next_agg(temp_aggregator)) {
+ bond_for_each_slave(bond, slave_iter, iter) {
+ temp_aggregator = &(SLAVE_AD_INFO(slave_iter).aggregator);
prev_port = NULL;
// search the port in the aggregator's related ports
for (temp_port = temp_aggregator->lag_ports; temp_port;
--
1.8.4
^ permalink raw reply related
* [PATCH net-next 8/9] bonding: don't use bond_next_slave() in bond_info_seq_next()
From: Veaceslav Falico @ 2013-09-27 14:12 UTC (permalink / raw)
To: netdev; +Cc: nikolay, bhutchings, Veaceslav Falico, Jay Vosburgh,
Andy Gospodarek
In-Reply-To: <1380291125-5671-1-git-send-email-vfalico@redhat.com>
We don't need the circular loop there and it's the only current user of
bond_next_slave() - so just use the standard bond_for_each_slave().
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
---
drivers/net/bonding/bond_procfs.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/bonding/bond_procfs.c b/drivers/net/bonding/bond_procfs.c
index 7af5646..fb868d6 100644
--- a/drivers/net/bonding/bond_procfs.c
+++ b/drivers/net/bonding/bond_procfs.c
@@ -31,17 +31,25 @@ static void *bond_info_seq_start(struct seq_file *seq, loff_t *pos)
static void *bond_info_seq_next(struct seq_file *seq, void *v, loff_t *pos)
{
struct bonding *bond = seq->private;
- struct slave *slave = v;
+ struct list_head *iter;
+ struct slave *slave;
+ bool found = false;
++*pos;
if (v == SEQ_START_TOKEN)
return bond_first_slave(bond);
- if (bond_is_last_slave(bond, slave))
+ if (bond_is_last_slave(bond, v))
return NULL;
- slave = bond_next_slave(bond, slave);
- return slave;
+ bond_for_each_slave(bond, slave, iter) {
+ if (found)
+ return slave;
+ if (slave == v)
+ found = true;
+ }
+
+ return NULL;
}
static void bond_info_seq_stop(struct seq_file *seq, void *v)
--
1.8.4
^ permalink raw reply related
* [PATCH net-next 9/9] bonding: remove bond_next_slave()
From: Veaceslav Falico @ 2013-09-27 14:12 UTC (permalink / raw)
To: netdev; +Cc: nikolay, bhutchings, Veaceslav Falico, Jay Vosburgh,
Andy Gospodarek
In-Reply-To: <1380291125-5671-1-git-send-email-vfalico@redhat.com>
There are no users left, so it's safe to remove.
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
---
drivers/net/bonding/bonding.h | 31 -------------------------------
1 file changed, 31 deletions(-)
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 5b71601..713b6af 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -89,9 +89,6 @@
#define bond_is_first_slave(bond, pos) (pos == bond_first_slave(bond))
#define bond_is_last_slave(bond, pos) (pos == bond_last_slave(bond))
-/* Since bond_first/last_slave can return NULL, these can return NULL too */
-#define bond_next_slave(bond, pos) __bond_next_slave(bond, pos)
-
/**
* bond_for_each_slave - iterate over all slaves
* @bond: the bond holding this list
@@ -244,34 +241,6 @@ struct bonding {
((struct slave *) rtnl_dereference(dev->rx_handler_data))
/**
- * __bond_next_slave - get the next slave after the one provided
- * @bond - bonding struct
- * @slave - the slave provided
- *
- * Returns the next slave after the slave provided, first slave if the
- * slave provided is the last slave and NULL if slave is not found
- */
-static inline struct slave *__bond_next_slave(struct bonding *bond,
- struct slave *slave)
-{
- struct slave *slave_iter;
- struct list_head *iter;
- bool found = false;
-
- netdev_for_each_lower_private(bond->dev, slave_iter, iter) {
- if (found)
- return slave_iter;
- if (slave_iter == slave)
- found = true;
- }
-
- if (found)
- return bond_first_slave(bond);
-
- return NULL;
-}
-
-/**
* Returns NULL if the net_device does not belong to any of the bond's slaves
*
* Caller must hold bond lock for read
--
1.8.4
^ permalink raw reply related
* Re: [PATCH net-next] virtio-net: switch to use XPS to choose txq
From: Michael S. Tsirkin @ 2013-09-27 14:35 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <1380261444-40918-1-git-send-email-jasowang@redhat.com>
On Fri, Sep 27, 2013 at 01:57:24PM +0800, Jason Wang wrote:
> We used to use a percpu structure vq_index to record the cpu to queue
> mapping, this is suboptimal since it duplicates the work of XPS and
> loses all other XPS functionality such as allowing use to configure
> their own transmission steering strategy.
>
> So this patch switches to use XPS and suggest a default mapping when
> the number of cpus is equal to the number of queues. With XPS support,
> there's no need for keeping per-cpu vq_index and .ndo_select_queue(),
> so they were removed also.
>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
More lines deleted that added is good :)
But how does the result perform?
About the same?
> ---
> drivers/net/virtio_net.c | 55 +++++++--------------------------------------
> 1 files changed, 9 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index defec2b..4102c1b 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -127,9 +127,6 @@ struct virtnet_info {
> /* Does the affinity hint is set for virtqueues? */
> bool affinity_hint_set;
>
> - /* Per-cpu variable to show the mapping from CPU to virtqueue */
> - int __percpu *vq_index;
> -
> /* CPU hot plug notifier */
> struct notifier_block nb;
> };
> @@ -1063,7 +1060,6 @@ static int virtnet_vlan_rx_kill_vid(struct net_device *dev,
> static void virtnet_clean_affinity(struct virtnet_info *vi, long hcpu)
> {
> int i;
> - int cpu;
>
> if (vi->affinity_hint_set) {
> for (i = 0; i < vi->max_queue_pairs; i++) {
> @@ -1073,20 +1069,11 @@ static void virtnet_clean_affinity(struct virtnet_info *vi, long hcpu)
>
> vi->affinity_hint_set = false;
> }
> -
> - i = 0;
> - for_each_online_cpu(cpu) {
> - if (cpu == hcpu) {
> - *per_cpu_ptr(vi->vq_index, cpu) = -1;
> - } else {
> - *per_cpu_ptr(vi->vq_index, cpu) =
> - ++i % vi->curr_queue_pairs;
> - }
> - }
> }
>
> static void virtnet_set_affinity(struct virtnet_info *vi)
> {
> + cpumask_var_t cpumask;
> int i;
> int cpu;
>
> @@ -1100,15 +1087,21 @@ static void virtnet_set_affinity(struct virtnet_info *vi)
> return;
> }
>
> + if (!alloc_cpumask_var(&cpumask, GFP_KERNEL))
> + return;
> +
> i = 0;
> for_each_online_cpu(cpu) {
> virtqueue_set_affinity(vi->rq[i].vq, cpu);
> virtqueue_set_affinity(vi->sq[i].vq, cpu);
> - *per_cpu_ptr(vi->vq_index, cpu) = i;
> + cpumask_clear(cpumask);
> + cpumask_set_cpu(cpu, cpumask);
> + netif_set_xps_queue(vi->dev, cpumask, i);
> i++;
> }
>
> vi->affinity_hint_set = true;
> + free_cpumask_var(cpumask);
> }
>
> static int virtnet_cpu_callback(struct notifier_block *nfb,
> @@ -1217,28 +1210,6 @@ static int virtnet_change_mtu(struct net_device *dev, int new_mtu)
> return 0;
> }
>
> -/* To avoid contending a lock hold by a vcpu who would exit to host, select the
> - * txq based on the processor id.
> - */
> -static u16 virtnet_select_queue(struct net_device *dev, struct sk_buff *skb)
> -{
> - int txq;
> - struct virtnet_info *vi = netdev_priv(dev);
> -
> - if (skb_rx_queue_recorded(skb)) {
> - txq = skb_get_rx_queue(skb);
> - } else {
> - txq = *__this_cpu_ptr(vi->vq_index);
> - if (txq == -1)
> - txq = 0;
> - }
> -
> - while (unlikely(txq >= dev->real_num_tx_queues))
> - txq -= dev->real_num_tx_queues;
> -
> - return txq;
> -}
> -
> static const struct net_device_ops virtnet_netdev = {
> .ndo_open = virtnet_open,
> .ndo_stop = virtnet_close,
> @@ -1250,7 +1221,6 @@ static const struct net_device_ops virtnet_netdev = {
> .ndo_get_stats64 = virtnet_stats,
> .ndo_vlan_rx_add_vid = virtnet_vlan_rx_add_vid,
> .ndo_vlan_rx_kill_vid = virtnet_vlan_rx_kill_vid,
> - .ndo_select_queue = virtnet_select_queue,
> #ifdef CONFIG_NET_POLL_CONTROLLER
> .ndo_poll_controller = virtnet_netpoll,
> #endif
> @@ -1559,10 +1529,6 @@ static int virtnet_probe(struct virtio_device *vdev)
> if (vi->stats == NULL)
> goto free;
>
> - vi->vq_index = alloc_percpu(int);
> - if (vi->vq_index == NULL)
> - goto free_stats;
> -
> mutex_init(&vi->config_lock);
> vi->config_enable = true;
> INIT_WORK(&vi->config_work, virtnet_config_changed_work);
> @@ -1589,7 +1555,7 @@ static int virtnet_probe(struct virtio_device *vdev)
> /* Allocate/initialize the rx/tx queues, and invoke find_vqs */
> err = init_vqs(vi);
> if (err)
> - goto free_index;
> + goto free_stats;
>
> netif_set_real_num_tx_queues(dev, 1);
> netif_set_real_num_rx_queues(dev, 1);
> @@ -1640,8 +1606,6 @@ free_recv_bufs:
> free_vqs:
> cancel_delayed_work_sync(&vi->refill);
> virtnet_del_vqs(vi);
> -free_index:
> - free_percpu(vi->vq_index);
> free_stats:
> free_percpu(vi->stats);
> free:
> @@ -1678,7 +1642,6 @@ static void virtnet_remove(struct virtio_device *vdev)
>
> flush_work(&vi->config_work);
>
> - free_percpu(vi->vq_index);
> free_percpu(vi->stats);
> free_netdev(vi->dev);
> }
> --
> 1.7.1
^ permalink raw reply
* RE: [PATCH net-next 2/9] bonding: remove __get_first_port()
From: David Laight @ 2013-09-27 14:50 UTC (permalink / raw)
To: Veaceslav Falico, netdev
Cc: nikolay, bhutchings, Jay Vosburgh, Andy Gospodarek
In-Reply-To: <1380291125-5671-3-git-send-email-vfalico@redhat.com>
> @@ -2104,8 +2091,11 @@ void bond_3ad_state_machine_handler(struct work_struct *work)
>
> // check if agg_select_timer timer after initialize is timed out
> if (BOND_AD_INFO(bond).agg_select_timer && !(--BOND_AD_INFO(bond).agg_select_timer)) {
> + slave = bond_first_slave(bond);
> + port = slave ? &(SLAVE_AD_INFO(slave).port) : NULL;
> +
> // select the active aggregator for the bond
> - if ((port = __get_first_port(bond))) {
> + if (port) {
> if (!port->slave) {
> pr_warning("%s: Warning: bond's first port is uninitialized\n",
> bond->dev->name);
> --
Looks like that could be:
slave = bond_first_slave(bond);
if (slave) {
port = SLAVE_AD_INFO(slave).port;
and I assume 'slave == port->slave' so there is no need for the latter check?
David
^ permalink raw reply
* Re: [PATCH net-next 2/9] bonding: remove __get_first_port()
From: Veaceslav Falico @ 2013-09-27 14:58 UTC (permalink / raw)
To: David Laight; +Cc: netdev, nikolay, bhutchings, Jay Vosburgh, Andy Gospodarek
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7365@saturn3.aculab.com>
On Fri, Sep 27, 2013 at 03:50:12PM +0100, David Laight wrote:
>> @@ -2104,8 +2091,11 @@ void bond_3ad_state_machine_handler(struct work_struct *work)
>>
>> // check if agg_select_timer timer after initialize is timed out
>> if (BOND_AD_INFO(bond).agg_select_timer && !(--BOND_AD_INFO(bond).agg_select_timer)) {
>> + slave = bond_first_slave(bond);
>> + port = slave ? &(SLAVE_AD_INFO(slave).port) : NULL;
>> +
>> // select the active aggregator for the bond
>> - if ((port = __get_first_port(bond))) {
>> + if (port) {
>> if (!port->slave) {
>> pr_warning("%s: Warning: bond's first port is uninitialized\n",
>> bond->dev->name);
>> --
>
>Looks like that could be:
> slave = bond_first_slave(bond);
> if (slave) {
> port = SLAVE_AD_INFO(slave).port;
>and I assume 'slave == port->slave' so there is no need for the latter check?
I've also fallen to this trap at first - slave->port can (virtually) be
NULL, and this way we'll panic on "if (!port->slave)".
>
> David
>
>
>
^ permalink raw reply
* Re: [PATCH net-next 2/9] bonding: remove __get_first_port()
From: Veaceslav Falico @ 2013-09-27 15:05 UTC (permalink / raw)
To: David Laight; +Cc: netdev, nikolay, bhutchings, Jay Vosburgh, Andy Gospodarek
In-Reply-To: <20130927145825.GA14139@redhat.com>
On Fri, Sep 27, 2013 at 04:58:25PM +0200, Veaceslav Falico wrote:
>On Fri, Sep 27, 2013 at 03:50:12PM +0100, David Laight wrote:
>>>@@ -2104,8 +2091,11 @@ void bond_3ad_state_machine_handler(struct work_struct *work)
>>>
>>> // check if agg_select_timer timer after initialize is timed out
>>> if (BOND_AD_INFO(bond).agg_select_timer && !(--BOND_AD_INFO(bond).agg_select_timer)) {
>>>+ slave = bond_first_slave(bond);
>>>+ port = slave ? &(SLAVE_AD_INFO(slave).port) : NULL;
>>>+
>>> // select the active aggregator for the bond
>>>- if ((port = __get_first_port(bond))) {
>>>+ if (port) {
>>> if (!port->slave) {
>>> pr_warning("%s: Warning: bond's first port is uninitialized\n",
>>> bond->dev->name);
>>>--
>>
>>Looks like that could be:
>> slave = bond_first_slave(bond);
>> if (slave) {
>> port = SLAVE_AD_INFO(slave).port;
>>and I assume 'slave == port->slave' so there is no need for the latter check?
>
>I've also fallen to this trap at first - slave->port can (virtually) be
>NULL, and this way we'll panic on "if (!port->slave)".
Err, forgot to address the 'slave == port->slave' - yes, virtually it
should be - if it's initialized (and, it should be) - however, as I've
stated in the cover letter - there are *tons* of cleanups/optimizations of
these kind that might be done here - and not to mix cleanups/optimizations
with the thing that these patches should do (remove bond_next_slave) - I've
decided to leave it as close to the original as possible.
>
>>
>> David
>>
>>
>>
^ permalink raw reply
* Re: [PATCH] tcp: TSQ can use a dynamic limit
From: Neal Cardwell @ 2013-09-27 15:08 UTC (permalink / raw)
To: Eric Dumazet
Cc: Cong Wang, David Miller, Wei Liu, Linux Kernel Network Developers,
Yuchung Cheng
In-Reply-To: <1380277734.30872.25.camel@edumazet-glaptop.roam.corp.google.com>
On Fri, Sep 27, 2013 at 6:28 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> When TCP Small Queues was added, we used a sysctl to limit amount of
> packets queues on Qdisc/device queues for a given TCP flow.
>
> Problem is this limit is either too big for low rates, or too small
> for high rates.
>
> Now TCP stack has rate estimation in sk->sk_pacing_rate, and TSO
> auto sizing, it can better control number of packets in Qdisc/device
> queues.
>
> New limit is two packets or at least 1 to 2 ms worth of packets.
>
> Low rates flows benefit from this patch by having even smaller
> number of packets in queues, allowing for faster recovery,
> better RTT estimations.
>
> High rates flows benefit from this patch by allowing more than 2 packets
> in flight as we had reports this was a limiting factor to reach line
> rate. [ In particular if TX completion is delayed because of coalescing
> parameters ]
>
> Example for a single flow on 10Gbp link controlled by FQ/pacing
>
> 14 packets in flight instead of 2
>
> $ tc -s -d qd
> qdisc fq 8001: dev eth0 root refcnt 32 limit 10000p flow_limit 100p
> buckets 1024 quantum 3028 initial_quantum 15140
> Sent 1168459366606 bytes 771822841 pkt (dropped 0, overlimits 0
> requeues 6822476)
> rate 9346Mbit 771713pps backlog 953820b 14p requeues 6822476
> 2047 flow, 2046 inactive, 1 throttled, delay 15673 ns
> 2372 gc, 0 highprio, 0 retrans, 9739249 throttled, 0 flows_plimit
>
> Note that sk_pacing_rate is currently set to twice the actual rate, but
> this might be refined in the future when a flow is in congestion
> avoidance.
>
> Additional change : skb->destructor should be set to tcp_wfree().
>
> A future patch (for linux 3.13+) might remove tcp_limit_output_bytes
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Cong Wang <xiyou.wangcong@gmail.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> ---
Acked-by: Neal Cardwell <ncardwell@google.com>
neal
^ permalink raw reply
* Re: question about map_read_chunks()
From: Tom Tucker @ 2013-09-27 15:23 UTC (permalink / raw)
To: Dan Carpenter
Cc: Tom Tucker, J. Bruce Fields, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20130927122108.GF6247@mwanda>
Hi Dan,
On 9/27/13 7:21 AM, Dan Carpenter wrote:
> I have looked at this again, and I still worry that it looks like a bug.
> (remote security related blah blah blah).
>
> regards,
> dan carpenter
>
> On Mon, Feb 20, 2012 at 12:50:19PM +0300, Dan Carpenter wrote:
>> I had a couple questions about some map_read_chunks().
>>
>> net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
>>
>> 150 ch_bytes = ntohl(ch->rc_target.rs_length);
>> ^^^^^^^^
>> It look like this is 32 bits from the network?
>>
>> 151 head->arg.head[0] = rqstp->rq_arg.head[0];
>> 152 head->arg.tail[0] = rqstp->rq_arg.tail[0];
>> 153 head->arg.pages = &head->pages[head->count];
>> 154 head->hdr_count = head->count; /* save count of hdr pages */
>> 155 head->arg.page_base = 0;
>> 156 head->arg.page_len = ch_bytes;
>> 157 head->arg.len = rqstp->rq_arg.len + ch_bytes;
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Can overflow.
>> 158 head->arg.buflen = rqstp->rq_arg.buflen + ch_bytes;
agreed.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Same. I didn't follow it through to see if an overflow matters. Does
>> it?
>>
>> 159 head->count++;
>> 160 chl_map->ch[0].start = 0;
>> 161 while (byte_count) {
>> 162 rpl_map->sge[sge_no].iov_base =
>> 163 page_address(rqstp->rq_arg.pages[page_no]) + page_off;
>> 164 sge_bytes = min_t(int, PAGE_SIZE-page_off, ch_bytes);
>> ^^^
>> This is the wrong cast to use. A large ch_bytes would be counted as a
>> negative value and get around the cap here.
True, but if we validate the wire data like we should, that's probably
not an issue.
>> 165 rpl_map->sge[sge_no].iov_len = sge_bytes;
>>
>> regards,
>> dan carpenter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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
* Re: [PATCH v3] powerpc/83xx: gianfar_ptp: select 1588 clock source through dts file
From: Kumar Gala @ 2013-09-27 15:28 UTC (permalink / raw)
To: Aida Mynzhasova
Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
richardcochran-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1380289227-12029-1-git-send-email-aida.mynzhasova-Fmhy8gsqeTEvJsYlp49lxw@public.gmane.org>
On Sep 27, 2013, at 8:40 AM, Aida Mynzhasova wrote:
> Currently IEEE 1588 timer reference clock source is determined through
> hard-coded value in gianfar_ptp driver. This patch allows to select ptp
> clock source by means of device tree file node.
>
> For instance:
>
> fsl,cksel = <0>;
>
> for using external (TSEC_TMR_CLK input) high precision timer
> reference clock.
>
> Other acceptable values:
>
> <1> : eTSEC system clock
> <2> : eTSEC1 transmit clock
> <3> : RTC clock input
>
> When this attribute isn't used, eTSEC system clock will serve as
> IEEE 1588 timer reference clock.
>
> Signed-off-by: Aida Mynzhasova <aida.mynzhasova-Fmhy8gsqeTEvJsYlp49lxw@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/fsl-tsec-phy.txt | 18 +++++++++++++++++-
> drivers/net/ethernet/freescale/gianfar_ptp.c | 4 +++-
> 2 files changed, 20 insertions(+), 2 deletions(-)
Acked-by: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
- k--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
* [PATCH] bonding: Fix broken promiscuity reference counting issue
From: Neil Horman @ 2013-09-27 16:22 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Jay Vosburgh, Andy Gospodarek, Mark Wu,
David S. Miller
Recently grabbed this report:
https://bugzilla.redhat.com/show_bug.cgi?id=1005567
Of an issue in which the bonding driver, with an attached vlan encountered the
following errors when bond0 was taken down and back up:
dummy1: promiscuity touches roof, set promiscuity failed. promiscuity feature of
device might be broken.
The error occurs because, during __bond_release_one, if we release our last
slave, we take on a random mac address and issue a NETDEV_CHANGEADDR
notification. With an attached vlan, the vlan may see that the vlan and bond
mac address were in sync, but no longer are. This triggers a call to dev_uc_add
and dev_set_rx_mode, which enables IFF_PROMISC on the bond device. Then, when
we complete __bond_release_one, we use the current state of the bond flags to
determine if we should decrement the promiscuity of the releasing slave. But
since the bond changed promiscuity state during the release operation, we
incorrectly decrement the slave promisc count when it wasn't in promiscuous mode
to begin with, causing the above error
Fix is pretty simple, just cache the bonding flags at the start of the function
and use those when determining the need to set promiscuity.
This is also needed for the ALLMULTI flag
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: Mark Wu <wudxw@linux.vnet.ibm.com>
CC: "David S. Miller" <davem@davemloft.net>
Reported-by: Mark Wu <wudxw@linux.vnet.ibm.com>
---
drivers/net/bonding/bond_main.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index d5c3153..5373a8d 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1710,6 +1710,7 @@ static int __bond_release_one(struct net_device *bond_dev,
struct bonding *bond = netdev_priv(bond_dev);
struct slave *slave, *oldcurrent;
struct sockaddr addr;
+ int old_flags = bond_dev->flags;
netdev_features_t old_features = bond_dev->features;
/* slave is not a slave or master is not master of this slave */
@@ -1841,12 +1842,18 @@ static int __bond_release_one(struct net_device *bond_dev,
* bond_change_active_slave(..., NULL)
*/
if (!USES_PRIMARY(bond->params.mode)) {
- /* unset promiscuity level from slave */
- if (bond_dev->flags & IFF_PROMISC)
+ /* unset promiscuity level from slave
+ * NOTE: The NETDEV_CHANGEADDR call above may change the value
+ * of the IFF_PROMISC flag in the bond_dev, but we need the
+ * value of that flag before that change, as that was the value
+ * when this slave was attached, so we cache at the start of the
+ * function and use it here. Same goes for ALLMULTI below
+ */
+ if (old_flags & IFF_PROMISC)
dev_set_promiscuity(slave_dev, -1);
/* unset allmulti level from slave */
- if (bond_dev->flags & IFF_ALLMULTI)
+ if (old_flags & IFF_ALLMULTI)
dev_set_allmulti(slave_dev, -1);
bond_hw_addr_flush(bond_dev, slave_dev);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] IPv6: Allow the MTU of ipip6 tunnel to be set below 1280
From: Oussama Ghorbel @ 2013-09-27 16:36 UTC (permalink / raw)
To: Oussama Ghorbel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <20130927105856.GF28287@order.stressinduktion.org>
Please see my comments below
Regards,
Oussama
On Fri, Sep 27, 2013 at 11:58 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Fri, Sep 27, 2013 at 11:45:48AM +0100, Oussama Ghorbel wrote:
>> The ip6_tunnel.c module would be then dependent on ip_tunnel.c and may
>> be it would not be good thing?
>
> It could just be a static inline in some shared header. So there would
> be no compile-time dependency.
>
The higher limit of mtu in ip_tunnel_change_mtu() is a calculated value.
This high limit is calculated using the netdev priv struct ip_tunnel
(field hlen).
This netdev priv struct is different in ipv6, it's a ip6_tnl struct.
Therefore implementing a beautiful function like
ip_tunnel_valid_mtu(struct net_device *dev, int mtu) won't be
feasible, unless we implement it in macro or something like like
ip_tunnel_valid_mtu(struct net_device *dev, int hlen, int mtu) which
seems not very nice ...
What do yo think?
>> As I have check in v3.10 there is no call from ip6_tunnel to ip_tunnel...
>>
>> For information, there is no check for the maximum MTU for ipv4 in the
>> patch as this is not done for ipv6.
>
> I understand, but it would be better to limit the MTU here. There is a
> (non-jumo) IPV6_MAXPLEN constant.
>
> Looking through the source it seems grev6 does actually check this,
> so it would not hurt adding them here, too.
what if jumbograms is used, in that case, we can't use IPV6_MAXPLEN.
the limit would be the the full unsigned int.
However checking the higher limit for ipv4 would be useful.
Please also note in case the tunnel mode is any (ipv4 or ipv6 means
ip6_tnl.parms.proto = 0), then we will be required to take the most
restrict limit from both ipv4 and ipv6 which means the lower limit
will be 1280 and the higher limit will be about 65535
Do you agree on this?
>
> Otherwise, I think your patch is fine.
>
> Greetings,
>
> Hannes
>
^ permalink raw reply
* Re: [PATCH v2.40 1/7] odp: Only pass vlan_tci to commit_vlan_action()
From: Ben Pfaff @ 2013-09-27 16:56 UTC (permalink / raw)
To: Simon Horman
Cc: dev, netdev, Jesse Gross, Pravin B Shelar, Ravi K, Isaku Yamahata,
Joe Stringer
In-Reply-To: <1380241116-7661-2-git-send-email-horms@verge.net.au>
On Fri, Sep 27, 2013 at 09:18:30AM +0900, Simon Horman wrote:
> From: Joe Stringer <joe@wand.net.nz>
>
> This allows for future patches to pass different tci values to
> commit_vlan_action() without passing an entire flow structure.
>
> Signed-off-by: Joe Stringer <joe@wand.net.nz>
> Signed-off-by: Simon Horman <horms@verge.net.au>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] IPv6: Allow the MTU of ipip6 tunnel to be set below 1280
From: Hannes Frederic Sowa @ 2013-09-27 17:03 UTC (permalink / raw)
To: Oussama Ghorbel
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <CA+ev272+Gp6Kt7S8P-wXxPBh0D8Di9WVH9NDi41HpNakLKC4Dw@mail.gmail.com>
On Fri, Sep 27, 2013 at 05:36:45PM +0100, Oussama Ghorbel wrote:
> Please see my comments below
>
> Regards,
> Oussama
>
> On Fri, Sep 27, 2013 at 11:58 AM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> > On Fri, Sep 27, 2013 at 11:45:48AM +0100, Oussama Ghorbel wrote:
> >> The ip6_tunnel.c module would be then dependent on ip_tunnel.c and may
> >> be it would not be good thing?
> >
> > It could just be a static inline in some shared header. So there would
> > be no compile-time dependency.
> >
>
> The higher limit of mtu in ip_tunnel_change_mtu() is a calculated value.
> This high limit is calculated using the netdev priv struct ip_tunnel
> (field hlen).
> This netdev priv struct is different in ipv6, it's a ip6_tnl struct.
> Therefore implementing a beautiful function like
> ip_tunnel_valid_mtu(struct net_device *dev, int mtu) won't be
> feasible, unless we implement it in macro or something like like
> ip_tunnel_valid_mtu(struct net_device *dev, int hlen, int mtu) which
> seems not very nice ...
> What do yo think?
Ok, let's go with one function per protocol type. Seems easier.
It seems to get more hairy, because it depends on the tunnel driver if the
prepended ip header is accounted in hard_header_len. :/
I don't know if it works out cleanly. Otherwise I would be ok if the checks
just get repeated in ip6_tunnel and leave the rest as-is.
>
> >> As I have check in v3.10 there is no call from ip6_tunnel to ip_tunnel...
> >>
> >> For information, there is no check for the maximum MTU for ipv4 in the
> >> patch as this is not done for ipv6.
> >
> > I understand, but it would be better to limit the MTU here. There is a
> > (non-jumo) IPV6_MAXPLEN constant.
> >
> > Looking through the source it seems grev6 does actually check this,
> > so it would not hurt adding them here, too.
>
> what if jumbograms is used, in that case, we can't use IPV6_MAXPLEN.
> the limit would be the the full unsigned int.
> However checking the higher limit for ipv4 would be useful.
Linux currently cannot create "jumbograms" (only the receiving side
is supported).
> Please also note in case the tunnel mode is any (ipv4 or ipv6 means
> ip6_tnl.parms.proto = 0), then we will be required to take the most
> restrict limit from both ipv4 and ipv6 which means the lower limit
> will be 1280 and the higher limit will be about 65535
> Do you agree on this?
Agreed, this would be needed for e.g. the sit driver, which now can
handle both protocols.
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net 0/4] bridge: Fix problems around the PVID
From: Toshiaki Makita @ 2013-09-27 17:11 UTC (permalink / raw)
To: vyasevic
Cc: Toshiaki Makita, David Miller, netdev, Fernando Luis Vazquez Cao,
Patrick McHardy
In-Reply-To: <52444322.40408@redhat.com>
On Thu, 2013-09-26 at 10:22 -0400, Vlad Yasevich wrote:
> On 09/26/2013 06:38 AM, Toshiaki Makita wrote:
> > On Tue, 2013-09-24 at 13:55 -0400, Vlad Yasevich wrote:
> >> On 09/24/2013 01:30 PM, Toshiaki Makita wrote:
> >>> On Tue, 2013-09-24 at 09:35 -0400, Vlad Yasevich wrote:
> >>>> On 09/24/2013 07:45 AM, Toshiaki Makita wrote:
> >>>>> On Mon, 2013-09-23 at 10:41 -0400, Vlad Yasevich wrote:
> >>>>>> On 09/17/2013 04:12 AM, Toshiaki Makita wrote:
> >>>>>>> On Mon, 2013-09-16 at 13:49 -0400, Vlad Yasevich wrote:
> >>>>>>>> On 09/13/2013 08:06 AM, Toshiaki Makita wrote:
> >>>>>>>>> On Thu, 2013-09-12 at 16:00 -0400, David Miller wrote:
> >>>>>>>>>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> >>>>>>>>>> Date: Tue, 10 Sep 2013 19:27:54 +0900
> >>>>>>>>>>
> >>>>>>>>>>> There seem to be some undesirable behaviors related with PVID.
> >>>>>>>>>>> 1. It has no effect assigning PVID to a port. PVID cannot be applied
> >>>>>>>>>>> to any frame regardless of whether we set it or not.
> >>>>>>>>>>> 2. FDB entries learned via frames applied PVID are registered with
> >>>>>>>>>>> VID 0 rather than VID value of PVID.
> >>>>>>>>>>> 3. We can set 0 or 4095 as a PVID that are not allowed in IEEE 802.1Q.
> >>>>>>>>>>> This leads interoperational problems such as sending frames with VID
> >>>>>>>>>>> 4095, which is not allowed in IEEE 802.1Q, and treating frames with VID
> >>>>>>>>>>> 0 as they belong to VLAN 0, which is expected to be handled as they have
> >>>>>>>>>>> no VID according to IEEE 802.1Q.
> >>>>>>>>>>>
> >>>>>>>>>>> Note: 2nd and 3rd problems are potential and not exposed unless 1st problem
> >>>>>>>>>>> is fixed, because we cannot activate PVID due to it.
> >>>>>>>>>>
> >>>>>>>>>> Please work out the issues in patch #2 with Vlad and resubmit this
> >>>>>>>>>> series.
> >>>>>>>>>>
> >>>>>>>>>> Thank you.
> >>>>>>>>>
> >>>>>>>>> I'm hovering between whether we should fix the issue by changing vlan 0
> >>>>>>>>> interface behavior in 8021q module or enabling a bridge port to sending
> >>>>>>>>> priority-tagged frames, or another better way.
> >>>>>>>>>
> >>>>>>>>> If you could comment it, I'd appreciate it :)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> BTW, I think what is discussed in patch #2 is another problem about
> >>>>>>>>> handling priority-tags, and it exists without this patch set applied.
> >>>>>>>>> It looks like that we should prepare another patch set than this to fix
> >>>>>>>>> that problem.
> >>>>>>>>>
> >>>>>>>>> Should I include patches that fix the priority-tags problem in this
> >>>>>>>>> patch set and resubmit them all together?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I am thinking that we might need to do it in bridge and it looks like
> >>>>>>>> the simplest way to do it is to have default priority regeneration table
> >>>>>>>> (table 6-5 from 802.1Q doc).
> >>>>>>>>
> >>>>>>>> That way I think we would conform to the spec.
> >>>>>>>>
> >>>>>>>> -vlad
> >>>>>>>
> >>>>>>> Unfortunately I don't think the default priority regeneration table
> >>>>>>> resolves the problem because IEEE 802.1Q says that a VLAN-aware bridge
> >>>>>>> can transmit untagged or VLAN-tagged frames only (the end of section 7.5
> >>>>>>> and 8.1.7).
> >>>>>>>
> >>>>>>> No mechanism to send priority-tagged frames is found as far as I can see
> >>>>>>> the standard. I think the regenerated priority is used for outgoing PCP
> >>>>>>> field only if egress policy is not untagged (i.e. transmitting as
> >>>>>>> VLAN-tagged), and unused if untagged (Section 6.9.2 3rd/4th Paragraph).
> >>>>>>>
> >>>>>>> If we want to transmit priority-tagged frames from a bridge port, I
> >>>>>>> think we need to implement a new (optional) feature that is above the
> >>>>>>> standard, as I stated previously.
> >>>>>>>
> >>>>>>> How do you feel about adding a per-port policy that enables a bridge to
> >>>>>>> send priority-tagged frames instead of untagged frames when egress
> >>>>>>> policy for the port is untagged?
> >>>>>>> With this change, we can transmit frames for a given vlan as either all
> >>>>>>> untagged, all priority-tagged or all VLAN-tagged.
> >>>>>>
> >>>>>> That would work. What I am thinking is that we do it by special casing
> >>>>>> the vid 0 egress policy specification. Let it be untagged by default
> >>>>>> and if it is tagged, then we preserve the priority field and forward
> >>>>>> it on.
> >>>>>>
> >>>>>> This keeps the API stable and doesn't require user/admin from knowing
> >>>>>> exactly what happens. Default operation conforms to the spec and allows
> >>>>>> simple change to make it backward-compatible.
> >>>>>>
> >>>>>> What do you think. I've done a simple prototype of this an it seems to
> >>>>>> work with the VMs I am testing with.
> >>>>>
> >>>>> Are you saying that
> >>>>> - by default, set the 0th bit of untagged_bitmap; and
> >>>>> - if we unset the 0th bit and set the "vid"th bit, we transmit frames
> >>>>> classified as belonging to VLAN "vid" as priority-tagged?
> >>>>>
> >>>>> If so, though it's attractive to keep current API, I'm worried about if
> >>>>> it could be a bit confusing and not intuitive for kernel/iproute2
> >>>>> developers that VID 0 has a special meaning only in the egress policy.
> >>>>> Wouldn't it be better to adding a new member to struct net_port_vlans
> >>>>> instead of using VID 0 of untagged_bitmap?
> >>>>>
> >>>>> Or are you saying that we use a new flag in struct net_port_vlans but
> >>>>> use the BRIDGE_VLAN_INFO_UNTAGGED bit with VID 0 in netlink to set the
> >>>>> flag?
> >>>>>
> >>>>> Even in that case, I'm afraid that it might be confusing for developers
> >>>>> for the same reason. We are going to prohibit to specify VID with 0 (and
> >>>>> 4095) in adding/deleting a FDB entry or a vlan filtering entry, but it
> >>>>> would allow us to use VID 0 only when a vlan filtering entry is
> >>>>> configured.
> >>>>> I am thinking a new nlattr is a straightforward approach to configure
> >>>>> it.
> >>>>
> >>>> By making this an explicit attribute it makes vid 0 a special case for
> >>>> any automatic tool that would provision such filtering. Seeing vid 0
> >>>> would mean that these tools would have to know that this would have to
> >>>> be translated to a different attribute instead of setting the policy
> >>>> values.
> >>>
> >>> Yes, I agree with you that we can do it by the way you explained.
> >>> What I don't understand is the advantage of using vid 0 over another way
> >>> such as adding a new nlattr.
> >>> I think we can indicate transmitting priority-tags explicitly by such a
> >>> nlattr. Using vid 0 seems to be easier to implement than a new nlattr,
> >>> but, for me, it looks less intuitive and more difficult to maintain
> >>> because we have to care about vid 0 instead of simply ignoring it.
> >>>
> >>
> >> The point I am trying to make is that regardless of the approach someone
> >> has to know what to do when enabling priority tagged frames. You
> >> proposal would require the administrator or config tool to have that
> >> knowledge. Example is:
> >> Admin does: bridge vlan set priority on dev eth0
> >> Automated app:
> >> if (vid == 0)
> >> /* Turn on priority tagged frame support */
> >>
> >> My proposal would require the bridge filtering implementation to have it.
> >> user tool: bridge vlan add vid 0 tagged
> >> Automated app: No special case.
> >>
> >> IMO its better to have 1 piece code handling the special case then
> >> putting it multiple places.
> >
> > Thank you for the detailed explanation.
> > Now I understand your intention.
> >
> > I have one question about your proposal.
> > I guess the way to enable priority-tagged is something like
> > bridge vlan add vid 10 dev eth0
> > bridge vlan add vid 10 dev vnet0 pvid untagged
> > bridge vlan add vid 0 dev vnet0 tagged
> > where vnet0 has sub interface vnet0.0.
> >
> > Here the admin have to know the egress policy is applied to a frame
> > twice in a certain order when it is transmitted from the port vnet0
> > attached, that is, first, a frame with vid 10 get untagged, and then, an
> > untagged frame get priority-tagged.
> >
> > This behavior looks difficult to know without previous knowledge.
> > Any good idea to avoid such a need for the admin's additional knowledge?
>
> To me, the fact that there is vnet0.0 (or typically, there is eth0.0 in
> the guest or on the remote host) already tells the admin vlan 0 has to
> be tagged. The fact that we codify this in the policy makes it explicit.
My worry is that the admin might not be able to guess how to use bridge
commands to enable priority-tag without any additional hint in "man
bridge", "bridge vlan help", etc.
I actually couldn't hit upon such a usage before seeing example commands
you gave, because I had never think the egress policy could be applied
twice.
>
> However, I can see strong argument to be made for an addition egress
> policy attribute that could be for instance:
>
> bridge vlan add vid 10 dev eth0 pvid
> bridge vlan add vid 10 dev vnet0 pvid untagged prio_tag
>
> But this has the same connotations as wrt to egress policy. The 2
> policies are applied:
> (1) untag the frame.
> (2) add priority_tag.
>
> (2) only happens if initial fame received on eth0 was priority tagged.
If we do so, we will not be able to communicate using vlan 0 interface
under a certain circumstance.
Eth0 can be receive mixed untagged and priority-tagged frames according
to the network element it is connected to: for example, Open vSwitch can
send such two kinds of frames from the same port even if original
incoming frames belong to the same vlan.
In this situation, we can only receive frames that is priority-tagged
when received on eth0.
IMO, if prio_tag is configured, the bridge should send any untagged
frame as priority-tagged regardless of whatever it is on eth0.
>
> I think I am ok with either approach. Explicit vid 0 policy is easier
> for automatic provisioning. The flag based one is easier for admin/
> manual provisioning.
Supposing we have to add something to help or man in any case, I think
flag based is better.
The format below seems to suitable for a per-port policy.
bridge vlan set prio_tag on dev vnet0
Thanks,
Toshiaki Makita
>
> -vlad.
>
> -vlad
>
>
>
>
> >
> >>
> >> Thanks
> >> -vlad
> >>
> >>> Thanks,
> >>>
> >>> Toshiaki Makita
> >>>
> >>>>
> >>>> How it is implemented internally in the kernel isn't as big of an issue.
> >>>> We can do it as a separate flag or as part of existing policy.
> >>>>
> >>>> -vlad
> >>>>
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Toshiaki Makita
> >>>>>
> >>>>>>
> >>>>>> -vlad
> >>>>>>
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>> Toshiaki Makita
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>>
> >>>>>>>>> Toshiaki Makita
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
> >>>>>>>>>> the body of a message to majordomo@vger.kernel.org
> >>>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
> >>>>>>> the body of a message to majordomo@vger.kernel.org
> >>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >
> >
>
^ permalink raw reply
* Re: [net v2 0/6][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2013-09-27 17:29 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1380285358-15685-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 27 Sep 2013 05:35:52 -0700
> This series contains updates to igb and i40e.
>
> Todd provides a fix for 82580 devices in igb, where the ethtool
> loopback test was missing 82580 copper devices.
>
> Jesse provides five fixes/cleanups to i40e based on feedback from
> Joe Perches and the community.
>
> v2: fixed up patch 5 in the series based on feedback from Joe Perches
> and David Miller
>
> The following are changes since commit f875691640cd3fa67f7ad1d3130ff9fa7fdca042:
> Merge branch 'fixes-for-3.12' of git://gitorious.org/linux-can/linux-can
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net master
Pulled, thanks a lot Jeff.
^ permalink raw reply
* Re: [PATCH net-next 0/2] netxen_nic: Minor enhancement
From: David Miller @ 2013-09-27 17:31 UTC (permalink / raw)
To: shahed.shaikh; +Cc: netdev, Dept-HSGLinuxNICDev
In-Reply-To: <1380260547-25903-1-git-send-email-shahed.shaikh@qlogic.com>
From: Shahed Shaikh <shahed.shaikh@qlogic.com>
Date: Fri, 27 Sep 2013 01:42:25 -0400
> From: Shahed Shaikh <shahed.shaikh@qlogic.com>
>
> This patch series contains following changes
> * Log a message about ULA adapter type.
> * Update the driver version to 4.0.82.
All applied, thank you.
^ permalink raw reply
* [PATCH v3 net-next 0/2] qlge: feature update
From: Jitendra Kalsaria @ 2013-09-27 17:17 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer, Dept-HSGLinuxNICDev, Jitendra Kalsaria
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
This patch series enhance the handling of nested vlan tags in Rx path.
V2 changes:
* removed module parameter.
V3 changes:
* Users can enable or disable hardware VLAN acceleration using ethtool
Please apply it to net-next.
Jitendra Kalsaria (2):
qlge: Enhance nested VLAN (Q-in-Q) handling.
qlge: Update version to 1.00.00.33
drivers/net/ethernet/qlogic/qlge/qlge.h | 2 +-
drivers/net/ethernet/qlogic/qlge/qlge_main.c | 126 +++++++++++++++++++++-----
2 files changed, 102 insertions(+), 26 deletions(-)
--
1.7.6.rc1.1.g2c162b
^ permalink raw reply
* [PATCH v3 net-next 1/2] qlge: Enhance nested VLAN (Q-in-Q) handling.
From: Jitendra Kalsaria @ 2013-09-27 17:17 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer, Dept-HSGLinuxNICDev, Jitendra Kalsaria
In-Reply-To: <1380302267-27843-1-git-send-email-jitendra.kalsaria@qlogic.com>
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
o Adapter doesn’t handle packets with nested VLAN tags in
Rx path. User can turn off VLAN tag stripping in the hardware
and let the stack handle stripping of VLAN tags in the Rx path.
o Users can enable or disable hardware VLAN acceleration using ethtool
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
---
drivers/net/ethernet/qlogic/qlge/qlge_main.c | 126 +++++++++++++++++++++-----
1 files changed, 101 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_main.c b/drivers/net/ethernet/qlogic/qlge/qlge_main.c
index 2553cf4..64f9409 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge_main.c
+++ b/drivers/net/ethernet/qlogic/qlge/qlge_main.c
@@ -96,8 +96,10 @@ static DEFINE_PCI_DEVICE_TABLE(qlge_pci_tbl) = {
MODULE_DEVICE_TABLE(pci, qlge_pci_tbl);
-static int ql_wol(struct ql_adapter *qdev);
-static void qlge_set_multicast_list(struct net_device *ndev);
+static int ql_wol(struct ql_adapter *);
+static void qlge_set_multicast_list(struct net_device *);
+static int ql_adapter_down(struct ql_adapter *);
+static int ql_adapter_up(struct ql_adapter *);
/* This hardware semaphore causes exclusive access to
* resources shared between the NIC driver, MPI firmware,
@@ -1464,6 +1466,29 @@ static void ql_categorize_rx_err(struct ql_adapter *qdev, u8 rx_err,
}
}
+/**
+ * ql_update_mac_hdr_len - helper routine to update the mac header length
+ * based on vlan tags if present
+ */
+static void ql_update_mac_hdr_len(struct ql_adapter *qdev,
+ struct ib_mac_iocb_rsp *ib_mac_rsp,
+ void *page, size_t *len)
+{
+ u16 *tags;
+
+ if (qdev->ndev->features & NETIF_F_HW_VLAN_CTAG_RX)
+ return;
+ if (ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) {
+ tags = (u16 *)page;
+ /* Look for stacked vlan tags in ethertype field */
+ if (tags[6] == ETH_P_8021Q &&
+ tags[8] == ETH_P_8021Q)
+ *len += 2 * VLAN_HLEN;
+ else
+ *len += VLAN_HLEN;
+ }
+}
+
/* Process an inbound completion from an rx ring. */
static void ql_process_mac_rx_gro_page(struct ql_adapter *qdev,
struct rx_ring *rx_ring,
@@ -1523,6 +1548,7 @@ static void ql_process_mac_rx_page(struct ql_adapter *qdev,
void *addr;
struct bq_desc *lbq_desc = ql_get_curr_lchunk(qdev, rx_ring);
struct napi_struct *napi = &rx_ring->napi;
+ size_t hlen = ETH_HLEN;
skb = netdev_alloc_skb(ndev, length);
if (!skb) {
@@ -1540,25 +1566,28 @@ static void ql_process_mac_rx_page(struct ql_adapter *qdev,
goto err_out;
}
+ /* Update the MAC header length*/
+ ql_update_mac_hdr_len(qdev, ib_mac_rsp, addr, &hlen);
+
/* The max framesize filter on this chip is set higher than
* MTU since FCoE uses 2k frames.
*/
- if (skb->len > ndev->mtu + ETH_HLEN) {
+ if (skb->len > ndev->mtu + hlen) {
netif_err(qdev, drv, qdev->ndev,
"Segment too small, dropping.\n");
rx_ring->rx_dropped++;
goto err_out;
}
- memcpy(skb_put(skb, ETH_HLEN), addr, ETH_HLEN);
+ memcpy(skb_put(skb, hlen), addr, hlen);
netif_printk(qdev, rx_status, KERN_DEBUG, qdev->ndev,
"%d bytes of headers and data in large. Chain page to new skb and pull tail.\n",
length);
skb_fill_page_desc(skb, 0, lbq_desc->p.pg_chunk.page,
- lbq_desc->p.pg_chunk.offset+ETH_HLEN,
- length-ETH_HLEN);
- skb->len += length-ETH_HLEN;
- skb->data_len += length-ETH_HLEN;
- skb->truesize += length-ETH_HLEN;
+ lbq_desc->p.pg_chunk.offset + hlen,
+ length - hlen);
+ skb->len += length - hlen;
+ skb->data_len += length - hlen;
+ skb->truesize += length - hlen;
rx_ring->rx_packets++;
rx_ring->rx_bytes += skb->len;
@@ -1576,7 +1605,7 @@ static void ql_process_mac_rx_page(struct ql_adapter *qdev,
(ib_mac_rsp->flags3 & IB_MAC_IOCB_RSP_V4)) {
/* Unfragmented ipv4 UDP frame. */
struct iphdr *iph =
- (struct iphdr *) ((u8 *)addr + ETH_HLEN);
+ (struct iphdr *)((u8 *)addr + hlen);
if (!(iph->frag_off &
htons(IP_MF|IP_OFFSET))) {
skb->ip_summed = CHECKSUM_UNNECESSARY;
@@ -1726,7 +1755,8 @@ static struct sk_buff *ql_build_rx_skb(struct ql_adapter *qdev,
struct bq_desc *sbq_desc;
struct sk_buff *skb = NULL;
u32 length = le32_to_cpu(ib_mac_rsp->data_len);
- u32 hdr_len = le32_to_cpu(ib_mac_rsp->hdr_len);
+ u32 hdr_len = le32_to_cpu(ib_mac_rsp->hdr_len);
+ size_t hlen = ETH_HLEN;
/*
* Handle the header buffer if present.
@@ -1853,9 +1883,10 @@ static struct sk_buff *ql_build_rx_skb(struct ql_adapter *qdev,
skb->data_len += length;
skb->truesize += length;
length -= length;
- __pskb_pull_tail(skb,
- (ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) ?
- VLAN_ETH_HLEN : ETH_HLEN);
+ ql_update_mac_hdr_len(qdev, ib_mac_rsp,
+ lbq_desc->p.pg_chunk.va,
+ &hlen);
+ __pskb_pull_tail(skb, hlen);
}
} else {
/*
@@ -1910,8 +1941,9 @@ static struct sk_buff *ql_build_rx_skb(struct ql_adapter *qdev,
length -= size;
i++;
}
- __pskb_pull_tail(skb, (ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) ?
- VLAN_ETH_HLEN : ETH_HLEN);
+ ql_update_mac_hdr_len(qdev, ib_mac_rsp, lbq_desc->p.pg_chunk.va,
+ &hlen);
+ __pskb_pull_tail(skb, hlen);
}
return skb;
}
@@ -2003,7 +2035,7 @@ static void ql_process_mac_split_rx_intr(struct ql_adapter *qdev,
rx_ring->rx_packets++;
rx_ring->rx_bytes += skb->len;
skb_record_rx_queue(skb, rx_ring->cq_id);
- if ((ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) && (vlan_id != 0))
+ if (vlan_id != 0xffff)
__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlan_id);
if (skb->ip_summed == CHECKSUM_UNNECESSARY)
napi_gro_receive(&rx_ring->napi, skb);
@@ -2017,7 +2049,8 @@ static unsigned long ql_process_mac_rx_intr(struct ql_adapter *qdev,
struct ib_mac_iocb_rsp *ib_mac_rsp)
{
u32 length = le32_to_cpu(ib_mac_rsp->data_len);
- u16 vlan_id = (ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) ?
+ u16 vlan_id = ((ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) &&
+ (qdev->ndev->features & NETIF_F_HW_VLAN_CTAG_RX)) ?
((le16_to_cpu(ib_mac_rsp->vlan_id) &
IB_MAC_IOCB_RSP_VLAN_MASK)) : 0xffff;
@@ -2310,9 +2343,39 @@ static void qlge_vlan_mode(struct net_device *ndev, netdev_features_t features)
}
}
+/**
+ * qlge_update_hw_vlan_features - helper routine to reinitialize the adapter
+ * based on the features to enable/disable hardware vlan accel
+ */
+static int qlge_update_hw_vlan_features(struct net_device *ndev,
+ netdev_features_t features)
+{
+ struct ql_adapter *qdev = netdev_priv(ndev);
+ int status = 0;
+
+ status = ql_adapter_down(qdev);
+ if (status) {
+ netif_err(qdev, link, qdev->ndev,
+ "Failed to bring down the adapter\n");
+ return status;
+ }
+
+ /* update the features with resent change */
+ ndev->features = features;
+
+ status = ql_adapter_up(qdev);
+ if (status) {
+ netif_err(qdev, link, qdev->ndev,
+ "Failed to bring up the adapter\n");
+ return status;
+ }
+ return status;
+}
+
static netdev_features_t qlge_fix_features(struct net_device *ndev,
netdev_features_t features)
{
+ int err;
/*
* Since there is no support for separate rx/tx vlan accel
* enable/disable make sure tx flag is always in same state as rx.
@@ -2322,6 +2385,11 @@ static netdev_features_t qlge_fix_features(struct net_device *ndev,
else
features &= ~NETIF_F_HW_VLAN_CTAG_TX;
+ /* Update the behavior of vlan accel in the adapter */
+ err = qlge_update_hw_vlan_features(ndev, features);
+ if (err)
+ return err;
+
return features;
}
@@ -3704,8 +3772,12 @@ static int ql_adapter_initialize(struct ql_adapter *qdev)
ql_write32(qdev, SYS, mask | value);
/* Set the default queue, and VLAN behavior. */
- value = NIC_RCV_CFG_DFQ | NIC_RCV_CFG_RV;
- mask = NIC_RCV_CFG_DFQ_MASK | (NIC_RCV_CFG_RV << 16);
+ value = NIC_RCV_CFG_DFQ;
+ mask = NIC_RCV_CFG_DFQ_MASK;
+ if (qdev->ndev->features & NETIF_F_HW_VLAN_CTAG_RX) {
+ value |= NIC_RCV_CFG_RV;
+ mask |= (NIC_RCV_CFG_RV << 16);
+ }
ql_write32(qdev, NIC_RCV_CFG, (mask | value));
/* Set the MPI interrupt to enabled. */
@@ -4692,11 +4764,15 @@ static int qlge_probe(struct pci_dev *pdev,
qdev = netdev_priv(ndev);
SET_NETDEV_DEV(ndev, &pdev->dev);
- ndev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM |
- NETIF_F_TSO | NETIF_F_TSO_ECN |
- NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_RXCSUM;
- ndev->features = ndev->hw_features |
- NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_HW_VLAN_CTAG_FILTER;
+ ndev->hw_features = NETIF_F_SG |
+ NETIF_F_IP_CSUM |
+ NETIF_F_TSO |
+ NETIF_F_TSO_ECN |
+ NETIF_F_HW_VLAN_CTAG_TX |
+ NETIF_F_HW_VLAN_CTAG_RX |
+ NETIF_F_HW_VLAN_CTAG_FILTER |
+ NETIF_F_RXCSUM;
+ ndev->features = ndev->hw_features;
ndev->vlan_features = ndev->hw_features;
if (test_bit(QL_DMA64, &qdev->flags))
--
1.7.6.rc1.1.g2c162b
^ permalink raw reply related
* [PATCH v3 net-next 2/2] qlge: Update version to 1.00.00.33
From: Jitendra Kalsaria @ 2013-09-27 17:17 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer, Dept-HSGLinuxNICDev, Jitendra Kalsaria
In-Reply-To: <1380302267-27843-1-git-send-email-jitendra.kalsaria@qlogic.com>
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
---
drivers/net/ethernet/qlogic/qlge/qlge.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlge/qlge.h b/drivers/net/ethernet/qlogic/qlge/qlge.h
index cc62272..f1af4d6 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge.h
+++ b/drivers/net/ethernet/qlogic/qlge/qlge.h
@@ -18,7 +18,7 @@
*/
#define DRV_NAME "qlge"
#define DRV_STRING "QLogic 10 Gigabit PCI-E Ethernet Driver "
-#define DRV_VERSION "v1.00.00.32"
+#define DRV_VERSION "1.00.00.33"
#define WQ_ADDR_ALIGN 0x3 /* 4 byte alignment */
--
1.7.6.rc1.1.g2c162b
^ permalink raw reply related
* pull request: wireless 2013-09-27
From: John W. Linville @ 2013-09-27 18:05 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 34284 bytes --]
Dave,
Please pull this batch of fixes intended for the 3.12 stream!
Regarding the Bluetooth bits, Gustavo says:
"First Bluetooth fixes to 3.12, it includes:
* 3 patches to add device id for 3 new hardwares.
* 2 patches from Johan to fix the rfkill behaviour during setup stage
* a small clean up in the rfcomm TTY code that fixes a potential racy
condition (by Gianluca Anzolin)
* 2 fixes to proper set encryption key size and security level in the
peripheral role of Bluetooth LE devices. (by Andre Guedes)
* a fix for dealing devices where pairing is not necessary, we were keeping
the Bluetooth ACL connection alive for too much time. (by Syam Sidhardhan)"
Also, I fixed-up an curly-brace indentation problem in the Bluetooth
code while merging. On top of that...
Alexey Khoroshilov brings a p54usb fix to avoid a resource leak when
request_firmware_nowait fails.
Amitkumar Karwar fixes a firmware hang caused by too much header data
being appended for USB devices using the mwifiex driver.
Arend van Spriel provides three fixes: a brcmfmac fix to relocate some
driver code outside of an .init section; a scheduling while atomic
fix for bcma; and, another scheduling while atomic fix for brcmsmac.
Bing Zhao offers a pair of mwifiex fixes: a code change to avoid
firmware timeouts on USB; and a fix for a NULL pointer dereference.
Christian Lamparter adds a device ID to p54usb.
Felix Fietkau implements a quartet of small ath9k fixes, including
a locking fix, a list management fix, a fix to properly mark a stale
buffer, and an aggregate buffering fix.
Larry Finger champions a data alignment fix to make rtlwifi work
better with ARM builds.
Solomon Peachy reverts an earlier interrupt handling fix for cw1200
and replaces it with a new threaded oneshot irq handler implementation.
Sujith Manoharan fixes an ath9k regression by reverting an earlier
patch.
Please let me know if there are problems!
John
---
The following changes since commit f875691640cd3fa67f7ad1d3130ff9fa7fdca042:
Merge branch 'fixes-for-3.12' of git://gitorious.org/linux-can/linux-can (2013-09-27 02:08:03 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
for you to fetch changes up to 0a878747e18d4d14c5b772dcddddd86bb4c26f8f:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem (2013-09-27 13:11:17 -0400)
----------------------------------------------------------------
Alexey Khoroshilov (1):
p54usb: fix leak at failure path in p54u_load_firmware()
Amitkumar Karwar (1):
mwifiex: fix hang issue for USB chipsets
Andre Guedes (2):
Bluetooth: Fix security level for peripheral role
Bluetooth: Fix encryption key size for peripheral role
Arend van Spriel (3):
brcmfmac: obtain platform data upon module initialization
bcma: make bcma_core_pci_{up,down}() callable from atomic context
brcmsmac: call bcma_core_pci_power_save() from non-atomic context
Bing Zhao (2):
mwifiex: fix PCIe hs_cfg cancel cmd timeout
mwifiex: fix NULL pointer dereference in usb suspend handler
Christian Lamparter (1):
p54usb: add USB ID for Corega WLUSB2GTST USB adapter
Felix Fietkau (4):
ath9k: fix stale flag handling on buffer clone
ath9k: do not link bf_next across multiple A-MPDUs
ath9k: don't use BAW tracking on PS responses for non-AMPDU packets
ath9k: add txq locking for ath_tx_aggr_start
Gianluca Anzolin (1):
Bluetooth: don't release the port in rfcomm_dev_state_change()
Johan Hedberg (2):
Bluetooth: Introduce a new HCI_RFKILLED flag
Bluetooth: Fix rfkill functionality during the HCI setup stage
John W. Linville (2):
Merge branch 'master' of git://git.kernel.org/.../bluetooth/bluetooth
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Ken O'Brien (1):
Bluetooth: btusb: Add support for Belkin F8065bf
Larry Finger (1):
rtlwifi: Align private space in rtl_priv struct
Peng Chen (1):
Bluetooth: Add a new PID/VID 0cf3/e005 for AR3012.
Raphael Kubo da Costa (1):
Bluetooth: Add support for BCM20702A0 [0b05, 17cb]
Solomon Peachy (2):
Revert "cw1200: Don't perform SPI transfers in interrupt context"
cw1200: Use a threaded oneshot irq handler for cw1200_spi
Sujith Manoharan (1):
ath9k: Fix regression in LNA diversity
Syam Sidhardhan (1):
Bluetooth: Fix ACL alive for long in case of non pariable devices
drivers/bcma/driver_pci.c | 49 ++++++++++++----------
drivers/bluetooth/ath3k.c | 2 +
drivers/bluetooth/btusb.c | 5 +++
drivers/net/wireless/ath/ath9k/recv.c | 7 ----
drivers/net/wireless/ath/ath9k/xmit.c | 17 ++++++--
.../net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c | 28 ++++++-------
drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h | 3 +-
.../net/wireless/brcm80211/brcmfmac/dhd_linux.c | 14 ++++---
drivers/net/wireless/brcm80211/brcmfmac/usb.c | 2 +-
.../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 4 ++
drivers/net/wireless/cw1200/cw1200_spi.c | 26 ++++--------
drivers/net/wireless/cw1200/fwio.c | 2 +-
drivers/net/wireless/cw1200/hwbus.h | 1 -
drivers/net/wireless/cw1200/hwio.c | 15 -------
drivers/net/wireless/mwifiex/11n_aggr.c | 3 +-
drivers/net/wireless/mwifiex/11n_aggr.h | 2 +-
drivers/net/wireless/mwifiex/cmdevt.c | 5 +--
drivers/net/wireless/mwifiex/usb.c | 7 ----
drivers/net/wireless/mwifiex/wmm.c | 3 +-
drivers/net/wireless/p54/p54usb.c | 2 +
drivers/net/wireless/rtlwifi/wifi.h | 2 +-
include/linux/bcma/bcma_driver_pci.h | 1 +
include/net/bluetooth/hci.h | 1 +
net/bluetooth/hci_core.c | 26 +++++++++---
net/bluetooth/hci_event.c | 6 ++-
net/bluetooth/l2cap_core.c | 7 ++++
net/bluetooth/rfcomm/tty.c | 35 +---------------
27 files changed, 128 insertions(+), 147 deletions(-)
diff --git a/drivers/bcma/driver_pci.c b/drivers/bcma/driver_pci.c
index c9fd694..50329d1 100644
--- a/drivers/bcma/driver_pci.c
+++ b/drivers/bcma/driver_pci.c
@@ -210,25 +210,6 @@ static void bcma_core_pci_config_fixup(struct bcma_drv_pci *pc)
}
}
-static void bcma_core_pci_power_save(struct bcma_drv_pci *pc, bool up)
-{
- u16 data;
-
- if (pc->core->id.rev >= 15 && pc->core->id.rev <= 20) {
- data = up ? 0x74 : 0x7C;
- bcma_pcie_mdio_writeread(pc, BCMA_CORE_PCI_MDIO_BLK1,
- BCMA_CORE_PCI_MDIO_BLK1_MGMT1, 0x7F64);
- bcma_pcie_mdio_writeread(pc, BCMA_CORE_PCI_MDIO_BLK1,
- BCMA_CORE_PCI_MDIO_BLK1_MGMT3, data);
- } else if (pc->core->id.rev >= 21 && pc->core->id.rev <= 22) {
- data = up ? 0x75 : 0x7D;
- bcma_pcie_mdio_writeread(pc, BCMA_CORE_PCI_MDIO_BLK1,
- BCMA_CORE_PCI_MDIO_BLK1_MGMT1, 0x7E65);
- bcma_pcie_mdio_writeread(pc, BCMA_CORE_PCI_MDIO_BLK1,
- BCMA_CORE_PCI_MDIO_BLK1_MGMT3, data);
- }
-}
-
/**************************************************
* Init.
**************************************************/
@@ -255,6 +236,32 @@ void bcma_core_pci_init(struct bcma_drv_pci *pc)
bcma_core_pci_clientmode_init(pc);
}
+void bcma_core_pci_power_save(struct bcma_bus *bus, bool up)
+{
+ struct bcma_drv_pci *pc;
+ u16 data;
+
+ if (bus->hosttype != BCMA_HOSTTYPE_PCI)
+ return;
+
+ pc = &bus->drv_pci[0];
+
+ if (pc->core->id.rev >= 15 && pc->core->id.rev <= 20) {
+ data = up ? 0x74 : 0x7C;
+ bcma_pcie_mdio_writeread(pc, BCMA_CORE_PCI_MDIO_BLK1,
+ BCMA_CORE_PCI_MDIO_BLK1_MGMT1, 0x7F64);
+ bcma_pcie_mdio_writeread(pc, BCMA_CORE_PCI_MDIO_BLK1,
+ BCMA_CORE_PCI_MDIO_BLK1_MGMT3, data);
+ } else if (pc->core->id.rev >= 21 && pc->core->id.rev <= 22) {
+ data = up ? 0x75 : 0x7D;
+ bcma_pcie_mdio_writeread(pc, BCMA_CORE_PCI_MDIO_BLK1,
+ BCMA_CORE_PCI_MDIO_BLK1_MGMT1, 0x7E65);
+ bcma_pcie_mdio_writeread(pc, BCMA_CORE_PCI_MDIO_BLK1,
+ BCMA_CORE_PCI_MDIO_BLK1_MGMT3, data);
+ }
+}
+EXPORT_SYMBOL_GPL(bcma_core_pci_power_save);
+
int bcma_core_pci_irq_ctl(struct bcma_drv_pci *pc, struct bcma_device *core,
bool enable)
{
@@ -310,8 +317,6 @@ void bcma_core_pci_up(struct bcma_bus *bus)
pc = &bus->drv_pci[0];
- bcma_core_pci_power_save(pc, true);
-
bcma_core_pci_extend_L1timer(pc, true);
}
EXPORT_SYMBOL_GPL(bcma_core_pci_up);
@@ -326,7 +331,5 @@ void bcma_core_pci_down(struct bcma_bus *bus)
pc = &bus->drv_pci[0];
bcma_core_pci_extend_L1timer(pc, false);
-
- bcma_core_pci_power_save(pc, false);
}
EXPORT_SYMBOL_GPL(bcma_core_pci_down);
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index a12b923..0a327f4 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -85,6 +85,7 @@ static struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x04CA, 0x3008) },
{ USB_DEVICE(0x13d3, 0x3362) },
{ USB_DEVICE(0x0CF3, 0xE004) },
+ { USB_DEVICE(0x0CF3, 0xE005) },
{ USB_DEVICE(0x0930, 0x0219) },
{ USB_DEVICE(0x0489, 0xe057) },
{ USB_DEVICE(0x13d3, 0x3393) },
@@ -126,6 +127,7 @@ static struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0cf3, 0xe005), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 8e16f0a..f3dfc0a 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -102,6 +102,7 @@ static struct usb_device_id btusb_table[] = {
/* Broadcom BCM20702A0 */
{ USB_DEVICE(0x0b05, 0x17b5) },
+ { USB_DEVICE(0x0b05, 0x17cb) },
{ USB_DEVICE(0x04ca, 0x2003) },
{ USB_DEVICE(0x0489, 0xe042) },
{ USB_DEVICE(0x413c, 0x8197) },
@@ -112,6 +113,9 @@ static struct usb_device_id btusb_table[] = {
/*Broadcom devices with vendor specific id */
{ USB_VENDOR_AND_INTERFACE_INFO(0x0a5c, 0xff, 0x01, 0x01) },
+ /* Belkin F8065bf - Broadcom based */
+ { USB_VENDOR_AND_INTERFACE_INFO(0x050d, 0xff, 0x01, 0x01) },
+
{ } /* Terminating entry */
};
@@ -148,6 +152,7 @@ static struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0cf3, 0xe005), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 4ee472a..ab9e3a8 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -1270,13 +1270,6 @@ static void ath9k_antenna_check(struct ath_softc *sc,
return;
/*
- * All MPDUs in an aggregate will use the same LNA
- * as the first MPDU.
- */
- if (rs->rs_isaggr && !rs->rs_firstaggr)
- return;
-
- /*
* Change the default rx antenna if rx diversity
* chooses the other antenna 3 times in a row.
*/
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 35b515f..5ac713d 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -399,6 +399,7 @@ static struct ath_buf* ath_clone_txbuf(struct ath_softc *sc, struct ath_buf *bf)
tbf->bf_buf_addr = bf->bf_buf_addr;
memcpy(tbf->bf_desc, bf->bf_desc, sc->sc_ah->caps.tx_desc_len);
tbf->bf_state = bf->bf_state;
+ tbf->bf_state.stale = false;
return tbf;
}
@@ -1389,11 +1390,15 @@ int ath_tx_aggr_start(struct ath_softc *sc, struct ieee80211_sta *sta,
u16 tid, u16 *ssn)
{
struct ath_atx_tid *txtid;
+ struct ath_txq *txq;
struct ath_node *an;
u8 density;
an = (struct ath_node *)sta->drv_priv;
txtid = ATH_AN_2_TID(an, tid);
+ txq = txtid->ac->txq;
+
+ ath_txq_lock(sc, txq);
/* update ampdu factor/density, they may have changed. This may happen
* in HT IBSS when a beacon with HT-info is received after the station
@@ -1417,6 +1422,8 @@ int ath_tx_aggr_start(struct ath_softc *sc, struct ieee80211_sta *sta,
memset(txtid->tx_buf, 0, sizeof(txtid->tx_buf));
txtid->baw_head = txtid->baw_tail = 0;
+ ath_txq_unlock_complete(sc, txq);
+
return 0;
}
@@ -1555,8 +1562,10 @@ void ath9k_release_buffered_frames(struct ieee80211_hw *hw,
__skb_unlink(bf->bf_mpdu, tid_q);
list_add_tail(&bf->list, &bf_q);
ath_set_rates(tid->an->vif, tid->an->sta, bf);
- ath_tx_addto_baw(sc, tid, bf);
- bf->bf_state.bf_type &= ~BUF_AGGR;
+ if (bf_isampdu(bf)) {
+ ath_tx_addto_baw(sc, tid, bf);
+ bf->bf_state.bf_type &= ~BUF_AGGR;
+ }
if (bf_tail)
bf_tail->bf_next = bf;
@@ -1950,7 +1959,9 @@ static void ath_tx_txqaddbuf(struct ath_softc *sc, struct ath_txq *txq,
if (bf_is_ampdu_not_probing(bf))
txq->axq_ampdu_depth++;
- bf = bf->bf_lastbf->bf_next;
+ bf_last = bf->bf_lastbf;
+ bf = bf_last->bf_next;
+ bf_last->bf_next = NULL;
}
}
}
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c
index 64f4a2b..c3462b7 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c
@@ -464,8 +464,6 @@ static struct sdio_driver brcmf_sdmmc_driver = {
static int brcmf_sdio_pd_probe(struct platform_device *pdev)
{
- int ret;
-
brcmf_dbg(SDIO, "Enter\n");
brcmfmac_sdio_pdata = pdev->dev.platform_data;
@@ -473,11 +471,7 @@ static int brcmf_sdio_pd_probe(struct platform_device *pdev)
if (brcmfmac_sdio_pdata->power_on)
brcmfmac_sdio_pdata->power_on();
- ret = sdio_register_driver(&brcmf_sdmmc_driver);
- if (ret)
- brcmf_err("sdio_register_driver failed: %d\n", ret);
-
- return ret;
+ return 0;
}
static int brcmf_sdio_pd_remove(struct platform_device *pdev)
@@ -500,6 +494,15 @@ static struct platform_driver brcmf_sdio_pd = {
}
};
+void brcmf_sdio_register(void)
+{
+ int ret;
+
+ ret = sdio_register_driver(&brcmf_sdmmc_driver);
+ if (ret)
+ brcmf_err("sdio_register_driver failed: %d\n", ret);
+}
+
void brcmf_sdio_exit(void)
{
brcmf_dbg(SDIO, "Enter\n");
@@ -510,18 +513,13 @@ void brcmf_sdio_exit(void)
sdio_unregister_driver(&brcmf_sdmmc_driver);
}
-void brcmf_sdio_init(void)
+void __init brcmf_sdio_init(void)
{
int ret;
brcmf_dbg(SDIO, "Enter\n");
ret = platform_driver_probe(&brcmf_sdio_pd, brcmf_sdio_pd_probe);
- if (ret == -ENODEV) {
- brcmf_dbg(SDIO, "No platform data available, registering without.\n");
- ret = sdio_register_driver(&brcmf_sdmmc_driver);
- }
-
- if (ret)
- brcmf_err("driver registration failed: %d\n", ret);
+ if (ret == -ENODEV)
+ brcmf_dbg(SDIO, "No platform data available.\n");
}
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h b/drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h
index f7c1985..74156f8 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h
+++ b/drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h
@@ -156,10 +156,11 @@ extern int brcmf_bus_start(struct device *dev);
#ifdef CONFIG_BRCMFMAC_SDIO
extern void brcmf_sdio_exit(void);
extern void brcmf_sdio_init(void);
+extern void brcmf_sdio_register(void);
#endif
#ifdef CONFIG_BRCMFMAC_USB
extern void brcmf_usb_exit(void);
-extern void brcmf_usb_init(void);
+extern void brcmf_usb_register(void);
#endif
#endif /* _BRCMF_BUS_H_ */
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c b/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
index e067aec..40e7f85 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
@@ -1231,21 +1231,23 @@ u32 brcmf_get_chip_info(struct brcmf_if *ifp)
return bus->chip << 4 | bus->chiprev;
}
-static void brcmf_driver_init(struct work_struct *work)
+static void brcmf_driver_register(struct work_struct *work)
{
- brcmf_debugfs_init();
-
#ifdef CONFIG_BRCMFMAC_SDIO
- brcmf_sdio_init();
+ brcmf_sdio_register();
#endif
#ifdef CONFIG_BRCMFMAC_USB
- brcmf_usb_init();
+ brcmf_usb_register();
#endif
}
-static DECLARE_WORK(brcmf_driver_work, brcmf_driver_init);
+static DECLARE_WORK(brcmf_driver_work, brcmf_driver_register);
static int __init brcmfmac_module_init(void)
{
+ brcmf_debugfs_init();
+#ifdef CONFIG_BRCMFMAC_SDIO
+ brcmf_sdio_init();
+#endif
if (!schedule_work(&brcmf_driver_work))
return -EBUSY;
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
index 39e01a7..f4aea47 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
@@ -1539,7 +1539,7 @@ void brcmf_usb_exit(void)
brcmf_release_fw(&fw_image_list);
}
-void brcmf_usb_init(void)
+void brcmf_usb_register(void)
{
brcmf_dbg(USB, "Enter\n");
INIT_LIST_HEAD(&fw_image_list);
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
index 3a65447..edc5d10 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
@@ -457,6 +457,8 @@ static int brcms_ops_start(struct ieee80211_hw *hw)
if (err != 0)
brcms_err(wl->wlc->hw->d11core, "%s: brcms_up() returned %d\n",
__func__, err);
+
+ bcma_core_pci_power_save(wl->wlc->hw->d11core->bus, true);
return err;
}
@@ -479,6 +481,8 @@ static void brcms_ops_stop(struct ieee80211_hw *hw)
return;
}
+ bcma_core_pci_power_save(wl->wlc->hw->d11core->bus, false);
+
/* put driver in down state */
spin_lock_bh(&wl->lock);
brcms_down(wl);
diff --git a/drivers/net/wireless/cw1200/cw1200_spi.c b/drivers/net/wireless/cw1200/cw1200_spi.c
index f5e6b48..899cad3 100644
--- a/drivers/net/wireless/cw1200/cw1200_spi.c
+++ b/drivers/net/wireless/cw1200/cw1200_spi.c
@@ -42,7 +42,6 @@ struct hwbus_priv {
spinlock_t lock; /* Serialize all bus operations */
wait_queue_head_t wq;
int claimed;
- int irq_disabled;
};
#define SDIO_TO_SPI_ADDR(addr) ((addr & 0x1f)>>2)
@@ -238,8 +237,6 @@ static irqreturn_t cw1200_spi_irq_handler(int irq, void *dev_id)
struct hwbus_priv *self = dev_id;
if (self->core) {
- disable_irq_nosync(self->func->irq);
- self->irq_disabled = 1;
cw1200_irq_handler(self->core);
return IRQ_HANDLED;
} else {
@@ -253,9 +250,10 @@ static int cw1200_spi_irq_subscribe(struct hwbus_priv *self)
pr_debug("SW IRQ subscribe\n");
- ret = request_any_context_irq(self->func->irq, cw1200_spi_irq_handler,
- IRQF_TRIGGER_HIGH,
- "cw1200_wlan_irq", self);
+ ret = request_threaded_irq(self->func->irq, NULL,
+ cw1200_spi_irq_handler,
+ IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
+ "cw1200_wlan_irq", self);
if (WARN_ON(ret < 0))
goto exit;
@@ -273,22 +271,13 @@ exit:
static int cw1200_spi_irq_unsubscribe(struct hwbus_priv *self)
{
+ int ret = 0;
+
pr_debug("SW IRQ unsubscribe\n");
disable_irq_wake(self->func->irq);
free_irq(self->func->irq, self);
- return 0;
-}
-
-static int cw1200_spi_irq_enable(struct hwbus_priv *self, int enable)
-{
- /* Disables are handled by the interrupt handler */
- if (enable && self->irq_disabled) {
- enable_irq(self->func->irq);
- self->irq_disabled = 0;
- }
-
- return 0;
+ return ret;
}
static int cw1200_spi_off(const struct cw1200_platform_data_spi *pdata)
@@ -368,7 +357,6 @@ static struct hwbus_ops cw1200_spi_hwbus_ops = {
.unlock = cw1200_spi_unlock,
.align_size = cw1200_spi_align_size,
.power_mgmt = cw1200_spi_pm,
- .irq_enable = cw1200_spi_irq_enable,
};
/* Probe Function to be called by SPI stack when device is discovered */
diff --git a/drivers/net/wireless/cw1200/fwio.c b/drivers/net/wireless/cw1200/fwio.c
index 0b2061b..acdff0f 100644
--- a/drivers/net/wireless/cw1200/fwio.c
+++ b/drivers/net/wireless/cw1200/fwio.c
@@ -485,7 +485,7 @@ int cw1200_load_firmware(struct cw1200_common *priv)
/* Enable interrupt signalling */
priv->hwbus_ops->lock(priv->hwbus_priv);
- ret = __cw1200_irq_enable(priv, 2);
+ ret = __cw1200_irq_enable(priv, 1);
priv->hwbus_ops->unlock(priv->hwbus_priv);
if (ret < 0)
goto unsubscribe;
diff --git a/drivers/net/wireless/cw1200/hwbus.h b/drivers/net/wireless/cw1200/hwbus.h
index 51dfb3a..8b2fc83 100644
--- a/drivers/net/wireless/cw1200/hwbus.h
+++ b/drivers/net/wireless/cw1200/hwbus.h
@@ -28,7 +28,6 @@ struct hwbus_ops {
void (*unlock)(struct hwbus_priv *self);
size_t (*align_size)(struct hwbus_priv *self, size_t size);
int (*power_mgmt)(struct hwbus_priv *self, bool suspend);
- int (*irq_enable)(struct hwbus_priv *self, int enable);
};
#endif /* CW1200_HWBUS_H */
diff --git a/drivers/net/wireless/cw1200/hwio.c b/drivers/net/wireless/cw1200/hwio.c
index 41bd761..ff230b7 100644
--- a/drivers/net/wireless/cw1200/hwio.c
+++ b/drivers/net/wireless/cw1200/hwio.c
@@ -273,21 +273,6 @@ int __cw1200_irq_enable(struct cw1200_common *priv, int enable)
u16 val16;
int ret;
- /* We need to do this hack because the SPI layer can sleep on I/O
- and the general path involves I/O to the device in interrupt
- context.
-
- However, the initial enable call needs to go to the hardware.
-
- We don't worry about shutdown because we do a full reset which
- clears the interrupt enabled bits.
- */
- if (priv->hwbus_ops->irq_enable) {
- ret = priv->hwbus_ops->irq_enable(priv->hwbus_priv, enable);
- if (ret || enable < 2)
- return ret;
- }
-
if (HIF_8601_SILICON == priv->hw_type) {
ret = __cw1200_reg_read_32(priv, ST90TDS_CONFIG_REG_ID, &val32);
if (ret < 0) {
diff --git a/drivers/net/wireless/mwifiex/11n_aggr.c b/drivers/net/wireless/mwifiex/11n_aggr.c
index 21c6882..1214c58 100644
--- a/drivers/net/wireless/mwifiex/11n_aggr.c
+++ b/drivers/net/wireless/mwifiex/11n_aggr.c
@@ -150,7 +150,7 @@ mwifiex_11n_form_amsdu_txpd(struct mwifiex_private *priv,
*/
int
mwifiex_11n_aggregate_pkt(struct mwifiex_private *priv,
- struct mwifiex_ra_list_tbl *pra_list, int headroom,
+ struct mwifiex_ra_list_tbl *pra_list,
int ptrindex, unsigned long ra_list_flags)
__releases(&priv->wmm.ra_list_spinlock)
{
@@ -160,6 +160,7 @@ mwifiex_11n_aggregate_pkt(struct mwifiex_private *priv,
int pad = 0, ret;
struct mwifiex_tx_param tx_param;
struct txpd *ptx_pd = NULL;
+ int headroom = adapter->iface_type == MWIFIEX_USB ? 0 : INTF_HEADER_LEN;
skb_src = skb_peek(&pra_list->skb_head);
if (!skb_src) {
diff --git a/drivers/net/wireless/mwifiex/11n_aggr.h b/drivers/net/wireless/mwifiex/11n_aggr.h
index 900e1c6..892098d 100644
--- a/drivers/net/wireless/mwifiex/11n_aggr.h
+++ b/drivers/net/wireless/mwifiex/11n_aggr.h
@@ -26,7 +26,7 @@
int mwifiex_11n_deaggregate_pkt(struct mwifiex_private *priv,
struct sk_buff *skb);
int mwifiex_11n_aggregate_pkt(struct mwifiex_private *priv,
- struct mwifiex_ra_list_tbl *ptr, int headroom,
+ struct mwifiex_ra_list_tbl *ptr,
int ptr_index, unsigned long flags)
__releases(&priv->wmm.ra_list_spinlock);
diff --git a/drivers/net/wireless/mwifiex/cmdevt.c b/drivers/net/wireless/mwifiex/cmdevt.c
index 2d76147..a6c46f3 100644
--- a/drivers/net/wireless/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/mwifiex/cmdevt.c
@@ -1155,7 +1155,7 @@ int mwifiex_ret_802_11_hs_cfg(struct mwifiex_private *priv,
uint32_t conditions = le32_to_cpu(phs_cfg->params.hs_config.conditions);
if (phs_cfg->action == cpu_to_le16(HS_ACTIVATE) &&
- adapter->iface_type == MWIFIEX_SDIO) {
+ adapter->iface_type != MWIFIEX_USB) {
mwifiex_hs_activated_event(priv, true);
return 0;
} else {
@@ -1167,8 +1167,7 @@ int mwifiex_ret_802_11_hs_cfg(struct mwifiex_private *priv,
}
if (conditions != HS_CFG_CANCEL) {
adapter->is_hs_configured = true;
- if (adapter->iface_type == MWIFIEX_USB ||
- adapter->iface_type == MWIFIEX_PCIE)
+ if (adapter->iface_type == MWIFIEX_USB)
mwifiex_hs_activated_event(priv, true);
} else {
adapter->is_hs_configured = false;
diff --git a/drivers/net/wireless/mwifiex/usb.c b/drivers/net/wireless/mwifiex/usb.c
index 2472d4b..1c70b8d 100644
--- a/drivers/net/wireless/mwifiex/usb.c
+++ b/drivers/net/wireless/mwifiex/usb.c
@@ -447,9 +447,6 @@ static int mwifiex_usb_suspend(struct usb_interface *intf, pm_message_t message)
*/
adapter->is_suspended = true;
- for (i = 0; i < adapter->priv_num; i++)
- netif_carrier_off(adapter->priv[i]->netdev);
-
if (atomic_read(&card->rx_cmd_urb_pending) && card->rx_cmd.urb)
usb_kill_urb(card->rx_cmd.urb);
@@ -509,10 +506,6 @@ static int mwifiex_usb_resume(struct usb_interface *intf)
MWIFIEX_RX_CMD_BUF_SIZE);
}
- for (i = 0; i < adapter->priv_num; i++)
- if (adapter->priv[i]->media_connected)
- netif_carrier_on(adapter->priv[i]->netdev);
-
/* Disable Host Sleep */
if (adapter->hs_activated)
mwifiex_cancel_hs(mwifiex_get_priv(adapter,
diff --git a/drivers/net/wireless/mwifiex/wmm.c b/drivers/net/wireless/mwifiex/wmm.c
index 2e8f9cd..95fa359 100644
--- a/drivers/net/wireless/mwifiex/wmm.c
+++ b/drivers/net/wireless/mwifiex/wmm.c
@@ -1239,8 +1239,7 @@ mwifiex_dequeue_tx_packet(struct mwifiex_adapter *adapter)
if (enable_tx_amsdu && mwifiex_is_amsdu_allowed(priv, tid) &&
mwifiex_is_11n_aggragation_possible(priv, ptr,
adapter->tx_buf_size))
- mwifiex_11n_aggregate_pkt(priv, ptr, INTF_HEADER_LEN,
- ptr_index, flags);
+ mwifiex_11n_aggregate_pkt(priv, ptr, ptr_index, flags);
/* ra_list_spinlock has been freed in
mwifiex_11n_aggregate_pkt() */
else
diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
index b9deef6..e328d30 100644
--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -83,6 +83,7 @@ static struct usb_device_id p54u_table[] = {
{USB_DEVICE(0x06a9, 0x000e)}, /* Westell 802.11g USB (A90-211WG-01) */
{USB_DEVICE(0x06b9, 0x0121)}, /* Thomson SpeedTouch 121g */
{USB_DEVICE(0x0707, 0xee13)}, /* SMC 2862W-G version 2 */
+ {USB_DEVICE(0x07aa, 0x0020)}, /* Corega WLUSB2GTST USB */
{USB_DEVICE(0x0803, 0x4310)}, /* Zoom 4410a */
{USB_DEVICE(0x083a, 0x4521)}, /* Siemens Gigaset USB Adapter 54 version 2 */
{USB_DEVICE(0x083a, 0x4531)}, /* T-Com Sinus 154 data II */
@@ -979,6 +980,7 @@ static int p54u_load_firmware(struct ieee80211_hw *dev,
if (err) {
dev_err(&priv->udev->dev, "(p54usb) cannot load firmware %s "
"(%d)!\n", p54u_fwlist[i].fw, err);
+ usb_put_dev(udev);
}
return err;
diff --git a/drivers/net/wireless/rtlwifi/wifi.h b/drivers/net/wireless/rtlwifi/wifi.h
index cc03e7c..7032587 100644
--- a/drivers/net/wireless/rtlwifi/wifi.h
+++ b/drivers/net/wireless/rtlwifi/wifi.h
@@ -2057,7 +2057,7 @@ struct rtl_priv {
that it points to the data allocated
beyond this structure like:
rtl_pci_priv or rtl_usb_priv */
- u8 priv[0];
+ u8 priv[0] __aligned(sizeof(void *));
};
#define rtl_priv(hw) (((struct rtl_priv *)(hw)->priv))
diff --git a/include/linux/bcma/bcma_driver_pci.h b/include/linux/bcma/bcma_driver_pci.h
index d66033f..0333e60 100644
--- a/include/linux/bcma/bcma_driver_pci.h
+++ b/include/linux/bcma/bcma_driver_pci.h
@@ -242,6 +242,7 @@ extern int bcma_core_pci_irq_ctl(struct bcma_drv_pci *pc,
struct bcma_device *core, bool enable);
extern void bcma_core_pci_up(struct bcma_bus *bus);
extern void bcma_core_pci_down(struct bcma_bus *bus);
+extern void bcma_core_pci_power_save(struct bcma_bus *bus, bool up);
extern int bcma_core_pci_pcibios_map_irq(const struct pci_dev *dev);
extern int bcma_core_pci_plat_dev_init(struct pci_dev *dev);
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index aaeaf09..15f1084 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -104,6 +104,7 @@ enum {
enum {
HCI_SETUP,
HCI_AUTO_OFF,
+ HCI_RFKILLED,
HCI_MGMT,
HCI_PAIRABLE,
HCI_SERVICE_CACHE,
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 634deba..fb7356f 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1146,7 +1146,11 @@ int hci_dev_open(__u16 dev)
goto done;
}
- if (hdev->rfkill && rfkill_blocked(hdev->rfkill)) {
+ /* Check for rfkill but allow the HCI setup stage to proceed
+ * (which in itself doesn't cause any RF activity).
+ */
+ if (test_bit(HCI_RFKILLED, &hdev->dev_flags) &&
+ !test_bit(HCI_SETUP, &hdev->dev_flags)) {
ret = -ERFKILL;
goto done;
}
@@ -1566,10 +1570,13 @@ static int hci_rfkill_set_block(void *data, bool blocked)
BT_DBG("%p name %s blocked %d", hdev, hdev->name, blocked);
- if (!blocked)
- return 0;
-
- hci_dev_do_close(hdev);
+ if (blocked) {
+ set_bit(HCI_RFKILLED, &hdev->dev_flags);
+ if (!test_bit(HCI_SETUP, &hdev->dev_flags))
+ hci_dev_do_close(hdev);
+ } else {
+ clear_bit(HCI_RFKILLED, &hdev->dev_flags);
+ }
return 0;
}
@@ -1591,9 +1598,13 @@ static void hci_power_on(struct work_struct *work)
return;
}
- if (test_bit(HCI_AUTO_OFF, &hdev->dev_flags))
+ if (test_bit(HCI_RFKILLED, &hdev->dev_flags)) {
+ clear_bit(HCI_AUTO_OFF, &hdev->dev_flags);
+ hci_dev_do_close(hdev);
+ } else if (test_bit(HCI_AUTO_OFF, &hdev->dev_flags)) {
queue_delayed_work(hdev->req_workqueue, &hdev->power_off,
HCI_AUTO_OFF_TIMEOUT);
+ }
if (test_and_clear_bit(HCI_SETUP, &hdev->dev_flags))
mgmt_index_added(hdev);
@@ -2209,6 +2220,9 @@ int hci_register_dev(struct hci_dev *hdev)
}
}
+ if (hdev->rfkill && rfkill_blocked(hdev->rfkill))
+ set_bit(HCI_RFKILLED, &hdev->dev_flags);
+
set_bit(HCI_SETUP, &hdev->dev_flags);
if (hdev->dev_type != HCI_AMP)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 94aab73..8db3e89 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -3557,7 +3557,11 @@ static void hci_le_ltk_request_evt(struct hci_dev *hdev, struct sk_buff *skb)
cp.handle = cpu_to_le16(conn->handle);
if (ltk->authenticated)
- conn->sec_level = BT_SECURITY_HIGH;
+ conn->pending_sec_level = BT_SECURITY_HIGH;
+ else
+ conn->pending_sec_level = BT_SECURITY_MEDIUM;
+
+ conn->enc_key_size = ltk->enc_size;
hci_send_cmd(hdev, HCI_OP_LE_LTK_REPLY, sizeof(cp), &cp);
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index b3bb7bc..63fa111 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -3755,6 +3755,13 @@ static struct l2cap_chan *l2cap_connect(struct l2cap_conn *conn,
sk = chan->sk;
+ /* For certain devices (ex: HID mouse), support for authentication,
+ * pairing and bonding is optional. For such devices, inorder to avoid
+ * the ACL alive for too long after L2CAP disconnection, reset the ACL
+ * disc_timeout back to HCI_DISCONN_TIMEOUT during L2CAP connect.
+ */
+ conn->hcon->disc_timeout = HCI_DISCONN_TIMEOUT;
+
bacpy(&bt_sk(sk)->src, conn->src);
bacpy(&bt_sk(sk)->dst, conn->dst);
chan->psm = psm;
diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
index 6d126fa..84fcf9f 100644
--- a/net/bluetooth/rfcomm/tty.c
+++ b/net/bluetooth/rfcomm/tty.c
@@ -569,7 +569,6 @@ static void rfcomm_dev_data_ready(struct rfcomm_dlc *dlc, struct sk_buff *skb)
static void rfcomm_dev_state_change(struct rfcomm_dlc *dlc, int err)
{
struct rfcomm_dev *dev = dlc->owner;
- struct tty_struct *tty;
if (!dev)
return;
@@ -581,38 +580,8 @@ static void rfcomm_dev_state_change(struct rfcomm_dlc *dlc, int err)
DPM_ORDER_DEV_AFTER_PARENT);
wake_up_interruptible(&dev->port.open_wait);
- } else if (dlc->state == BT_CLOSED) {
- tty = tty_port_tty_get(&dev->port);
- if (!tty) {
- if (test_bit(RFCOMM_RELEASE_ONHUP, &dev->flags)) {
- /* Drop DLC lock here to avoid deadlock
- * 1. rfcomm_dev_get will take rfcomm_dev_lock
- * but in rfcomm_dev_add there's lock order:
- * rfcomm_dev_lock -> dlc lock
- * 2. tty_port_put will deadlock if it's
- * the last reference
- *
- * FIXME: when we release the lock anything
- * could happen to dev, even its destruction
- */
- rfcomm_dlc_unlock(dlc);
- if (rfcomm_dev_get(dev->id) == NULL) {
- rfcomm_dlc_lock(dlc);
- return;
- }
-
- if (!test_and_set_bit(RFCOMM_TTY_RELEASED,
- &dev->flags))
- tty_port_put(&dev->port);
-
- tty_port_put(&dev->port);
- rfcomm_dlc_lock(dlc);
- }
- } else {
- tty_hangup(tty);
- tty_kref_put(tty);
- }
- }
+ } else if (dlc->state == BT_CLOSED)
+ tty_port_tty_hangup(&dev->port, false);
}
static void rfcomm_dev_modem_status(struct rfcomm_dlc *dlc, u8 v24_sig)
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: [PATCH net 0/4] bridge: Fix problems around the PVID
From: Vlad Yasevich @ 2013-09-27 18:10 UTC (permalink / raw)
To: Toshiaki Makita
Cc: Toshiaki Makita, David Miller, netdev, Fernando Luis Vazquez Cao,
Patrick McHardy
In-Reply-To: <1380301914.1734.63.camel@localhost.localdomain>
On 09/27/2013 01:11 PM, Toshiaki Makita wrote:
> On Thu, 2013-09-26 at 10:22 -0400, Vlad Yasevich wrote:
>> On 09/26/2013 06:38 AM, Toshiaki Makita wrote:
>>> On Tue, 2013-09-24 at 13:55 -0400, Vlad Yasevich wrote:
>>>> On 09/24/2013 01:30 PM, Toshiaki Makita wrote:
>>>>> On Tue, 2013-09-24 at 09:35 -0400, Vlad Yasevich wrote:
>>>>>> On 09/24/2013 07:45 AM, Toshiaki Makita wrote:
>>>>>>> On Mon, 2013-09-23 at 10:41 -0400, Vlad Yasevich wrote:
>>>>>>>> On 09/17/2013 04:12 AM, Toshiaki Makita wrote:
>>>>>>>>> On Mon, 2013-09-16 at 13:49 -0400, Vlad Yasevich wrote:
>>>>>>>>>> On 09/13/2013 08:06 AM, Toshiaki Makita wrote:
>>>>>>>>>>> On Thu, 2013-09-12 at 16:00 -0400, David Miller wrote:
>>>>>>>>>>>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>>>>>>>>>> Date: Tue, 10 Sep 2013 19:27:54 +0900
>>>>>>>>>>>>
>>>>>>>>>>>>> There seem to be some undesirable behaviors related with PVID.
>>>>>>>>>>>>> 1. It has no effect assigning PVID to a port. PVID cannot be applied
>>>>>>>>>>>>> to any frame regardless of whether we set it or not.
>>>>>>>>>>>>> 2. FDB entries learned via frames applied PVID are registered with
>>>>>>>>>>>>> VID 0 rather than VID value of PVID.
>>>>>>>>>>>>> 3. We can set 0 or 4095 as a PVID that are not allowed in IEEE 802.1Q.
>>>>>>>>>>>>> This leads interoperational problems such as sending frames with VID
>>>>>>>>>>>>> 4095, which is not allowed in IEEE 802.1Q, and treating frames with VID
>>>>>>>>>>>>> 0 as they belong to VLAN 0, which is expected to be handled as they have
>>>>>>>>>>>>> no VID according to IEEE 802.1Q.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Note: 2nd and 3rd problems are potential and not exposed unless 1st problem
>>>>>>>>>>>>> is fixed, because we cannot activate PVID due to it.
>>>>>>>>>>>>
>>>>>>>>>>>> Please work out the issues in patch #2 with Vlad and resubmit this
>>>>>>>>>>>> series.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you.
>>>>>>>>>>>
>>>>>>>>>>> I'm hovering between whether we should fix the issue by changing vlan 0
>>>>>>>>>>> interface behavior in 8021q module or enabling a bridge port to sending
>>>>>>>>>>> priority-tagged frames, or another better way.
>>>>>>>>>>>
>>>>>>>>>>> If you could comment it, I'd appreciate it :)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> BTW, I think what is discussed in patch #2 is another problem about
>>>>>>>>>>> handling priority-tags, and it exists without this patch set applied.
>>>>>>>>>>> It looks like that we should prepare another patch set than this to fix
>>>>>>>>>>> that problem.
>>>>>>>>>>>
>>>>>>>>>>> Should I include patches that fix the priority-tags problem in this
>>>>>>>>>>> patch set and resubmit them all together?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I am thinking that we might need to do it in bridge and it looks like
>>>>>>>>>> the simplest way to do it is to have default priority regeneration table
>>>>>>>>>> (table 6-5 from 802.1Q doc).
>>>>>>>>>>
>>>>>>>>>> That way I think we would conform to the spec.
>>>>>>>>>>
>>>>>>>>>> -vlad
>>>>>>>>>
>>>>>>>>> Unfortunately I don't think the default priority regeneration table
>>>>>>>>> resolves the problem because IEEE 802.1Q says that a VLAN-aware bridge
>>>>>>>>> can transmit untagged or VLAN-tagged frames only (the end of section 7.5
>>>>>>>>> and 8.1.7).
>>>>>>>>>
>>>>>>>>> No mechanism to send priority-tagged frames is found as far as I can see
>>>>>>>>> the standard. I think the regenerated priority is used for outgoing PCP
>>>>>>>>> field only if egress policy is not untagged (i.e. transmitting as
>>>>>>>>> VLAN-tagged), and unused if untagged (Section 6.9.2 3rd/4th Paragraph).
>>>>>>>>>
>>>>>>>>> If we want to transmit priority-tagged frames from a bridge port, I
>>>>>>>>> think we need to implement a new (optional) feature that is above the
>>>>>>>>> standard, as I stated previously.
>>>>>>>>>
>>>>>>>>> How do you feel about adding a per-port policy that enables a bridge to
>>>>>>>>> send priority-tagged frames instead of untagged frames when egress
>>>>>>>>> policy for the port is untagged?
>>>>>>>>> With this change, we can transmit frames for a given vlan as either all
>>>>>>>>> untagged, all priority-tagged or all VLAN-tagged.
>>>>>>>>
>>>>>>>> That would work. What I am thinking is that we do it by special casing
>>>>>>>> the vid 0 egress policy specification. Let it be untagged by default
>>>>>>>> and if it is tagged, then we preserve the priority field and forward
>>>>>>>> it on.
>>>>>>>>
>>>>>>>> This keeps the API stable and doesn't require user/admin from knowing
>>>>>>>> exactly what happens. Default operation conforms to the spec and allows
>>>>>>>> simple change to make it backward-compatible.
>>>>>>>>
>>>>>>>> What do you think. I've done a simple prototype of this an it seems to
>>>>>>>> work with the VMs I am testing with.
>>>>>>>
>>>>>>> Are you saying that
>>>>>>> - by default, set the 0th bit of untagged_bitmap; and
>>>>>>> - if we unset the 0th bit and set the "vid"th bit, we transmit frames
>>>>>>> classified as belonging to VLAN "vid" as priority-tagged?
>>>>>>>
>>>>>>> If so, though it's attractive to keep current API, I'm worried about if
>>>>>>> it could be a bit confusing and not intuitive for kernel/iproute2
>>>>>>> developers that VID 0 has a special meaning only in the egress policy.
>>>>>>> Wouldn't it be better to adding a new member to struct net_port_vlans
>>>>>>> instead of using VID 0 of untagged_bitmap?
>>>>>>>
>>>>>>> Or are you saying that we use a new flag in struct net_port_vlans but
>>>>>>> use the BRIDGE_VLAN_INFO_UNTAGGED bit with VID 0 in netlink to set the
>>>>>>> flag?
>>>>>>>
>>>>>>> Even in that case, I'm afraid that it might be confusing for developers
>>>>>>> for the same reason. We are going to prohibit to specify VID with 0 (and
>>>>>>> 4095) in adding/deleting a FDB entry or a vlan filtering entry, but it
>>>>>>> would allow us to use VID 0 only when a vlan filtering entry is
>>>>>>> configured.
>>>>>>> I am thinking a new nlattr is a straightforward approach to configure
>>>>>>> it.
>>>>>>
>>>>>> By making this an explicit attribute it makes vid 0 a special case for
>>>>>> any automatic tool that would provision such filtering. Seeing vid 0
>>>>>> would mean that these tools would have to know that this would have to
>>>>>> be translated to a different attribute instead of setting the policy
>>>>>> values.
>>>>>
>>>>> Yes, I agree with you that we can do it by the way you explained.
>>>>> What I don't understand is the advantage of using vid 0 over another way
>>>>> such as adding a new nlattr.
>>>>> I think we can indicate transmitting priority-tags explicitly by such a
>>>>> nlattr. Using vid 0 seems to be easier to implement than a new nlattr,
>>>>> but, for me, it looks less intuitive and more difficult to maintain
>>>>> because we have to care about vid 0 instead of simply ignoring it.
>>>>>
>>>>
>>>> The point I am trying to make is that regardless of the approach someone
>>>> has to know what to do when enabling priority tagged frames. You
>>>> proposal would require the administrator or config tool to have that
>>>> knowledge. Example is:
>>>> Admin does: bridge vlan set priority on dev eth0
>>>> Automated app:
>>>> if (vid == 0)
>>>> /* Turn on priority tagged frame support */
>>>>
>>>> My proposal would require the bridge filtering implementation to have it.
>>>> user tool: bridge vlan add vid 0 tagged
>>>> Automated app: No special case.
>>>>
>>>> IMO its better to have 1 piece code handling the special case then
>>>> putting it multiple places.
>>>
>>> Thank you for the detailed explanation.
>>> Now I understand your intention.
>>>
>>> I have one question about your proposal.
>>> I guess the way to enable priority-tagged is something like
>>> bridge vlan add vid 10 dev eth0
>>> bridge vlan add vid 10 dev vnet0 pvid untagged
>>> bridge vlan add vid 0 dev vnet0 tagged
>>> where vnet0 has sub interface vnet0.0.
>>>
>>> Here the admin have to know the egress policy is applied to a frame
>>> twice in a certain order when it is transmitted from the port vnet0
>>> attached, that is, first, a frame with vid 10 get untagged, and then, an
>>> untagged frame get priority-tagged.
>>>
>>> This behavior looks difficult to know without previous knowledge.
>>> Any good idea to avoid such a need for the admin's additional knowledge?
>>
>> To me, the fact that there is vnet0.0 (or typically, there is eth0.0 in
>> the guest or on the remote host) already tells the admin vlan 0 has to
>> be tagged. The fact that we codify this in the policy makes it explicit.
>
> My worry is that the admin might not be able to guess how to use bridge
> commands to enable priority-tag without any additional hint in "man
> bridge", "bridge vlan help", etc.
> I actually couldn't hit upon such a usage before seeing example commands
> you gave, because I had never think the egress policy could be applied
> twice.
>
>>
>> However, I can see strong argument to be made for an addition egress
>> policy attribute that could be for instance:
>>
>> bridge vlan add vid 10 dev eth0 pvid
>> bridge vlan add vid 10 dev vnet0 pvid untagged prio_tag
>>
>> But this has the same connotations as wrt to egress policy. The 2
>> policies are applied:
>> (1) untag the frame.
>> (2) add priority_tag.
>>
>> (2) only happens if initial fame received on eth0 was priority tagged.
>
> If we do so, we will not be able to communicate using vlan 0 interface
> under a certain circumstance.
> Eth0 can be receive mixed untagged and priority-tagged frames according
> to the network element it is connected to: for example, Open vSwitch can
> send such two kinds of frames from the same port even if original
> incoming frames belong to the same vlan.
Which priority would you assign to the frame that was received untagged?
> In this situation, we can only receive frames that is priority-tagged
> when received on eth0.
Not sure I understand. Let's look at this config:
bridge vlan add vid 10 dev eth0 pvid
bridge vlan add vid 10 dev vnet0 pvid untagged prio_tag
Here, eth0 is allowed to receive vid 10 tagged, untagged, and
prio_tagged (if we look at the patch 2 from this set).
Now, frame is forwarded to vnet0.
1) if the frame had vid 10 in the tag or was untagged,
it should probably be sent untagged.
2) if the frame had a priority tag, it should probably
be sent as such.
Now, I think a case could be made that if the frame had any priority
markings in the vlan header, we should try to preserve those markings
if prio_tag is turned on. We can assume value of 0 means not set.
> IMO, if prio_tag is configured, the bridge should send any untagged
> frame as priority-tagged regardless of whatever it is on eth0.
Which priority would you use, 0? You are not guaranteed to properly
deliver the traffic then for a configuration such as:
VM: eth0: 10.0.0.1/24
eth0.0: 10.0.1.1/24
-vlad
>
>>
>> I think I am ok with either approach. Explicit vid 0 policy is easier
>> for automatic provisioning. The flag based one is easier for admin/
>> manual provisioning.
>
> Supposing we have to add something to help or man in any case, I think
> flag based is better.
> The format below seems to suitable for a per-port policy.
> bridge vlan set prio_tag on dev vnet0
>
> Thanks,
>
> Toshiaki Makita
>
>>
>> -vlad.
>>
>> -vlad
>>
>>
>>
>>
>>>
>>>>
>>>> Thanks
>>>> -vlad
>>>>
>>>>> Thanks,
>>>>>
>>>>> Toshiaki Makita
>>>>>
>>>>>>
>>>>>> How it is implemented internally in the kernel isn't as big of an issue.
>>>>>> We can do it as a separate flag or as part of existing policy.
>>>>>>
>>>>>> -vlad
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Toshiaki Makita
>>>>>>>
>>>>>>>>
>>>>>>>> -vlad
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Toshiaki Makita
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Toshiaki Makita
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>
^ permalink raw reply
* Re: [PATCH 2/2] net: phy: at803x: add suspend/resume callbacks
From: Daniel Mack @ 2013-09-27 18:49 UTC (permalink / raw)
To: Mugunthan V N; +Cc: netdev, davem, ujhelyi.m, sergei.shtylyov
In-Reply-To: <523E877F.4050906@ti.com>
On 22.09.2013 08:00, Mugunthan V N wrote:
> On Saturday 21 September 2013 08:23 PM, Daniel Mack wrote:
>> When WOL is enabled, the chip can't be put into power-down (BMCR_PDOWN)
>> mode, as that will also switch off the MAC, which consequently leads to
>> a link loss.
>>
>> Use BMCR_ISOLATE in that case, which will at least save us some
>> milliamperes in comparison to normal operation mode.
>>
>> Signed-off-by: Daniel Mack <zonque@gmail.com>
> Looks good to me
>
> Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Thanks :)
David, can you take these two patches with Mugunthan's Acked-by: or do
you want me to resend them?
Best regards,
Daniel
^ 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