* RE: INVESTMENT/ RELOCATION ASSISTANCE. 9th/10/2013
From: Jamilahussain @ 2013-10-09 13:22 UTC (permalink / raw)
To: Recipients
Dear Beloved,
I am Mrs. Jamila Hussein a Teacher and a Muslim Convert here in Syria,i had sent a previous mail which i am not sure you got. I need your assistance to invest and assist relocate 3 kids who are 17 years and below so that they can get a better life there in your country due to the on going crises here in Syria.
I need your trust, before the death of their parents they had a savings with an Indian Bank, so money is not the issue.
I got your reference in my search for someone who suits my
purpose.If you can help me reply, let me know.
Regards,
Mrs. Jamila Hussein
=====================================4
^ permalink raw reply
* [PATCH 14/16] batman-adv: reorder packet types
From: Antonio Quartulli @ 2013-10-09 12:40 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Simon Wunderlich, Simon Wunderlich,
Marek Lindner, Antonio Quartulli
In-Reply-To: <1381322418-1349-1-git-send-email-antonio@meshcoding.com>
From: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
Reordering the packet type numbers allows us to handle unicast
packets in a general way - even if we don't know the specific packet
type, we can still forward it. There was already code handling
this for a couple of unicast packets, and this is the more
generalized version to do that.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
---
net/batman-adv/main.c | 20 +++++++++++++++-----
net/batman-adv/packet.h | 31 +++++++++++++++++++++++--------
net/batman-adv/routing.c | 28 ++++++++++++++++++++++++++++
net/batman-adv/routing.h | 2 ++
4 files changed, 68 insertions(+), 13 deletions(-)
diff --git a/net/batman-adv/main.c b/net/batman-adv/main.c
index b22368e..8b195e6 100644
--- a/net/batman-adv/main.c
+++ b/net/batman-adv/main.c
@@ -393,6 +393,9 @@ static void batadv_recv_handler_init(void)
for (i = 0; i < ARRAY_SIZE(batadv_rx_handler); i++)
batadv_rx_handler[i] = batadv_recv_unhandled_packet;
+ for (i = BATADV_UNICAST_MIN; i <= BATADV_UNICAST_MAX; i++)
+ batadv_rx_handler[i] = batadv_recv_unhandled_unicast_packet;
+
/* compile time checks for struct member offsets */
BUILD_BUG_ON(offsetof(struct batadv_unicast_4addr_packet, src) != 10);
BUILD_BUG_ON(offsetof(struct batadv_unicast_packet, dest) != 4);
@@ -401,18 +404,20 @@ static void batadv_recv_handler_init(void)
BUILD_BUG_ON(offsetof(struct batadv_icmp_packet, dst) != 4);
BUILD_BUG_ON(offsetof(struct batadv_icmp_packet_rr, dst) != 4);
- /* batman icmp packet */
- batadv_rx_handler[BATADV_ICMP] = batadv_recv_icmp_packet;
+ /* broadcast packet */
+ batadv_rx_handler[BATADV_BCAST] = batadv_recv_bcast_packet;
+
+ /* unicast packets ... */
/* unicast with 4 addresses packet */
batadv_rx_handler[BATADV_UNICAST_4ADDR] = batadv_recv_unicast_packet;
/* unicast packet */
batadv_rx_handler[BATADV_UNICAST] = batadv_recv_unicast_packet;
/* fragmented unicast packet */
batadv_rx_handler[BATADV_UNICAST_FRAG] = batadv_recv_ucast_frag_packet;
- /* broadcast packet */
- batadv_rx_handler[BATADV_BCAST] = batadv_recv_bcast_packet;
/* unicast tvlv packet */
batadv_rx_handler[BATADV_UNICAST_TVLV] = batadv_recv_unicast_tvlv;
+ /* batman icmp packet */
+ batadv_rx_handler[BATADV_ICMP] = batadv_recv_icmp_packet;
}
int
@@ -420,7 +425,12 @@ batadv_recv_handler_register(uint8_t packet_type,
int (*recv_handler)(struct sk_buff *,
struct batadv_hard_iface *))
{
- if (batadv_rx_handler[packet_type] != &batadv_recv_unhandled_packet)
+ int (*curr)(struct sk_buff *,
+ struct batadv_hard_iface *);
+ curr = batadv_rx_handler[packet_type];
+
+ if ((curr != batadv_recv_unhandled_packet) &&
+ (curr != batadv_recv_unhandled_unicast_packet))
return -EBUSY;
batadv_rx_handler[packet_type] = recv_handler;
diff --git a/net/batman-adv/packet.h b/net/batman-adv/packet.h
index 87fcf2e..f02dbb1 100644
--- a/net/batman-adv/packet.h
+++ b/net/batman-adv/packet.h
@@ -22,17 +22,32 @@
/**
* enum batadv_packettype - types for batman-adv encapsulated packets
+ * @BATADV_IV_OGM: originator messages for B.A.T.M.A.N. IV
+ * @BATADV_BCAST: broadcast packets carrying broadcast payload
+ * @BATADV_CODED: network coded packets
+ *
+ * @BATADV_UNICAST: unicast packets carrying unicast payload traffic
+ * @BATADV_UNICAST_FRAG: unicast packets carrying a fragment of the original
+ * payload packet
+ * @BATADV_UNICAST_4ADDR: unicast packet including the originator address of
+ * the sender
+ * @BATADV_ICMP: unicast packet like IP ICMP used for ping or traceroute
* @BATADV_UNICAST_TVLV: unicast packet carrying TVLV containers
*/
enum batadv_packettype {
- BATADV_IV_OGM = 0x01,
- BATADV_ICMP = 0x02,
- BATADV_UNICAST = 0x03,
- BATADV_BCAST = 0x04,
- BATADV_UNICAST_FRAG = 0x06,
- BATADV_UNICAST_4ADDR = 0x09,
- BATADV_CODED = 0x0a,
- BATADV_UNICAST_TVLV = 0x0b,
+ /* 0x00 - 0x3f: local packets or special rules for handling */
+ BATADV_IV_OGM = 0x00,
+ BATADV_BCAST = 0x01,
+ BATADV_CODED = 0x02,
+ /* 0x40 - 0x7f: unicast */
+#define BATADV_UNICAST_MIN 0x40
+ BATADV_UNICAST = 0x40,
+ BATADV_UNICAST_FRAG = 0x41,
+ BATADV_UNICAST_4ADDR = 0x42,
+ BATADV_ICMP = 0x43,
+ BATADV_UNICAST_TVLV = 0x44,
+#define BATADV_UNICAST_MAX 0x7f
+ /* 0x80 - 0xff: reserved */
};
/**
diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 2a9318b..457dfef 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -911,6 +911,34 @@ static int batadv_check_unicast_ttvn(struct batadv_priv *bat_priv,
return 1;
}
+/**
+ * batadv_recv_unhandled_unicast_packet - receive and process packets which
+ * are in the unicast number space but not yet known to the implementation
+ * @skb: unicast tvlv packet to process
+ * @recv_if: pointer to interface this packet was received on
+ *
+ * Returns NET_RX_SUCCESS if the packet has been consumed or NET_RX_DROP
+ * otherwise.
+ */
+int batadv_recv_unhandled_unicast_packet(struct sk_buff *skb,
+ struct batadv_hard_iface *recv_if)
+{
+ struct batadv_unicast_packet *unicast_packet;
+ struct batadv_priv *bat_priv = netdev_priv(recv_if->soft_iface);
+ int check, hdr_size = sizeof(*unicast_packet);
+
+ check = batadv_check_unicast_packet(bat_priv, skb, hdr_size);
+ if (check < 0)
+ return NET_RX_DROP;
+
+ /* we don't know about this type, drop it. */
+ unicast_packet = (struct batadv_unicast_packet *)skb->data;
+ if (batadv_is_my_mac(bat_priv, unicast_packet->dest))
+ return NET_RX_DROP;
+
+ return batadv_route_unicast_packet(skb, recv_if);
+}
+
int batadv_recv_unicast_packet(struct sk_buff *skb,
struct batadv_hard_iface *recv_if)
{
diff --git a/net/batman-adv/routing.h b/net/batman-adv/routing.h
index b3f53d4..ea15fa6 100644
--- a/net/batman-adv/routing.h
+++ b/net/batman-adv/routing.h
@@ -40,6 +40,8 @@ int batadv_recv_roam_adv(struct sk_buff *skb,
struct batadv_hard_iface *recv_if);
int batadv_recv_unicast_tvlv(struct sk_buff *skb,
struct batadv_hard_iface *recv_if);
+int batadv_recv_unhandled_unicast_packet(struct sk_buff *skb,
+ struct batadv_hard_iface *recv_if);
struct batadv_neigh_node *
batadv_find_router(struct batadv_priv *bat_priv,
struct batadv_orig_node *orig_node,
--
1.8.3.2
^ permalink raw reply related
* Re: MBIM device refusing to be enabled
From: Dan Williams @ 2013-10-09 13:31 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Bjørn Mork, netdev
In-Reply-To: <1381317745.3464.6.camel@linux-fkkt.site>
On Wed, 2013-10-09 at 13:22 +0200, Oliver Neukum wrote:
> On Wed, 2013-10-09 at 13:09 +0200, Bjørn Mork wrote:
> > Bjørn Mork <bjorn@mork.no> writes:
>
> Hi,
>
> >
> > > Sorry, that was nonsense. rfkill would only affect the HwRadioState.
> >
> > Turns out I wasn't completely off anyway... by pure luck ;-)
> >
> > > Looking at the commands following this message, it appears that MM
> > > correctly attempts to enable the SwRadioState but fails. I don't know
> > > why.
>
> Cool.
>
> > Is the device by any chance a Sierra Wireless device?
>
> Yes. Rebranded by HP but it is Sierra.
> HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module
>
> > I was able to recreate the behaviour you see after experimenting a bit
> > with my MC7710. This device (and I assume most other MBIM capable
> > Sierra Wireless minicards) can be configured to enter low power mode on
> > rfkill (W_DISABLE asserted), instead of powering off. Sony for example
> > are known to configure the built-in Sierra devices in this mode.
> >
> > When low power mode is forced by rfkill this way, the firmware
> > erroneously[1] claims
> >
> > HwRadioState: on
> > SwRadioState: off
> >
> > Any attempt to change this software state using MBIM will fail with
> > MBIM_STATUS_FAILURE. Exactly like your log shows. The modem must be
> > enabled using rfkill before MM can use it. Changing the firmware
> > behaviour will not do any good - it will just cause the modem to power
> > off and disappear instead.
> >
> > So I would start looking at rfkill after all. There are often problems
> > with these platform drivers and newer laptops, due to the lack of
> > documentation from the vendors. Here's one (now fixed) example:
> > https://bugzilla.kernel.org/show_bug.cgi?id=47751
>
> Thanks. A quick look shows that there's something wrong. There is no
> rfkill entry for the device. I am investigating.
PCIe minicard pinouts have a W_DISABLE# pin (row 1 pin 20, active low)
that kills the card. If your machine grounds that PIN or mishandles it
somehow, and the card cares about that pin, then the card will show as
rfkilled.
I have cards that care: Samsung Y3300/Y3400, and most Ericsson devices.
The devices themselves show as rfkilled (either through QMI, AT
commands, etc) but you can't do anything about it unless you have a way
to float W_DISABLE.
So depending on your laptop's slot pinout and BIOS behavior, and whether
or not the rfkill driver correctly supports your laptop, you might be
out of luck.
Dan
^ permalink raw reply
* [PATCH 13/16] batman-adv: add build check macros for packet member offset
From: Antonio Quartulli @ 2013-10-09 12:40 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Simon Wunderlich, Simon Wunderlich,
Marek Lindner, Antonio Quartulli
In-Reply-To: <1381322418-1349-1-git-send-email-antonio@meshcoding.com>
From: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
Since we removed the __packed from most of the packets, we should
make sure that the offset generated by the compiler are correct for
sent/received data.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
---
net/batman-adv/main.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/net/batman-adv/main.c b/net/batman-adv/main.c
index 43dc92e..b22368e 100644
--- a/net/batman-adv/main.c
+++ b/net/batman-adv/main.c
@@ -393,6 +393,14 @@ static void batadv_recv_handler_init(void)
for (i = 0; i < ARRAY_SIZE(batadv_rx_handler); i++)
batadv_rx_handler[i] = batadv_recv_unhandled_packet;
+ /* compile time checks for struct member offsets */
+ BUILD_BUG_ON(offsetof(struct batadv_unicast_4addr_packet, src) != 10);
+ BUILD_BUG_ON(offsetof(struct batadv_unicast_packet, dest) != 4);
+ BUILD_BUG_ON(offsetof(struct batadv_unicast_frag_packet, dest) != 4);
+ BUILD_BUG_ON(offsetof(struct batadv_unicast_tvlv_packet, dst) != 4);
+ BUILD_BUG_ON(offsetof(struct batadv_icmp_packet, dst) != 4);
+ BUILD_BUG_ON(offsetof(struct batadv_icmp_packet_rr, dst) != 4);
+
/* batman icmp packet */
batadv_rx_handler[BATADV_ICMP] = batadv_recv_icmp_packet;
/* unicast with 4 addresses packet */
--
1.8.3.2
^ permalink raw reply related
* [PATCH 10/16] batman-adv: use CRC32C instead of CRC16 in TT code
From: Antonio Quartulli @ 2013-10-09 12:40 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <1381322418-1349-1-git-send-email-antonio@meshcoding.com>
From: Antonio Quartulli <ordex@autistici.org>
CRC32C has to be preferred to CRC16 because of its possible
HW native support and because of the reduced collision
probability. With this change the Translation Table
component now uses CRC32C to compute the local and global
table checksum.
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
---
net/batman-adv/packet.h | 6 ++--
net/batman-adv/translation-table.c | 73 ++++++++++++++++++++------------------
net/batman-adv/types.h | 4 +--
3 files changed, 45 insertions(+), 38 deletions(-)
diff --git a/net/batman-adv/packet.h b/net/batman-adv/packet.h
index 5c08d26..7a337d7 100644
--- a/net/batman-adv/packet.h
+++ b/net/batman-adv/packet.h
@@ -345,12 +345,14 @@ struct batadv_tvlv_gateway_data {
* struct batadv_tvlv_tt_data - tt data propagated through the tt tvlv container
* @flags: translation table flags (see batadv_tt_data_flags)
* @ttvn: translation table version number
- * @crc: crc16 checksum of the local translation table
+ * @reserved: field reserved for future use
+ * @crc: crc32 checksum of the local translation table
*/
struct batadv_tvlv_tt_data {
uint8_t flags;
uint8_t ttvn;
- __be16 crc;
+ uint16_t reserved;
+ __be32 crc;
};
/**
diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index cb3c58e..4cdd743 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -27,7 +27,7 @@
#include "routing.h"
#include "bridge_loop_avoidance.h"
-#include <linux/crc16.h>
+#include <linux/crc32c.h>
/* hash class keys */
static struct lock_class_key batadv_tt_local_hash_lock_class_key;
@@ -409,7 +409,7 @@ static void batadv_tt_tvlv_container_update(struct batadv_priv *bat_priv)
tt_data->flags = BATADV_TT_OGM_DIFF;
tt_data->ttvn = atomic_read(&bat_priv->tt.vn);
- tt_data->crc = htons(bat_priv->tt.local_crc);
+ tt_data->crc = htonl(bat_priv->tt.local_crc);
if (tt_diff_len == 0)
goto container_register;
@@ -481,7 +481,7 @@ int batadv_tt_local_seq_print_text(struct seq_file *seq, void *offset)
goto out;
seq_printf(seq,
- "Locally retrieved addresses (from %s) announced via TT (TTVN: %u CRC: %#.4x):\n",
+ "Locally retrieved addresses (from %s) announced via TT (TTVN: %u CRC: %#.8x):\n",
net_dev->name, (uint8_t)atomic_read(&bat_priv->tt.vn),
bat_priv->tt.local_crc);
seq_printf(seq, " %-13s %-7s %-10s\n", "Client", "Flags",
@@ -993,7 +993,7 @@ batadv_tt_global_print_entry(struct batadv_tt_global_entry *tt_global_entry,
if (best_entry) {
last_ttvn = atomic_read(&best_entry->orig_node->last_ttvn);
seq_printf(seq,
- " %c %pM (%3u) via %pM (%3u) (%#.4x) [%c%c%c]\n",
+ " %c %pM (%3u) via %pM (%3u) (%#.8x) [%c%c%c]\n",
'*', tt_global_entry->common.addr,
best_entry->ttvn, best_entry->orig_node->orig,
last_ttvn, best_entry->orig_node->tt_crc,
@@ -1037,7 +1037,7 @@ int batadv_tt_global_seq_print_text(struct seq_file *seq, void *offset)
seq_printf(seq,
"Globally announced TT entries received via the mesh %s\n",
net_dev->name);
- seq_printf(seq, " %-13s %s %-15s %s (%-6s) %s\n",
+ seq_printf(seq, " %-13s %s %-15s %s (%-10s) %s\n",
"Client", "(TTVN)", "Originator", "(Curr TTVN)", "CRC",
"Flags");
@@ -1394,17 +1394,19 @@ out:
return orig_node;
}
-/* Calculates the checksum of the local table of a given orig_node */
-static uint16_t batadv_tt_global_crc(struct batadv_priv *bat_priv,
+/**
+ * batadv_tt_global_crc - calculates the checksum of the local table belonging
+ * to the given orig_node
+ * @bat_priv: the bat priv with all the soft interface information
+ */
+static uint32_t batadv_tt_global_crc(struct batadv_priv *bat_priv,
struct batadv_orig_node *orig_node)
{
- uint16_t total = 0, total_one;
struct batadv_hashtable *hash = bat_priv->tt.global_hash;
struct batadv_tt_common_entry *tt_common;
struct batadv_tt_global_entry *tt_global;
struct hlist_head *head;
- uint32_t i;
- int j;
+ uint32_t i, crc = 0;
for (i = 0; i < hash->size; i++) {
head = &hash->table[i];
@@ -1435,27 +1437,24 @@ static uint16_t batadv_tt_global_crc(struct batadv_priv *bat_priv,
orig_node))
continue;
- total_one = 0;
- for (j = 0; j < ETH_ALEN; j++)
- total_one = crc16_byte(total_one,
- tt_common->addr[j]);
- total ^= total_one;
+ crc ^= crc32c(0, tt_common->addr, ETH_ALEN);
}
rcu_read_unlock();
}
- return total;
+ return crc;
}
-/* Calculates the checksum of the local table */
-static uint16_t batadv_tt_local_crc(struct batadv_priv *bat_priv)
+/**
+ * batadv_tt_local_crc - calculates the checksum of the local table
+ * @bat_priv: the bat priv with all the soft interface information
+ */
+static uint32_t batadv_tt_local_crc(struct batadv_priv *bat_priv)
{
- uint16_t total = 0, total_one;
struct batadv_hashtable *hash = bat_priv->tt.local_hash;
struct batadv_tt_common_entry *tt_common;
struct hlist_head *head;
- uint32_t i;
- int j;
+ uint32_t i, crc = 0;
for (i = 0; i < hash->size; i++) {
head = &hash->table[i];
@@ -1467,16 +1466,13 @@ static uint16_t batadv_tt_local_crc(struct batadv_priv *bat_priv)
*/
if (tt_common->flags & BATADV_TT_CLIENT_NEW)
continue;
- total_one = 0;
- for (j = 0; j < ETH_ALEN; j++)
- total_one = crc16_byte(total_one,
- tt_common->addr[j]);
- total ^= total_one;
+
+ crc ^= crc32c(0, tt_common->addr, ETH_ALEN);
}
rcu_read_unlock();
}
- return total;
+ return crc;
}
static void batadv_tt_req_list_free(struct batadv_priv *bat_priv)
@@ -1662,9 +1658,18 @@ out:
return tvlv_tt_data;
}
+/**
+ * batadv_send_tt_request - send a TT Request message to a given node
+ * @bat_priv: the bat priv with all the soft interface information
+ * @dst_orig_node: the destination of the message
+ * @ttvn: the version number that the source of the message is looking for
+ * @tt_crc: the CRC associated with the version number
+ * @full_table: ask for the entire translation table if true, while only for the
+ * last TT diff otherwise
+ */
static int batadv_send_tt_request(struct batadv_priv *bat_priv,
struct batadv_orig_node *dst_orig_node,
- uint8_t ttvn, uint16_t tt_crc,
+ uint8_t ttvn, uint32_t tt_crc,
bool full_table)
{
struct batadv_tvlv_tt_data *tvlv_tt_data = NULL;
@@ -1689,7 +1694,7 @@ static int batadv_send_tt_request(struct batadv_priv *bat_priv,
tvlv_tt_data->flags = BATADV_TT_REQUEST;
tvlv_tt_data->ttvn = ttvn;
- tvlv_tt_data->crc = htons(tt_crc);
+ tvlv_tt_data->crc = htonl(tt_crc);
if (full_table)
tvlv_tt_data->flags |= BATADV_TT_FULL_TABLE;
@@ -1756,7 +1761,7 @@ static bool batadv_send_other_tt_response(struct batadv_priv *bat_priv,
/* this node doesn't have the requested data */
if (orig_ttvn != req_ttvn ||
- tt_data->crc != htons(req_dst_orig_node->tt_crc))
+ tt_data->crc != htonl(req_dst_orig_node->tt_crc))
goto out;
/* If the full table has been explicitly requested */
@@ -2403,13 +2408,13 @@ out:
* @tt_buff: buffer holding the tt information
* @tt_num_changes: number of tt changes inside the tt buffer
* @ttvn: translation table version number of this changeset
- * @tt_crc: crc16 checksum of orig node's translation table
+ * @tt_crc: crc32 checksum of orig node's translation table
*/
static void batadv_tt_update_orig(struct batadv_priv *bat_priv,
struct batadv_orig_node *orig_node,
const unsigned char *tt_buff,
uint16_t tt_num_changes, uint8_t ttvn,
- uint16_t tt_crc)
+ uint32_t tt_crc)
{
uint8_t orig_ttvn = (uint8_t)atomic_read(&orig_node->last_ttvn);
bool full_table = true;
@@ -2463,7 +2468,7 @@ static void batadv_tt_update_orig(struct batadv_priv *bat_priv,
orig_node->tt_crc != tt_crc) {
request_table:
batadv_dbg(BATADV_DBG_TT, bat_priv,
- "TT inconsistency for %pM. Need to retrieve the correct information (ttvn: %u last_ttvn: %u crc: %#.4x last_crc: %#.4x num_changes: %u)\n",
+ "TT inconsistency for %pM. Need to retrieve the correct information (ttvn: %u last_ttvn: %u crc: %#.8x last_crc: %#.8x num_changes: %u)\n",
orig_node->orig, ttvn, orig_ttvn, tt_crc,
orig_node->tt_crc, tt_num_changes);
batadv_send_tt_request(bat_priv, orig_node, ttvn,
@@ -2571,7 +2576,7 @@ static void batadv_tt_tvlv_ogm_handler_v1(struct batadv_priv *bat_priv,
batadv_tt_update_orig(bat_priv, orig,
(unsigned char *)(tt_data + 1),
- num_entries, tt_data->ttvn, ntohs(tt_data->crc));
+ num_entries, tt_data->ttvn, ntohl(tt_data->crc));
}
/**
diff --git a/net/batman-adv/types.h b/net/batman-adv/types.h
index bdabbc2..e98915a 100644
--- a/net/batman-adv/types.h
+++ b/net/batman-adv/types.h
@@ -150,7 +150,7 @@ struct batadv_orig_node {
uint8_t flags;
uint8_t capabilities;
atomic_t last_ttvn;
- uint16_t tt_crc;
+ uint32_t tt_crc;
unsigned char *tt_buff;
int16_t tt_buff_len;
spinlock_t tt_buff_lock; /* protects tt_buff & tt_buff_len */
@@ -377,7 +377,7 @@ struct batadv_priv_tt {
spinlock_t req_list_lock; /* protects req_list */
spinlock_t roam_list_lock; /* protects roam_list */
atomic_t local_entry_num;
- uint16_t local_crc;
+ uint32_t local_crc;
unsigned char *last_changeset;
int16_t last_changeset_len;
/* protects last_changeset & last_changeset_len */
--
1.8.3.2
^ permalink raw reply related
* [PATCH 16/16] batman-adv: reorder batadv_iv_flags
From: Antonio Quartulli @ 2013-10-09 12:40 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Simon Wunderlich, Simon Wunderlich,
Marek Lindner, Antonio Quartulli
In-Reply-To: <1381322418-1349-1-git-send-email-antonio@meshcoding.com>
From: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
The vis flag is not needed anymore, and since we do a compat bump we
can start with the first bit again
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
---
net/batman-adv/packet.h | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/net/batman-adv/packet.h b/net/batman-adv/packet.h
index 4e5fe7d..4361bae 100644
--- a/net/batman-adv/packet.h
+++ b/net/batman-adv/packet.h
@@ -67,10 +67,19 @@ enum batadv_subtype {
/* this file is included by batctl which needs these defines */
#define BATADV_COMPAT_VERSION 15
+/**
+ * enum batadv_iv_flags - flags used in B.A.T.M.A.N. IV OGM packets
+ * @BATADV_NOT_BEST_NEXT_HOP: flag is set when ogm packet is forwarded and was
+ * previously received from someone else than the best neighbor.
+ * @BATADV_PRIMARIES_FIRST_HOP: flag is set when the primary interface address
+ * is used, and the packet travels its first hop.
+ * @BATADV_DIRECTLINK: flag is for the first hop or if rebroadcasted from a
+ * one hop neighbor on the interface where it was originally received.
+ */
enum batadv_iv_flags {
- BATADV_NOT_BEST_NEXT_HOP = BIT(3),
- BATADV_PRIMARIES_FIRST_HOP = BIT(4),
- BATADV_DIRECTLINK = BIT(6),
+ BATADV_NOT_BEST_NEXT_HOP = BIT(0),
+ BATADV_PRIMARIES_FIRST_HOP = BIT(1),
+ BATADV_DIRECTLINK = BIT(2),
};
/* ICMP message types */
@@ -164,11 +173,12 @@ struct batadv_header {
/**
* struct batadv_ogm_packet - ogm (routing protocol) packet
* @header: common batman packet header
+ * @flags: contains routing relevant flags - see enum batadv_iv_flags
* @tvlv_len: length of tvlv data following the ogm header
*/
struct batadv_ogm_packet {
struct batadv_header header;
- uint8_t flags; /* 0x40: DIRECTLINK flag ... */
+ uint8_t flags;
__be32 seqno;
uint8_t orig[ETH_ALEN];
uint8_t prev_sender[ETH_ALEN];
--
1.8.3.2
^ permalink raw reply related
* [PATCH net-next] bnx2x: Add ndo_get_phys_port_id support
From: Yuval Mintz @ 2013-10-09 14:06 UTC (permalink / raw)
To: davem; +Cc: netdev, Yuval Mintz, Ariel Elior, Eilon Greenstein
Each network interface (either PF or VF) is identified by its port's MAC id.
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
Hi Dave,
Please consider applying this patch to 'net-next'.
Thanks,
Yuval Mintz
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 3 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 23 ++++
drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c | 149 +++++++++++++++++++----
drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.h | 7 ++
4 files changed, 155 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index 8fe4bcb..5fb18cd 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -1546,6 +1546,7 @@ struct bnx2x {
#define IS_VF_FLAG (1 << 22)
#define INTERRUPTS_ENABLED_FLAG (1 << 23)
#define BC_SUPPORTS_RMMOD_CMD (1 << 24)
+#define HAS_PHYS_PORT_ID (1 << 25)
#define BP_NOMCP(bp) ((bp)->flags & NO_MCP_FLAG)
@@ -1876,6 +1877,8 @@ struct bnx2x {
u32 dump_preset_idx;
bool stats_started;
struct semaphore stats_sema;
+
+ u8 phys_port_id[ETH_ALEN];
};
/* Tx queues may be less or equal to Rx queues */
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 13a5694..e53ff1e 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -11149,6 +11149,14 @@ static void bnx2x_get_mac_hwinfo(struct bnx2x *bp)
bnx2x_get_cnic_mac_hwinfo(bp);
}
+ if (!BP_NOMCP(bp)) {
+ /* Read physical port identifier from shmem */
+ val2 = SHMEM_RD(bp, dev_info.port_hw_config[port].mac_upper);
+ val = SHMEM_RD(bp, dev_info.port_hw_config[port].mac_lower);
+ bnx2x_set_mac_buf(bp->phys_port_id, val, val2);
+ bp->flags |= HAS_PHYS_PORT_ID;
+ }
+
memcpy(bp->link_params.mac_addr, bp->dev->dev_addr, ETH_ALEN);
if (!bnx2x_is_valid_ether_addr(bp, bp->dev->dev_addr))
@@ -12044,6 +12052,20 @@ static int bnx2x_validate_addr(struct net_device *dev)
return 0;
}
+static int bnx2x_get_phys_port_id(struct net_device *netdev,
+ struct netdev_phys_port_id *ppid)
+{
+ struct bnx2x *bp = netdev_priv(netdev);
+
+ if (!(bp->flags & HAS_PHYS_PORT_ID))
+ return -EOPNOTSUPP;
+
+ ppid->id_len = sizeof(bp->phys_port_id);
+ memcpy(ppid->id, bp->phys_port_id, ppid->id_len);
+
+ return 0;
+}
+
static const struct net_device_ops bnx2x_netdev_ops = {
.ndo_open = bnx2x_open,
.ndo_stop = bnx2x_close,
@@ -12073,6 +12095,7 @@ static const struct net_device_ops bnx2x_netdev_ops = {
#ifdef CONFIG_NET_RX_BUSY_POLL
.ndo_busy_poll = bnx2x_low_latency_recv,
#endif
+ .ndo_get_phys_port_id = bnx2x_get_phys_port_id,
};
static int bnx2x_set_coherency_mask(struct bnx2x *bp)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
index da16953..e4b90aa 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
@@ -60,6 +60,30 @@ void bnx2x_vfpf_finalize(struct bnx2x *bp, struct vfpf_first_tlv *first_tlv)
mutex_unlock(&bp->vf2pf_mutex);
}
+/* Finds a TLV by type in a TLV buffer; If found, returns pointer to the TLV */
+static void *bnx2x_search_tlv_list(struct bnx2x *bp, void *tlvs_list,
+ enum channel_tlvs req_tlv)
+{
+ struct channel_tlv *tlv = (struct channel_tlv *)tlvs_list;
+
+ do {
+ if (tlv->type == req_tlv)
+ return tlv;
+
+ if (!tlv->length) {
+ BNX2X_ERR("Found TLV with length 0\n");
+ return NULL;
+ }
+
+ tlvs_list += tlv->length;
+ tlv = (struct channel_tlv *)tlvs_list;
+ } while (tlv->type != CHANNEL_TLV_LIST_END);
+
+ DP(BNX2X_MSG_IOV, "TLV list does not contain %d TLV\n", req_tlv);
+
+ return NULL;
+}
+
/* list the types and lengths of the tlvs on the buffer */
void bnx2x_dp_tlv_list(struct bnx2x *bp, void *tlvs_list)
{
@@ -196,6 +220,7 @@ int bnx2x_vfpf_acquire(struct bnx2x *bp, u8 tx_count, u8 rx_count)
int rc = 0, attempts = 0;
struct vfpf_acquire_tlv *req = &bp->vf2pf_mbox->req.acquire;
struct pfvf_acquire_resp_tlv *resp = &bp->vf2pf_mbox->resp.acquire_resp;
+ struct vfpf_port_phys_id_resp_tlv *phys_port_resp;
u32 vf_id;
bool resources_acquired = false;
@@ -219,8 +244,14 @@ int bnx2x_vfpf_acquire(struct bnx2x *bp, u8 tx_count, u8 rx_count)
/* pf 2 vf bulletin board address */
req->bulletin_addr = bp->pf2vf_bulletin_mapping;
+ /* Request physical port identifier */
+ bnx2x_add_tlv(bp, req, req->first_tlv.tl.length,
+ CHANNEL_TLV_PHYS_PORT_ID, sizeof(struct channel_tlv));
+
/* add list termination tlv */
- bnx2x_add_tlv(bp, req, req->first_tlv.tl.length, CHANNEL_TLV_LIST_END,
+ bnx2x_add_tlv(bp, req,
+ req->first_tlv.tl.length + sizeof(struct channel_tlv),
+ CHANNEL_TLV_LIST_END,
sizeof(struct channel_list_end_tlv));
/* output tlvs list */
@@ -287,6 +318,15 @@ int bnx2x_vfpf_acquire(struct bnx2x *bp, u8 tx_count, u8 rx_count)
}
}
+ /* Retrieve physical port id (if possible) */
+ phys_port_resp = (struct vfpf_port_phys_id_resp_tlv *)
+ bnx2x_search_tlv_list(bp, resp,
+ CHANNEL_TLV_PHYS_PORT_ID);
+ if (phys_port_resp) {
+ memcpy(bp->phys_port_id, phys_port_resp->id, ETH_ALEN);
+ bp->flags |= HAS_PHYS_PORT_ID;
+ }
+
/* get HW info */
bp->common.chip_id |= (bp->acquire_resp.pfdev_info.chip_num & 0xffff);
bp->link_params.chip_id = bp->common.chip_id;
@@ -983,53 +1023,59 @@ static int bnx2x_copy32_vf_dmae(struct bnx2x *bp, u8 from_vf,
return bnx2x_issue_dmae_with_comp(bp, &dmae);
}
-static void bnx2x_vf_mbx_resp(struct bnx2x *bp, struct bnx2x_virtf *vf)
+static void bnx2x_vf_mbx_resp_single_tlv(struct bnx2x *bp,
+ struct bnx2x_virtf *vf)
{
struct bnx2x_vf_mbx *mbx = BP_VF_MBX(bp, vf->index);
- u64 vf_addr;
- dma_addr_t pf_addr;
u16 length, type;
- int rc;
- struct pfvf_general_resp_tlv *resp = &mbx->msg->resp.general_resp;
/* prepare response */
type = mbx->first_tlv.tl.type;
length = type == CHANNEL_TLV_ACQUIRE ?
sizeof(struct pfvf_acquire_resp_tlv) :
sizeof(struct pfvf_general_resp_tlv);
- bnx2x_add_tlv(bp, resp, 0, type, length);
- resp->hdr.status = bnx2x_pfvf_status_codes(vf->op_rc);
- bnx2x_add_tlv(bp, resp, length, CHANNEL_TLV_LIST_END,
+ bnx2x_add_tlv(bp, &mbx->msg->resp, 0, type, length);
+ bnx2x_add_tlv(bp, &mbx->msg->resp, length, CHANNEL_TLV_LIST_END,
sizeof(struct channel_list_end_tlv));
+}
+
+static void bnx2x_vf_mbx_resp_send_msg(struct bnx2x *bp,
+ struct bnx2x_virtf *vf)
+{
+ struct bnx2x_vf_mbx *mbx = BP_VF_MBX(bp, vf->index);
+ struct pfvf_general_resp_tlv *resp = &mbx->msg->resp.general_resp;
+ dma_addr_t pf_addr;
+ u64 vf_addr;
+ int rc;
+
bnx2x_dp_tlv_list(bp, resp);
DP(BNX2X_MSG_IOV, "mailbox vf address hi 0x%x, lo 0x%x, offset 0x%x\n",
mbx->vf_addr_hi, mbx->vf_addr_lo, mbx->first_tlv.resp_msg_offset);
+ resp->hdr.status = bnx2x_pfvf_status_codes(vf->op_rc);
+
/* send response */
vf_addr = HILO_U64(mbx->vf_addr_hi, mbx->vf_addr_lo) +
mbx->first_tlv.resp_msg_offset;
pf_addr = mbx->msg_mapping +
offsetof(struct bnx2x_vf_mbx_msg, resp);
- /* copy the response body, if there is one, before the header, as the vf
- * is sensitive to the header being written
+ /* Copy the response buffer. The first u64 is written afterwards, as
+ * the vf is sensitive to the header being written
*/
- if (resp->hdr.tl.length > sizeof(u64)) {
- length = resp->hdr.tl.length - sizeof(u64);
- vf_addr += sizeof(u64);
- pf_addr += sizeof(u64);
- rc = bnx2x_copy32_vf_dmae(bp, false, pf_addr, vf->abs_vfid,
- U64_HI(vf_addr),
- U64_LO(vf_addr),
- length/4);
- if (rc) {
- BNX2X_ERR("Failed to copy response body to VF %d\n",
- vf->abs_vfid);
- goto mbx_error;
- }
- vf_addr -= sizeof(u64);
- pf_addr -= sizeof(u64);
+ vf_addr += sizeof(u64);
+ pf_addr += sizeof(u64);
+ rc = bnx2x_copy32_vf_dmae(bp, false, pf_addr, vf->abs_vfid,
+ U64_HI(vf_addr),
+ U64_LO(vf_addr),
+ (sizeof(union pfvf_tlvs) - sizeof(u64))/4);
+ if (rc) {
+ BNX2X_ERR("Failed to copy response body to VF %d\n",
+ vf->abs_vfid);
+ goto mbx_error;
}
+ vf_addr -= sizeof(u64);
+ pf_addr -= sizeof(u64);
/* ack the FW */
storm_memset_vf_mbx_ack(bp, vf->abs_vfid);
@@ -1060,6 +1106,36 @@ mbx_error:
bnx2x_vf_release(bp, vf, false); /* non blocking */
}
+static void bnx2x_vf_mbx_resp(struct bnx2x *bp,
+ struct bnx2x_virtf *vf)
+{
+ bnx2x_vf_mbx_resp_single_tlv(bp, vf);
+ bnx2x_vf_mbx_resp_send_msg(bp, vf);
+}
+
+static void bnx2x_vf_mbx_resp_phys_port(struct bnx2x *bp,
+ struct bnx2x_virtf *vf,
+ void *buffer,
+ u16 *offset)
+{
+ struct vfpf_port_phys_id_resp_tlv *port_id;
+
+ if (!(bp->flags & HAS_PHYS_PORT_ID))
+ return;
+
+ bnx2x_add_tlv(bp, buffer, *offset, CHANNEL_TLV_PHYS_PORT_ID,
+ sizeof(struct vfpf_port_phys_id_resp_tlv));
+
+ port_id = (struct vfpf_port_phys_id_resp_tlv *)
+ (((u8 *)buffer) + *offset);
+ memcpy(port_id->id, bp->phys_port_id, ETH_ALEN);
+
+ /* Offset should continue representing the offset to the tail
+ * of TLV data (outside this function scope)
+ */
+ *offset += sizeof(struct vfpf_port_phys_id_resp_tlv);
+}
+
static void bnx2x_vf_mbx_acquire_resp(struct bnx2x *bp, struct bnx2x_virtf *vf,
struct bnx2x_vf_mbx *mbx, int vfop_status)
{
@@ -1067,6 +1143,7 @@ static void bnx2x_vf_mbx_acquire_resp(struct bnx2x *bp, struct bnx2x_virtf *vf,
struct pfvf_acquire_resp_tlv *resp = &mbx->msg->resp.acquire_resp;
struct pf_vf_resc *resc = &resp->resc;
u8 status = bnx2x_pfvf_status_codes(vfop_status);
+ u16 length;
memset(resp, 0, sizeof(*resp));
@@ -1140,9 +1217,24 @@ static void bnx2x_vf_mbx_acquire_resp(struct bnx2x *bp, struct bnx2x_virtf *vf,
resc->hw_sbs[i].sb_qid);
DP_CONT(BNX2X_MSG_IOV, "]\n");
+ /* prepare response */
+ length = sizeof(struct pfvf_acquire_resp_tlv);
+ bnx2x_add_tlv(bp, &mbx->msg->resp, 0, CHANNEL_TLV_ACQUIRE, length);
+
+ /* Handle possible VF requests for physical port identifiers.
+ * 'length' should continue to indicate the offset of the first empty
+ * place in the buffer (i.e., where next TLV should be inserted)
+ */
+ if (bnx2x_search_tlv_list(bp, &mbx->msg->req,
+ CHANNEL_TLV_PHYS_PORT_ID))
+ bnx2x_vf_mbx_resp_phys_port(bp, vf, &mbx->msg->resp, &length);
+
+ bnx2x_add_tlv(bp, &mbx->msg->resp, length, CHANNEL_TLV_LIST_END,
+ sizeof(struct channel_list_end_tlv));
+
/* send the response */
vf->op_rc = vfop_status;
- bnx2x_vf_mbx_resp(bp, vf);
+ bnx2x_vf_mbx_resp_send_msg(bp, vf);
}
static void bnx2x_vf_mbx_acquire(struct bnx2x *bp, struct bnx2x_virtf *vf,
@@ -1874,6 +1966,9 @@ void bnx2x_vf_mbx(struct bnx2x *bp, struct vf_pf_event_data *vfpf_event)
/* process the VF message header */
mbx->first_tlv = mbx->msg->req.first_tlv;
+ /* Clean response buffer to refrain from falsely seeing chains */
+ memset(&mbx->msg->resp, 0, sizeof(union pfvf_tlvs));
+
/* dispatch the request (will prepare the response) */
bnx2x_vf_mbx_request(bp, vf, mbx);
goto mbx_done;
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.h
index 1179fe0..208568b 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.h
@@ -188,6 +188,12 @@ struct pfvf_acquire_resp_tlv {
} resc;
};
+struct vfpf_port_phys_id_resp_tlv {
+ struct channel_tlv tl;
+ u8 id[ETH_ALEN];
+ u8 padding[2];
+};
+
#define VFPF_INIT_FLG_STATS_COALESCE (1 << 0) /* when set the VFs queues
* stats will be coalesced on
* the leading RSS queue
@@ -398,6 +404,7 @@ enum channel_tlvs {
CHANNEL_TLV_PF_SET_MAC,
CHANNEL_TLV_PF_SET_VLAN,
CHANNEL_TLV_UPDATE_RSS,
+ CHANNEL_TLV_PHYS_PORT_ID,
CHANNEL_TLV_MAX
};
--
1.8.1.227.g44fe835
^ permalink raw reply related
* Re: bug in passing file descriptors
From: Steve Rago @ 2013-10-09 14:07 UTC (permalink / raw)
To: Andi Kleen
Cc: Andy Lutomirski, David Miller, Network Development,
Michael Kerrisk-manpages, Eric W. Biederman
In-Reply-To: <525437FF.5020905@nec-labs.com>
On 10/08/2013 12:51 PM, Steve Rago wrote:
> On 10/08/2013 12:41 PM, Andi Kleen wrote:
>>> I just want the semantics to be consistent. If you want Linux to
>>> always require applications that call recvmsg to provide a buffer
>>> size of CMSG_SPACE bytes long to retrieve control information, then
>>> fail the system call when the buffer is smaller. But if you do
>>> this, you risk breaking applications that work with FreeBSD, Mac OS
>>> X, Solaris, and probably a few others.
>>
>> The primary concern is to be binary compatible with Linux.
Not to application developers, by the way.
>>
>> But not being compatible between 32bit and 64bit Linux processes on the same
>> host would seem like a serious problem to me.
>>
>>> Regardless, copying 20 bytes and telling me you copied 24 is misleading and wrong.
>>
>> The question is could it break existing Linux applications to change it?
>> And would it help with the 32/64bit compatibility?
>>
>> If not some other way to fix the compat layer would need to be found.
>>
>> -Andi
>>
>
> I'm not sure if a 64-bit process and a 32-bit process exchange file descriptors on the same system has a problem. It
> certainly looks like the compat code does the right thing. I can test this tonight if you want.
I tested all combinations and they work fine as far as Linux binary compatibility is concerned.
Steve
^ permalink raw reply
* RE: [PATCH 10/16] batman-adv: use CRC32C instead of CRC16 in TT code
From: David Laight @ 2013-10-09 14:11 UTC (permalink / raw)
To: Antonio Quartulli, davem
Cc: netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <1381322418-1349-11-git-send-email-antonio@meshcoding.com>
> CRC32C has to be preferred to CRC16 because of its possible
> HW native support and because of the reduced collision
> probability. With this change the Translation Table
> component now uses CRC32C to compute the local and global
> table checksum.
...
> -/* Calculates the checksum of the local table of a given orig_node */
> -static uint16_t batadv_tt_global_crc(struct batadv_priv *bat_priv,
> +/**
> + * batadv_tt_global_crc - calculates the checksum of the local table belonging
> + * to the given orig_node
> + * @bat_priv: the bat priv with all the soft interface information
> + */
> +static uint32_t batadv_tt_global_crc(struct batadv_priv *bat_priv,
> struct batadv_orig_node *orig_node)
...
> for (i = 0; i < hash->size; i++) {
> head = &hash->table[i];
> @@ -1435,27 +1437,24 @@ static uint16_t batadv_tt_global_crc(struct batadv_priv *bat_priv,
> orig_node))
> continue;
>
...
> + crc ^= crc32c(0, tt_common->addr, ETH_ALEN);
> }
Are you really generating CRC32 of a pile of ethernet MAC addresses
and the XORing the CRC together?
That gives the same answer as XORing together the MAC addresses and
then doing a CRC of the final value.
So it gives you almost no protection against corruption at all.
...
> -/* Calculates the checksum of the local table */
> -static uint16_t batadv_tt_local_crc(struct batadv_priv *bat_priv)
> +/**
> + * batadv_tt_local_crc - calculates the checksum of the local table
> + * @bat_priv: the bat priv with all the soft interface information
> + */
> +static uint32_t batadv_tt_local_crc(struct batadv_priv *bat_priv)
> {
...
This looks like a clone of the previous routine.
Surely you can avoid the code duplication.
David
^ permalink raw reply
* Re: [PATCH 10/16] batman-adv: use CRC32C instead of CRC16 in TT code
From: Antonio Quartulli @ 2013-10-09 14:35 UTC (permalink / raw)
To: David Laight; +Cc: davem, netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7384@saturn3.aculab.com>
[-- Attachment #1: Type: text/plain, Size: 2770 bytes --]
On Wed, Oct 09, 2013 at 03:11:08PM +0100, David Laight wrote:
> > CRC32C has to be preferred to CRC16 because of its possible
> > HW native support and because of the reduced collision
> > probability. With this change the Translation Table
> > component now uses CRC32C to compute the local and global
> > table checksum.
> ...
> > -/* Calculates the checksum of the local table of a given orig_node */
> > -static uint16_t batadv_tt_global_crc(struct batadv_priv *bat_priv,
> > +/**
> > + * batadv_tt_global_crc - calculates the checksum of the local table belonging
> > + * to the given orig_node
> > + * @bat_priv: the bat priv with all the soft interface information
> > + */
> > +static uint32_t batadv_tt_global_crc(struct batadv_priv *bat_priv,
> > struct batadv_orig_node *orig_node)
> ...
> > for (i = 0; i < hash->size; i++) {
> > head = &hash->table[i];
> > @@ -1435,27 +1437,24 @@ static uint16_t batadv_tt_global_crc(struct batadv_priv *bat_priv,
> > orig_node))
> > continue;
> >
> ...
> > + crc ^= crc32c(0, tt_common->addr, ETH_ALEN);
> > }
>
> Are you really generating CRC32 of a pile of ethernet MAC addresses
> and the XORing the CRC together?
> That gives the same answer as XORing together the MAC addresses and
> then doing a CRC of the final value.
I was not sure about this since the CRC32 is not a linear operation. However
this routine is not on the fast path, so we can also live with this order.
> So it gives you almost no protection against corruption at all.
The corruption check is for the entire global table.
The global table is the union of the local tables of all the other nodes (each
node has a local and a global table).
The resulting value (the xor of the CRCs) is then compared to the value
sent by whom originated this piece of global table.
In this way each batman-adv node is sure to have the entries that the node
really generated in its local table.
(sorry for using the word table several times..)
Does this clarify? or have I misunderstood your objection?
>
> ...
> > -/* Calculates the checksum of the local table */
> > -static uint16_t batadv_tt_local_crc(struct batadv_priv *bat_priv)
> > +/**
> > + * batadv_tt_local_crc - calculates the checksum of the local table
> > + * @bat_priv: the bat priv with all the soft interface information
> > + */
> > +static uint32_t batadv_tt_local_crc(struct batadv_priv *bat_priv)
> > {
> ...
>
> This looks like a clone of the previous routine.
> Surely you can avoid the code duplication.
Some parts are the same, true. But this was already like this.
We can surely try to improve it later on with another patch.
Regards,
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Fwd: [PATCH 1/1] hso: fix problem with wrong status code sent by OPTION GTM601 during RING indication
From: Eric Verdonck @ 2013-10-09 14:38 UTC (permalink / raw)
To: marek.belisko, linux-usb, netdev; +Cc: Jan Dumon, linux-kernel
In-Reply-To: <7685369CB6CCA443BA30E328A476A8CB2BDD6D@SRV-SATURNUS.OPTION.local>
Met vriendelijke groeten,
Eric Verdonck
Driver Development
Option nv, Gaston Geenslaan 14, B-3001 Leuven
T: +32 16 311 597
F: +32 16 207 164
E-mail: e.verdonck@option.com
Website: www.option.com
Disclaimer:http://www.option.com/company/disclaimer.shtml
RPR Leuven 0429.375.448
On 10/09/2013 03:58 PM, Eric Verdonck wrote:
> Hi all,
>
> Thank you very much for your problem report. The line
> le16_to_cpu(serial_state_notification->wIndex) != W_INDEX) in the
> function "tiocmget_intr_callback" of the hso driver intents to discard
> the notification if the notification urb is not coming from the modem
> interface. Actually the line discards the urb if the interface number
> differs from the hard coded value W_INDEX ( see Table 67:
> Class-Specific Notifications of
> www.usb.org/developers/devclass_docs/usbcdc11.pdf for the meaning of
> wIndex). Depending of the tyoe of device used and/or depending of the
> actual configuration of the device the interface number of the modem
> port will vary. Therefore I would like to suggest to remove this check
> and replace it by a discard if the urb doesn't belong to an interface
> with its port_spec set to HSO_PORT_MODEM. This test has the advantage
> that it's independend of the actual configuration or type of the modem
> device ( see patch below)
>
> diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
> index e2dd324..288ec46 100644
> --- a/drivers/net/usb/hso.c
> +++ b/drivers/net/usb/hso.c
> @@ -1503,7 +1503,7 @@ static void tiocmget_intr_callback(struct urb *urb)
> if (serial_state_notification->bmRequestType != BM_REQUEST_TYPE ||
> serial_state_notification->bNotification != B_NOTIFICATION ||
> le16_to_cpu(serial_state_notification->wValue) != W_VALUE ||
> - le16_to_cpu(serial_state_notification->wIndex) != W_INDEX ||
> + (serial->parent->port_spec & HSO_PORT_MASK) != HSO_PORT_MODEM ||
> le16_to_cpu(serial_state_notification->wLength) != W_LENGTH) {
> dev_warn(&usb->dev,
> "hso received invalid serial state notification\n");
> Best regards,
> Eric Verdonck
> Firmware development engineer
> Option nv, Gaston Geenslaan 14, B-3001 Leuven
>
> T: +32 16 311 597
> F: +32 16 207 164
> E-mail:e.verdonck@option.com
> Website:www.option.com
> Disclaimer:http://www.option.com/company/disclaimer.shtml
>
> RPR Leuven 0429.375.448
>
> On 10/09/2013 01:37 PM, Jan Dumon wrote:
>>
>>
>>
>> -------- Original Message --------
>> Subject: Fwd: [PATCH 1/1] hso: fix problem with wrong status code
>> sent by OPTION GTM601 during RING indication
>> Date: Fri, 4 Oct 2013 08:49:46 +0200
>> From: Jan Dumon <J.Dumon@option.com>
>> To: Axel Schollaert <a.schollaert@option.com>
>>
>>
>>
>>
>>
>>
>> -------- Original Message --------
>> Subject: [PATCH 1/1] hso: fix problem with wrong status code sent by
>> OPTION GTM601 during RING indication
>> Date: Wed, 2 Oct 2013 09:00:18 +0200
>> From: Dr. H. Nikolaus Schaller <hns@goldelico.com>
>> To: Jan Dumon <j.dumon@option.com>
>> CC: Belisko Marek <marek.belisko@gmail.com>,
>> linux-usb@vger.kernel.org, netdev@vger.kernel.org,
>> linux-kernel@vger.kernel.org
>>
>>
>>
>> Hi Jan,
>>
>> we are using a GTM601 modem (Firmware 1.7) for a while and have spotted an
>> issue that under some conditions the modem sends a packed wIndex over USB
>> that is rejected by the hso driver making troubles afterwards. Not rejecting makes
>> it work fine.
>>
>> BR,
>> Nikolaus Schaller
>>
>> ---
>>
>> From f5c7e15b61f2ce4fe3105ff914f6bfaf5d74af0d Mon Sep 17 00:00:00 2001
>> From: "H. Nikolaus Schaller"<hns@goldelico.com>
>> Date: Thu, 15 Nov 2012 14:40:57 +0100
>> Subject: [PATCH 1/1] hso: fix problem with wrong status code sent by OPTION
>> GTM601 during RING indication
>>
>> It has been observed that the GTM601 with 1.7 firmware sometimes sends a value
>> wIndex that has bit 0x04 set instead of being reset as the code expects. So we
>> mask it for the error check.
>>
>> Seehttp://lists.goldelico.com/pipermail/gta04-owner/2012-February/001643.html
>>
>> Signed-off-by: NeilBrown<neilb@suse.de>
>> Signed-off-by: H. Nikolaus Schaller<hns@goldelico.de>
>> ---
>> drivers/net/usb/hso.c | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
>> index cba1d46..d146e26 100644
>> --- a/drivers/net/usb/hso.c
>> +++ b/drivers/net/usb/hso.c
>> @@ -1503,7 +1503,8 @@ static void tiocmget_intr_callback(struct urb *urb)
>> if (serial_state_notification->bmRequestType != BM_REQUEST_TYPE ||
>> serial_state_notification->bNotification != B_NOTIFICATION ||
>> le16_to_cpu(serial_state_notification->wValue) != W_VALUE ||
>> - le16_to_cpu(serial_state_notification->wIndex) != W_INDEX ||
>> + (le16_to_cpu(serial_state_notification->wIndex) & ~0x4) !=
>> + W_INDEX ||
>> le16_to_cpu(serial_state_notification->wLength) != W_LENGTH) {
>> dev_warn(&usb->dev,
>> "hso received invalid serial state notification\n");
>> --
>> 1.7.7.4
>>
>>
>>
>>
>>
>>
>
^ permalink raw reply
* Re: [PATCH] Stmmac: fix a bug when clk_csr == 0x0
From: Wan ZongShun @ 2013-10-09 15:02 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: netdev
In-Reply-To: <52556BA2.1080004@st.com>
2013/10/9 Giuseppe CAVALLARO <peppe.cavallaro@st.com>:
> hello
>
>
> On 10/9/2013 4:37 AM, Wan ZongShun wrote:
>>
>> Hi Giuseppe,
>>
>> According to spec, if csr clock freq is 60-100Mhz, we have to set CR[5:2]
>> = 0000
>> but when I set the 'plat_dat.clk_csr = 0',acctually, this value is not
>> used
>> since the driver code judge 'if (!priv->plat->clk_csr)' then go to dynamic
>> tune
>> the MDC clock. So I add other judge condition.
>
>
> yes, and true in case of 60-100Mhz... I don't know if this was actually
> tested on SPEAr long time ago.
>
Hmmm, I am using other GBE chip based on synopsis IP, so I am testing
it on other platform.
> Pls document the new platform field in the stmmac.txt or find a way
> to reuse the clk_csr (maybe not the case)
Do you mean I need submit the other patch to add some comments for
this new field？
I can not find better way to fix this issue and make it more
compatible to another platform.
Wan.
>
> peppe
>
>
>>
>> Signed-off-by: Wan Zongshun <mcuos.com@gmail.com>
>> ---
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
>> include/linux/stmmac.h | 1 +
>> 2 files changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index 8d4ccd3..a849092c 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -2741,7 +2741,7 @@ struct stmmac_priv *stmmac_dvr_probe(struct
>> device *device,
>> * set the MDC clock dynamically according to the csr actual
>> * clock input.
>> */
>> - if (!priv->plat->clk_csr)
>> + if (priv->plat->dynamic_mdc_clk_en)
>> stmmac_clk_csr_set(priv);
>> else
>> priv->clk_csr = priv->plat->clk_csr;
>> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
>> index bb5deb0..e2552ce 100644
>> --- a/include/linux/stmmac.h
>> +++ b/include/linux/stmmac.h
>> @@ -101,6 +101,7 @@ struct plat_stmmacenet_data {
>> struct stmmac_mdio_bus_data *mdio_bus_data;
>> struct stmmac_dma_cfg *dma_cfg;
>> int clk_csr;
>> + int dynamic_mdc_clk_en;
>> int has_gmac;
>> int enh_desc;
>> int tx_coe;
>>
>
--
Wan ZongShun.
www.mcuos.com
^ permalink raw reply
* Re: [PATCH] Stmmac: fix a bug when clk_csr == 0x0
From: Giuseppe CAVALLARO @ 2013-10-09 14:43 UTC (permalink / raw)
To: Wan ZongShun; +Cc: netdev
In-Reply-To: <CAKT61h8mcj1Gvp1i8xkM_NS2+fv1WhPtCQaFq7mi=i=JUqT4Uw@mail.gmail.com>
hello
On 10/9/2013 4:37 AM, Wan ZongShun wrote:
> Hi Giuseppe,
>
> According to spec, if csr clock freq is 60-100Mhz, we have to set CR[5:2] = 0000
> but when I set the 'plat_dat.clk_csr = 0',acctually, this value is not used
> since the driver code judge 'if (!priv->plat->clk_csr)' then go to dynamic tune
> the MDC clock. So I add other judge condition.
yes, and true in case of 60-100Mhz... I don't know if this was actually
tested on SPEAr long time ago.
Pls document the new platform field in the stmmac.txt or find a way
to reuse the clk_csr (maybe not the case)
peppe
>
> Signed-off-by: Wan Zongshun <mcuos.com@gmail.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
> include/linux/stmmac.h | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 8d4ccd3..a849092c 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2741,7 +2741,7 @@ struct stmmac_priv *stmmac_dvr_probe(struct
> device *device,
> * set the MDC clock dynamically according to the csr actual
> * clock input.
> */
> - if (!priv->plat->clk_csr)
> + if (priv->plat->dynamic_mdc_clk_en)
> stmmac_clk_csr_set(priv);
> else
> priv->clk_csr = priv->plat->clk_csr;
> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> index bb5deb0..e2552ce 100644
> --- a/include/linux/stmmac.h
> +++ b/include/linux/stmmac.h
> @@ -101,6 +101,7 @@ struct plat_stmmacenet_data {
> struct stmmac_mdio_bus_data *mdio_bus_data;
> struct stmmac_dma_cfg *dma_cfg;
> int clk_csr;
> + int dynamic_mdc_clk_en;
> int has_gmac;
> int enh_desc;
> int tx_coe;
>
^ permalink raw reply
* Re: [PATCH] Stmmac: fix a bug when clk_csr == 0x0
From: Giuseppe CAVALLARO @ 2013-10-09 15:16 UTC (permalink / raw)
To: Wan ZongShun; +Cc: netdev
In-Reply-To: <CAKT61h8ZLQRUsD99vOYyK8jj0o_SHhA+PN4MoPA5SS9V+eit5g@mail.gmail.com>
On 10/9/2013 5:02 PM, Wan ZongShun wrote:
> 2013/10/9 Giuseppe CAVALLARO <peppe.cavallaro@st.com>:
>> hello
>>
>>
>> On 10/9/2013 4:37 AM, Wan ZongShun wrote:
>>>
>>> Hi Giuseppe,
>>>
>>> According to spec, if csr clock freq is 60-100Mhz, we have to set CR[5:2]
>>> = 0000
>>> but when I set the 'plat_dat.clk_csr = 0',acctually, this value is not
>>> used
>>> since the driver code judge 'if (!priv->plat->clk_csr)' then go to dynamic
>>> tune
>>> the MDC clock. So I add other judge condition.
>>
>>
>> yes, and true in case of 60-100Mhz... I don't know if this was actually
>> tested on SPEAr long time ago.
>>
>
> Hmmm, I am using other GBE chip based on synopsis IP, so I am testing
> it on other platform.
>
>> Pls document the new platform field in the stmmac.txt or find a way
>> to reuse the clk_csr (maybe not the case)
>
> Do you mean I need submit the other patch to add some comments for
> this new field？
yes in the Documentation/networking/stmmac.txt
peppe
> I can not find better way to fix this issue and make it more
> compatible to another platform.
>
> Wan.
>
>>
>> peppe
>>
>>
>>>
>>> Signed-off-by: Wan Zongshun <mcuos.com@gmail.com>
>>> ---
>>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
>>> include/linux/stmmac.h | 1 +
>>> 2 files changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> index 8d4ccd3..a849092c 100644
>>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> @@ -2741,7 +2741,7 @@ struct stmmac_priv *stmmac_dvr_probe(struct
>>> device *device,
>>> * set the MDC clock dynamically according to the csr actual
>>> * clock input.
>>> */
>>> - if (!priv->plat->clk_csr)
>>> + if (priv->plat->dynamic_mdc_clk_en)
>>> stmmac_clk_csr_set(priv);
>>> else
>>> priv->clk_csr = priv->plat->clk_csr;
>>> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
>>> index bb5deb0..e2552ce 100644
>>> --- a/include/linux/stmmac.h
>>> +++ b/include/linux/stmmac.h
>>> @@ -101,6 +101,7 @@ struct plat_stmmacenet_data {
>>> struct stmmac_mdio_bus_data *mdio_bus_data;
>>> struct stmmac_dma_cfg *dma_cfg;
>>> int clk_csr;
>>> + int dynamic_mdc_clk_en;
>>> int has_gmac;
>>> int enh_desc;
>>> int tx_coe;
>>>
>>
>
>
>
^ permalink raw reply
* Re: [PATCH net 0/4] bridge: Fix problems around the PVID
From: Vlad Yasevich @ 2013-10-09 15:01 UTC (permalink / raw)
To: Toshiaki Makita
Cc: Toshiaki Makita, David Miller, netdev, Fernando Luis Vazquez Cao,
Patrick McHardy
In-Reply-To: <1380628602.3150.59.camel@ubuntu-vm-makita>
On 10/01/2013 07:56 AM, Toshiaki Makita wrote:
> On Mon, 2013-09-30 at 12:01 -0400, Vlad Yasevich wrote:
>> On 09/30/2013 07:46 AM, Toshiaki Makita wrote:
>>> On Fri, 2013-09-27 at 14:10 -0400, Vlad Yasevich wrote:
>>>> 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?
>>>
>>> Untagged frame's priority is by default 0, so I think 0 is likely.
>>>
>>> 802.1Q 6.9.1 i) The received priority value and the drop_eligible
>>> parameter value are the values in the M_UNITDATA.indication.
>>>
>>> M_UNITDATA is passed from ISS.
>>>
>>> 802.1Q 6.7.1 The priority parameter provided in a data indication
>>> primitive shall take the value of the Default User Priority parameter
>>> for the Port through which the MAC frame was received. The default
>>> value of this parameter is 0, it may be set by management in which
>>> case the capability to set it to any of the values 0 through 7 shall
>>> be provided.
>>>
>>>>
>>>>> 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.
>>>
>>> If we don't insert prio_tag when PCP is 0, we might receive mixed
>>> priority-tagged and untagged frames on eth0.
>>
>> Right, and that's what you were trying to handle in your patch:
>>
>>> + /* PVID is set on this port. Any untagged or priority-tagged +
>>> * ingress frame is considered to belong to this vlan. */
>>
>> So, in this case we are prepared to handle the "mixed" scenario on ingress.
>>
>>> Even if we are sending frames from eth0.0 with some priority other
>>> than 0, we could receive frames with priority 0 or untagged on the
>>> other side of the bridge.
>>> For example, if we receive untagged arp reply on the bridge port, we
>>> migit not be able to communicate with such an end station, because
>>> untagged reply will not be passed to eth0.0.
>>
>> So the ARP request was sent tagged, but the reply came back untagged?
>
> Yes, it can happen.
> These are problematic cases.
>
> Example 1:
> prio_tagged prio_tagged
> +------------+ ---> +------------+ ---> +----------+
> |guest eth0.0|------|host1 Bridge|------|host2 eth0|
> +------------+ <--- +------------+ <--- +----------+
> untagged untagged
>
> Note: Host2 eth0, which is an interface on Linux, can receive
> priority-tagged frames if it doesn't have vlan 0 interface (eth0.0).
Hmm.. Just to see if this works, I ran the this scenario with
a dumb switch in the middle, and it did not work as you noted.
I then realized that one of the kernels was rather old and after
updating it, behaved differently. The communication still didn't
work, but host2 behaved properly.
>>
>> How does that work when the end station is attached directly to the
>> HW switch instead of a linux bridge?
>>
>> The station configures eth0.0 and sends priority-tagged traffic to
>> the HW switch. If the HW switch sends back untagged traffic, then
>> the untagged traffic will never reach eth0.0.
>
> Currently we cannot communicate using eth0.0 via directly connected
> 802.1Q conformed switch, because we never receive priority-tagged frames
> from the switch.
> It is not a problem of Linux bridge and is why I wondered whether it
> should be fixed by bridge or vlan 0 interface.
>
>>
>>>
>>>>
>>>>> 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
>>>
>>> I'd like to use priority 0 for untagged frames.
>>>
>>> I am assuming that one of our goals is at least that eth0.0 comes to
>>> be able to communicate with another end station. It seems to be hard
>>> to use both eth0 and eth0.0 simultaneously.
>>
>> I understand, but I don't agree that we should always tag.
>>
>> Consider config:
>>
>> hw switch <---> (eth0: Linux Bridge: eth1) <--- (em1.0:end station)
>>
>> If the end station sends priority-tagged traffic it should receive
>> priority tagged traffic back. Otherwise, untagged traffic may be
>> dropped by the end station. This is true whether it is connected to
>> the hw switch or Linux bridge.
>
> Though such a behavior is generally not necessary as far as I can read
> 802.1Q spec, it is essential for vlan 0 interface on Linux, I think.
> My proposal aims to resolve it at least when we use Linux bridge.
>
> Example configuration:
> bridge vlan add vid 10 dev eth1 pvid untagged
> bridge vlan add vid 10 dev eth0
> bridge vlan set prio_tag on dev eth1
>
> Intended behavior:
>
> VID10-tagged prio_tagged
> +---------+ <--- +------------------------+ <--- +-----------------+
> |hw switch|------|eth0: Linux Bridge: eth1|------|em1.0:end station|
> +---------+ ---> +------------------------+ ---> +-----------------+
> VID10-tagged prio_tagged
> (always if egress policy untagged)
Ok, I think you've convinced me that this is the right approach. The
only thing that I am not crazy about is the API. I'd almost want to
introduce a new flag that can be set in a 'vlan add' or 'vlan set'
command that communicates a new policy.
Thanks
-vlad
>
> Thanks,
>
> Toshiaki Makita
>
>>
>> -vlad
>>
>>>
>>> Thanks,
>>>
>>> Toshiaki Makita
>>>
>>>>
>>>> -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
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
> --
> 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: [RFC] net: stmmac: keep RXC running in LPI mode to avoid system overload
From: Giuseppe CAVALLARO @ 2013-10-09 15:28 UTC (permalink / raw)
To: Romain Baeriswyl; +Cc: David S. Miller, netdev, linux-kernel, Romain Baeriswyl
In-Reply-To: <1381244795-3922-1-git-send-email-romainba@abilis.com>
Hello Romain
On 10/8/2013 5:06 PM, Romain Baeriswyl wrote:
> In order to avoid system overload, the clock RXC from the Phy should not be
> stopped when in LPI mode.
>
> With the RTL8211E PHY which support EEE mode and with Apple Airport Extreme that
> supports it also, the kernel get frozen as soon as some Ethernet transfers are
hmm, I have a board with this transceiver so I could do some tests
this could take a while, unfortunately.
> on-going. System seems to be overloaded with too many interrupts. The 'top'
> command reports often around ~80% irq.
do you mean lpi mac interrupts?
>
> By letting the RXC clock running even in LPI mode as proposed below, the issue
> seems solved. Is it the right way to proceed?
For EEE capability, RX_CLK may be halted for this reason i used it as
default in the stmmac and never seen your issue.
>
> What is the power impact to not stop RXC in LPI mode?
I can point you to "22.2.2.8a Receive direction LPI transition"
in IEEE802-3az... where is it reported that the PHY halt the RX_CLK
in LPI mode.
May I suspect some issues on your HW? or disable it with ethtool
peppe
>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index e9eab29..d40d26b 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -314,7 +314,8 @@ bool stmmac_eee_init(struct stmmac_priv *priv)
> /* MAC core supports the EEE feature. */
> if (priv->dma_cap.eee) {
> /* Check if the PHY supports EEE */
> - if (phy_init_eee(priv->phydev, 1))
> + /* Keeps RXC running in LPI mode to avoid stability issue */
> + if (phy_init_eee(priv->phydev, 0))
> goto out;
>
> if (!priv->eee_active) {
> @@ -770,7 +771,8 @@ static void stmmac_adjust_link(struct net_device *dev)
> /* At this stage, it could be needed to setup the EEE or adjust some
> * MAC related HW registers.
> */
> - priv->eee_enabled = stmmac_eee_init(priv);
> + if (new_state)
> + priv->eee_enabled = stmmac_eee_init(priv);
this seems out of context and not necessary
>
> spin_unlock_irqrestore(&priv->lock, flags);
> }
>
^ permalink raw reply
* pull request: wireless 2013-10-09
From: John W. Linville @ 2013-10-09 15:28 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 16475 bytes --]
Dave,
Please pull this batch of fixes intended for 3.12...
Most of the bits are for iwlwifi -- Johannes says:
"I have a fix for WoWLAN/D3, a PCIe device fix, we're removing a
warning, there's a fix for RF-kill while scanning (which goes together
with a mac80211 fix) and last but not least we have many new PCI IDs."
Also for iwlwifi is a patch from Johannes to correct some merge damage
that crept into the tree before the last merge window.
On top of that, Felix Fietkau sends an ath9k patch to avoid a Tx
scheduling hang when changing channels to do a scan.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 9684d7b0dab3cf3a897edd85dca501d413888d56:
Merge branch 'sfc-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc (2013-10-08 21:56:09 -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 b26082b9945a9aca85d51be37824f852617c7129:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem (2013-10-09 11:19:05 -0400)
----------------------------------------------------------------
Alexander Bondar (1):
iwlwifi: mvm: Disable uAPSD for D3 image
Emmanuel Grumbach (4):
iwlwifi: pcie: don't reset the TX queue counter
iwlwifi: don't WARN on host commands sent when firmware is dead
iwlwifi: pcie: add SKUs for 6000, 6005 and 6235 series
iwlwifi: mvm: call ieee80211_scan_completed when needed
Felix Fietkau (1):
ath9k: fix tx queue scheduling after channel changes
Johannes Berg (1):
iwlwifi: pcie: fix merge damage
John W. Linville (2):
Merge branch 'for-john' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Matti Gottlieb (1):
iwlwifi: pcie: add new SKUs for 7000 & 3160 NIC series
drivers/net/wireless/ath/ath9k/main.c | 23 ++++++++---------
drivers/net/wireless/iwlwifi/iwl-6000.c | 6 +++++
drivers/net/wireless/iwlwifi/iwl-config.h | 1 +
drivers/net/wireless/iwlwifi/iwl-trans.h | 6 +++--
drivers/net/wireless/iwlwifi/mvm/power.c | 5 +++-
drivers/net/wireless/iwlwifi/mvm/scan.c | 12 ++++++++-
drivers/net/wireless/iwlwifi/pcie/drv.c | 42 +++++++++++++++++++++++++++++++
drivers/net/wireless/iwlwifi/pcie/trans.c | 8 +++---
drivers/net/wireless/iwlwifi/pcie/tx.c | 2 ++
9 files changed, 85 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index e4f6590..709301f 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -208,6 +208,7 @@ static bool ath_complete_reset(struct ath_softc *sc, bool start)
struct ath_hw *ah = sc->sc_ah;
struct ath_common *common = ath9k_hw_common(ah);
unsigned long flags;
+ int i;
if (ath_startrecv(sc) != 0) {
ath_err(common, "Unable to restart recv logic\n");
@@ -235,6 +236,15 @@ static bool ath_complete_reset(struct ath_softc *sc, bool start)
}
work:
ath_restart_work(sc);
+
+ for (i = 0; i < ATH9K_NUM_TX_QUEUES; i++) {
+ if (!ATH_TXQ_SETUP(sc, i))
+ continue;
+
+ spin_lock_bh(&sc->tx.txq[i].axq_lock);
+ ath_txq_schedule(sc, &sc->tx.txq[i]);
+ spin_unlock_bh(&sc->tx.txq[i].axq_lock);
+ }
}
ieee80211_wake_queues(sc->hw);
@@ -539,21 +549,10 @@ chip_reset:
static int ath_reset(struct ath_softc *sc)
{
- int i, r;
+ int r;
ath9k_ps_wakeup(sc);
-
r = ath_reset_internal(sc, NULL);
-
- for (i = 0; i < ATH9K_NUM_TX_QUEUES; i++) {
- if (!ATH_TXQ_SETUP(sc, i))
- continue;
-
- spin_lock_bh(&sc->tx.txq[i].axq_lock);
- ath_txq_schedule(sc, &sc->tx.txq[i]);
- spin_unlock_bh(&sc->tx.txq[i].axq_lock);
- }
-
ath9k_ps_restore(sc);
return r;
diff --git a/drivers/net/wireless/iwlwifi/iwl-6000.c b/drivers/net/wireless/iwlwifi/iwl-6000.c
index 30d45e2..8ac305b 100644
--- a/drivers/net/wireless/iwlwifi/iwl-6000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-6000.c
@@ -240,6 +240,12 @@ const struct iwl_cfg iwl6035_2agn_cfg = {
.ht_params = &iwl6000_ht_params,
};
+const struct iwl_cfg iwl6035_2agn_sff_cfg = {
+ .name = "Intel(R) Centrino(R) Ultimate-N 6235 AGN",
+ IWL_DEVICE_6035,
+ .ht_params = &iwl6000_ht_params,
+};
+
const struct iwl_cfg iwl1030_bgn_cfg = {
.name = "Intel(R) Centrino(R) Wireless-N 1030 BGN",
IWL_DEVICE_6030,
diff --git a/drivers/net/wireless/iwlwifi/iwl-config.h b/drivers/net/wireless/iwlwifi/iwl-config.h
index e4d370b..b03c25e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-config.h
+++ b/drivers/net/wireless/iwlwifi/iwl-config.h
@@ -280,6 +280,7 @@ extern const struct iwl_cfg iwl2000_2bgn_cfg;
extern const struct iwl_cfg iwl2000_2bgn_d_cfg;
extern const struct iwl_cfg iwl2030_2bgn_cfg;
extern const struct iwl_cfg iwl6035_2agn_cfg;
+extern const struct iwl_cfg iwl6035_2agn_sff_cfg;
extern const struct iwl_cfg iwl105_bgn_cfg;
extern const struct iwl_cfg iwl105_bgn_d_cfg;
extern const struct iwl_cfg iwl135_bgn_cfg;
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans.h b/drivers/net/wireless/iwlwifi/iwl-trans.h
index dd57a36..80b4750 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans.h
+++ b/drivers/net/wireless/iwlwifi/iwl-trans.h
@@ -601,8 +601,10 @@ static inline int iwl_trans_send_cmd(struct iwl_trans *trans,
{
int ret;
- WARN_ONCE(trans->state != IWL_TRANS_FW_ALIVE,
- "%s bad state = %d", __func__, trans->state);
+ if (trans->state != IWL_TRANS_FW_ALIVE) {
+ IWL_ERR(trans, "%s bad state = %d", __func__, trans->state);
+ return -EIO;
+ }
if (!(cmd->flags & CMD_ASYNC))
lock_map_acquire_read(&trans->sync_cmd_lockdep_map);
diff --git a/drivers/net/wireless/iwlwifi/mvm/power.c b/drivers/net/wireless/iwlwifi/mvm/power.c
index 21407a3..d58e393 100644
--- a/drivers/net/wireless/iwlwifi/mvm/power.c
+++ b/drivers/net/wireless/iwlwifi/mvm/power.c
@@ -273,7 +273,10 @@ static void iwl_mvm_power_build_cmd(struct iwl_mvm *mvm,
if (!mvmvif->queue_params[ac].uapsd)
continue;
- cmd->flags |= cpu_to_le16(POWER_FLAGS_ADVANCE_PM_ENA_MSK);
+ if (mvm->cur_ucode != IWL_UCODE_WOWLAN)
+ cmd->flags |=
+ cpu_to_le16(POWER_FLAGS_ADVANCE_PM_ENA_MSK);
+
cmd->uapsd_ac_flags |= BIT(ac);
/* QNDP TID - the highest TID with no admission control */
diff --git a/drivers/net/wireless/iwlwifi/mvm/scan.c b/drivers/net/wireless/iwlwifi/mvm/scan.c
index 9a7ab84..621fb71 100644
--- a/drivers/net/wireless/iwlwifi/mvm/scan.c
+++ b/drivers/net/wireless/iwlwifi/mvm/scan.c
@@ -394,6 +394,11 @@ static bool iwl_mvm_scan_abort_notif(struct iwl_notif_wait_data *notif_wait,
return false;
}
+ /*
+ * If scan cannot be aborted, it means that we had a
+ * SCAN_COMPLETE_NOTIFICATION in the pipe and it called
+ * ieee80211_scan_completed already.
+ */
IWL_DEBUG_SCAN(mvm, "Scan cannot be aborted, exit now: %d\n",
*resp);
return true;
@@ -417,14 +422,19 @@ void iwl_mvm_cancel_scan(struct iwl_mvm *mvm)
SCAN_COMPLETE_NOTIFICATION };
int ret;
+ if (mvm->scan_status == IWL_MVM_SCAN_NONE)
+ return;
+
iwl_init_notification_wait(&mvm->notif_wait, &wait_scan_abort,
scan_abort_notif,
ARRAY_SIZE(scan_abort_notif),
iwl_mvm_scan_abort_notif, NULL);
- ret = iwl_mvm_send_cmd_pdu(mvm, SCAN_ABORT_CMD, CMD_SYNC, 0, NULL);
+ ret = iwl_mvm_send_cmd_pdu(mvm, SCAN_ABORT_CMD,
+ CMD_SYNC | CMD_SEND_IN_RFKILL, 0, NULL);
if (ret) {
IWL_ERR(mvm, "Couldn't send SCAN_ABORT_CMD: %d\n", ret);
+ /* mac80211's state will be cleaned in the fw_restart flow */
goto out_remove_notif;
}
diff --git a/drivers/net/wireless/iwlwifi/pcie/drv.c b/drivers/net/wireless/iwlwifi/pcie/drv.c
index dc02cb9..26108a1 100644
--- a/drivers/net/wireless/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/iwlwifi/pcie/drv.c
@@ -139,13 +139,16 @@ static DEFINE_PCI_DEVICE_TABLE(iwl_hw_card_ids) = {
/* 6x00 Series */
{IWL_PCI_DEVICE(0x422B, 0x1101, iwl6000_3agn_cfg)},
+ {IWL_PCI_DEVICE(0x422B, 0x1108, iwl6000_3agn_cfg)},
{IWL_PCI_DEVICE(0x422B, 0x1121, iwl6000_3agn_cfg)},
+ {IWL_PCI_DEVICE(0x422B, 0x1128, iwl6000_3agn_cfg)},
{IWL_PCI_DEVICE(0x422C, 0x1301, iwl6000i_2agn_cfg)},
{IWL_PCI_DEVICE(0x422C, 0x1306, iwl6000i_2abg_cfg)},
{IWL_PCI_DEVICE(0x422C, 0x1307, iwl6000i_2bg_cfg)},
{IWL_PCI_DEVICE(0x422C, 0x1321, iwl6000i_2agn_cfg)},
{IWL_PCI_DEVICE(0x422C, 0x1326, iwl6000i_2abg_cfg)},
{IWL_PCI_DEVICE(0x4238, 0x1111, iwl6000_3agn_cfg)},
+ {IWL_PCI_DEVICE(0x4238, 0x1118, iwl6000_3agn_cfg)},
{IWL_PCI_DEVICE(0x4239, 0x1311, iwl6000i_2agn_cfg)},
{IWL_PCI_DEVICE(0x4239, 0x1316, iwl6000i_2abg_cfg)},
@@ -153,12 +156,16 @@ static DEFINE_PCI_DEVICE_TABLE(iwl_hw_card_ids) = {
{IWL_PCI_DEVICE(0x0082, 0x1301, iwl6005_2agn_cfg)},
{IWL_PCI_DEVICE(0x0082, 0x1306, iwl6005_2abg_cfg)},
{IWL_PCI_DEVICE(0x0082, 0x1307, iwl6005_2bg_cfg)},
+ {IWL_PCI_DEVICE(0x0082, 0x1308, iwl6005_2agn_cfg)},
{IWL_PCI_DEVICE(0x0082, 0x1321, iwl6005_2agn_cfg)},
{IWL_PCI_DEVICE(0x0082, 0x1326, iwl6005_2abg_cfg)},
+ {IWL_PCI_DEVICE(0x0082, 0x1328, iwl6005_2agn_cfg)},
{IWL_PCI_DEVICE(0x0085, 0x1311, iwl6005_2agn_cfg)},
+ {IWL_PCI_DEVICE(0x0085, 0x1318, iwl6005_2agn_cfg)},
{IWL_PCI_DEVICE(0x0085, 0x1316, iwl6005_2abg_cfg)},
{IWL_PCI_DEVICE(0x0082, 0xC020, iwl6005_2agn_sff_cfg)},
{IWL_PCI_DEVICE(0x0085, 0xC220, iwl6005_2agn_sff_cfg)},
+ {IWL_PCI_DEVICE(0x0085, 0xC228, iwl6005_2agn_sff_cfg)},
{IWL_PCI_DEVICE(0x0082, 0x4820, iwl6005_2agn_d_cfg)},
{IWL_PCI_DEVICE(0x0082, 0x1304, iwl6005_2agn_mow1_cfg)},/* low 5GHz active */
{IWL_PCI_DEVICE(0x0082, 0x1305, iwl6005_2agn_mow2_cfg)},/* high 5GHz active */
@@ -240,8 +247,11 @@ static DEFINE_PCI_DEVICE_TABLE(iwl_hw_card_ids) = {
/* 6x35 Series */
{IWL_PCI_DEVICE(0x088E, 0x4060, iwl6035_2agn_cfg)},
+ {IWL_PCI_DEVICE(0x088E, 0x406A, iwl6035_2agn_sff_cfg)},
{IWL_PCI_DEVICE(0x088F, 0x4260, iwl6035_2agn_cfg)},
+ {IWL_PCI_DEVICE(0x088F, 0x426A, iwl6035_2agn_sff_cfg)},
{IWL_PCI_DEVICE(0x088E, 0x4460, iwl6035_2agn_cfg)},
+ {IWL_PCI_DEVICE(0x088E, 0x446A, iwl6035_2agn_sff_cfg)},
{IWL_PCI_DEVICE(0x088E, 0x4860, iwl6035_2agn_cfg)},
{IWL_PCI_DEVICE(0x088F, 0x5260, iwl6035_2agn_cfg)},
@@ -260,54 +270,86 @@ static DEFINE_PCI_DEVICE_TABLE(iwl_hw_card_ids) = {
#if IS_ENABLED(CONFIG_IWLMVM)
/* 7000 Series */
{IWL_PCI_DEVICE(0x08B1, 0x4070, iwl7260_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0x4072, iwl7260_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0x4170, iwl7260_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0x4060, iwl7260_2n_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0x406A, iwl7260_2n_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0x4160, iwl7260_2n_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0x4062, iwl7260_n_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0x4162, iwl7260_n_cfg)},
{IWL_PCI_DEVICE(0x08B2, 0x4270, iwl7260_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B2, 0x4272, iwl7260_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B2, 0x4260, iwl7260_2n_cfg)},
+ {IWL_PCI_DEVICE(0x08B2, 0x426A, iwl7260_2n_cfg)},
{IWL_PCI_DEVICE(0x08B2, 0x4262, iwl7260_n_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0x4470, iwl7260_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0x4472, iwl7260_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0x4460, iwl7260_2n_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0x446A, iwl7260_2n_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0x4462, iwl7260_n_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0x4870, iwl7260_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0x486E, iwl7260_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0x4A70, iwl7260_2ac_cfg_high_temp)},
{IWL_PCI_DEVICE(0x08B1, 0x4A6E, iwl7260_2ac_cfg_high_temp)},
{IWL_PCI_DEVICE(0x08B1, 0x4A6C, iwl7260_2ac_cfg_high_temp)},
+ {IWL_PCI_DEVICE(0x08B1, 0x4570, iwl7260_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0x4560, iwl7260_2n_cfg)},
+ {IWL_PCI_DEVICE(0x08B2, 0x4370, iwl7260_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B2, 0x4360, iwl7260_2n_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0x5070, iwl7260_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0x4020, iwl7260_2n_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0x402A, iwl7260_2n_cfg)},
{IWL_PCI_DEVICE(0x08B2, 0x4220, iwl7260_2n_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0x4420, iwl7260_2n_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0xC070, iwl7260_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0xC072, iwl7260_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0xC170, iwl7260_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0xC060, iwl7260_2n_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0xC06A, iwl7260_2n_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0xC160, iwl7260_2n_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0xC062, iwl7260_n_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0xC162, iwl7260_n_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0xC770, iwl7260_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0xC760, iwl7260_2n_cfg)},
{IWL_PCI_DEVICE(0x08B2, 0xC270, iwl7260_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B2, 0xC272, iwl7260_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B2, 0xC260, iwl7260_2n_cfg)},
+ {IWL_PCI_DEVICE(0x08B2, 0xC26A, iwl7260_n_cfg)},
{IWL_PCI_DEVICE(0x08B2, 0xC262, iwl7260_n_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0xC470, iwl7260_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0xC472, iwl7260_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0xC460, iwl7260_2n_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0xC462, iwl7260_n_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0xC570, iwl7260_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0xC560, iwl7260_2n_cfg)},
+ {IWL_PCI_DEVICE(0x08B2, 0xC370, iwl7260_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0xC360, iwl7260_2n_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0xC020, iwl7260_2n_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0xC02A, iwl7260_2n_cfg)},
{IWL_PCI_DEVICE(0x08B2, 0xC220, iwl7260_2n_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0xC420, iwl7260_2n_cfg)},
/* 3160 Series */
{IWL_PCI_DEVICE(0x08B3, 0x0070, iwl3160_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B3, 0x0072, iwl3160_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B3, 0x0170, iwl3160_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B3, 0x0172, iwl3160_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B3, 0x0060, iwl3160_2n_cfg)},
{IWL_PCI_DEVICE(0x08B3, 0x0062, iwl3160_n_cfg)},
{IWL_PCI_DEVICE(0x08B4, 0x0270, iwl3160_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B4, 0x0272, iwl3160_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B3, 0x0470, iwl3160_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B3, 0x0472, iwl3160_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B4, 0x0370, iwl3160_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B3, 0x8070, iwl3160_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B3, 0x8072, iwl3160_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B3, 0x8170, iwl3160_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B3, 0x8172, iwl3160_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B3, 0x8060, iwl3160_2n_cfg)},
{IWL_PCI_DEVICE(0x08B3, 0x8062, iwl3160_n_cfg)},
{IWL_PCI_DEVICE(0x08B4, 0x8270, iwl3160_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B3, 0x8470, iwl3160_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B3, 0x8570, iwl3160_2ac_cfg)},
#endif /* CONFIG_IWLMVM */
{0}
diff --git a/drivers/net/wireless/iwlwifi/pcie/trans.c b/drivers/net/wireless/iwlwifi/pcie/trans.c
index bad95d2..c3f904d 100644
--- a/drivers/net/wireless/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/iwlwifi/pcie/trans.c
@@ -1401,6 +1401,10 @@ struct iwl_trans *iwl_trans_pcie_alloc(struct pci_dev *pdev,
spin_lock_init(&trans_pcie->reg_lock);
init_waitqueue_head(&trans_pcie->ucode_write_waitq);
+ err = pci_enable_device(pdev);
+ if (err)
+ goto out_no_pci;
+
if (!cfg->base_params->pcie_l1_allowed) {
/*
* W/A - seems to solve weird behavior. We need to remove this
@@ -1412,10 +1416,6 @@ struct iwl_trans *iwl_trans_pcie_alloc(struct pci_dev *pdev,
PCIE_LINK_STATE_CLKPM);
}
- err = pci_enable_device(pdev);
- if (err)
- goto out_no_pci;
-
pci_set_master(pdev);
err = pci_set_dma_mask(pdev, DMA_BIT_MASK(36));
diff --git a/drivers/net/wireless/iwlwifi/pcie/tx.c b/drivers/net/wireless/iwlwifi/pcie/tx.c
index f45eb29..1424335 100644
--- a/drivers/net/wireless/iwlwifi/pcie/tx.c
+++ b/drivers/net/wireless/iwlwifi/pcie/tx.c
@@ -1102,6 +1102,8 @@ void iwl_trans_pcie_txq_enable(struct iwl_trans *trans, int txq_id, int fifo,
* non-AGG queue.
*/
iwl_clear_bits_prph(trans, SCD_AGGR_SEL, BIT(txq_id));
+
+ ssn = trans_pcie->txq[txq_id].q.read_ptr;
}
/* Place first TFD at index corresponding to start sequence number.
--
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 RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Tejun Heo @ 2013-10-09 15:41 UTC (permalink / raw)
To: Alexander Gordeev
Cc: Benjamin Herrenschmidt, Ben Hutchings, linux-kernel,
Bjorn Helgaas, Ralf Baechle, Michael Ellerman, Martin Schwidefsky,
Ingo Molnar, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips, linuxppc-dev, linux390, linux-s390, x86,
linux-ide, iss_storagedev, linux-nvme, linux-rdma, netdev,
e1000-devel, linux-driver, Solarflare linux maintainers, "VMw
In-Reply-To: <20131008122215.GA14389@dhcp-26-207.brq.redhat.com>
Hello,
On Tue, Oct 08, 2013 at 02:22:16PM +0200, Alexander Gordeev wrote:
> If we talk about pSeries quota, then the current pSeries pci_enable_msix()
> implementation is racy internally and could fail if the quota went down
> *while* pci_enable_msix() is executing. In this case the loop will have to
> exit rather than retry with a lower number (what number?).
Ah, okay, so that one is already broken.
> In this regard the new scheme does not bring anything new and relies on
> the fact this race does not hit and therefore does not worry.
>
> If we talk about quota as it has to be, then yes - the loop scheme seems
> more preferable.
>
> Overall, looks like we just need to fix the pSeries implementation,
> if the guys want it, he-he :)
If we can't figure out a better interface for the retry case, I think
what can really help is having a simple interface for the simpler
cases.
> > The problem case is where multiple msi(x) allocation fails completely
> > because the global limit went down before inquiry and allocation. In
> > the loop based interface, it'd retry with the lower number.
>
> I am probably missing something here. If the global limit went down before
> inquiry then the inquiry will get what is available and try to allocate with
> than number.
Oh, I should have written between inquiry and allocation. Sorry.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Tejun Heo @ 2013-10-09 15:43 UTC (permalink / raw)
To: Alexander Gordeev
Cc: Benjamin Herrenschmidt, Ben Hutchings, linux-kernel,
Bjorn Helgaas, Ralf Baechle, Michael Ellerman, Martin Schwidefsky,
Ingo Molnar, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips, linuxppc-dev, linux390, linux-s390, x86,
linux-ide, iss_storagedev, linux-nvme, linux-rdma, netdev,
e1000-devel, linux-driver, Solarflare linux maintainers, "VMw
In-Reply-To: <20131009125715.GC32733@dhcp-26-207.brq.redhat.com>
Hello,
On Wed, Oct 09, 2013 at 02:57:16PM +0200, Alexander Gordeev wrote:
> On Mon, Oct 07, 2013 at 02:01:11PM -0400, Tejun Heo wrote:
> > Hmmm... yean, the race condition could be an issue as multiple msi
> > allocation might fail even if the driver can and explicitly handle
> > multiple allocation if the quota gets reduced inbetween.
>
> BTW, should we care about the quota getting increased inbetween?
> That would entail.. kind of pci_get_msi_limit() :), but IMHO it is
> not worth it.
I think we shouldn't. If the resource was low during a point in time
during allocation, it's fine to base the result on that - the resource
was actually low and which answer we return is just a question of
timing and both are correct. The only reason the existing race
condition is problematic is because it may fail even if the resource
never falls below the failure point.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Tejun Heo @ 2013-10-09 15:46 UTC (permalink / raw)
To: Ben Hutchings
Cc: Alexander Gordeev, Benjamin Herrenschmidt, linux-kernel,
Bjorn Helgaas, Ralf Baechle, Michael Ellerman, Martin Schwidefsky,
Ingo Molnar, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips, linuxppc-dev, linux390, linux-s390, x86,
linux-ide, iss_storagedev, linux-nvme, linux-rdma, netdev,
e1000-devel, linux-driver, Solarflare linux maintainers,
"VMwar
In-Reply-To: <1381178881.1536.28.camel@bwh-desktop.uk.level5networks.com>
On Mon, Oct 07, 2013 at 09:48:01PM +0100, Ben Hutchings wrote:
> > There is one major flaw in min-max approach - the generic MSI layer
> > will have to take decisions on exact number of MSIs to request, not
> > device drivers.
> [...
>
> No, the min-max functions should be implemented using the same loop that
> drivers are expected to use now.
Wheee... earlier in the thread I thought you guys were referring to
yourselves in the third person and was getting a bit worried. :)
--
tejun
^ permalink raw reply
* Re: [PATCH RFC 07/77] PCI/MSI: Re-design MSI/MSI-X interrupts enablement pattern
From: Tejun Heo @ 2013-10-09 15:54 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-kernel, Bjorn Helgaas, Ralf Baechle, Michael Ellerman,
Benjamin Herrenschmidt, Martin Schwidefsky, Ingo Molnar,
Dan Williams, Andy King, Jon Mason, Matt Porter, linux-pci,
linux-doc, linux-mips, linuxppc-dev, linux390, linux-s390, x86,
linux-ide, iss_storagedev, linux-nvme, linux-rdma, netdev,
e1000-devel, linux-driver, Solarflare linux maintainers,
"VMware, Inc." <pv-dr
In-Reply-To: <20131008074826.GD10669@dhcp-26-207.brq.redhat.com>
Hello, Alexander.
On Tue, Oct 08, 2013 at 09:48:26AM +0200, Alexander Gordeev wrote:
> > If there are many which duplicate the above pattern, it'd probably be
> > worthwhile to provide a helper? It's usually a good idea to reduce
> > the amount of boilerplate code in drivers.
>
> I wanted to limit discussion in v1 to as little changes as possible.
> I 'planned' those helper(s) for a separate effort if/when the most
> important change is accepted and soaked a bit.
The thing is doing it this way generates more churns and noises. Once
the simpler ones live behind a wrapper which can be built on the
existing interface, we can have both reduced cost and more latitude on
the complex cases.
> > If we do things this way, it breaks all drivers using this interface
> > until they're converted, right?
>
> Right. And the rest of the series does it.
Which breaks bisection which we shouldn't do.
> > Also, it probably isn't the best idea
> > to flip the behavior like this as this can go completely unnoticed (no
> > compiler warning or anything, the same function just behaves
> > differently). Maybe it'd be a better idea to introduce a simpler
> > interface that most can be converted to?
>
> Well, an *other* interface is a good idea. What do you mean with the
> simpler here?
I'm still talking about a simpler wrapper for common cases, which is
the important part anyway.
Thanks.
--
tejun
^ permalink raw reply
* RE: [PATCH 10/16] batman-adv: use CRC32C instead of CRC16 in TT code
From: David Laight @ 2013-10-09 15:49 UTC (permalink / raw)
To: Antonio Quartulli
Cc: davem, netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <20131009143500.GH3544@neomailbox.net>
> > Are you really generating CRC32 of a pile of ethernet MAC addresses
> > and the XORing the CRC together?
> > That gives the same answer as XORing together the MAC addresses and
> > then doing a CRC of the final value.
>
> I was not sure about this since the CRC32 is not a linear operation. However
> this routine is not on the fast path, so we can also live with this order.
All CRC are linear.
Because '(a + b) mod c' is the same as '((a mod c) + (b mod c)) mod c'.
The CRC of a buffer is the XOR of the CRCs generated for each '1' bit.
The CRC for each bit depends on how far it is from the end of the buffer.
Presetting the CRC to all-ones generates a value that is dependent on
the length of the buffer - otherwise missing/extra leading zeros are
not detected.
David
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Tejun Heo @ 2013-10-09 15:57 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-kernel, Bjorn Helgaas, Ralf Baechle, Michael Ellerman,
Benjamin Herrenschmidt, Martin Schwidefsky, Ingo Molnar,
Dan Williams, Andy King, Jon Mason, Matt Porter, linux-pci,
linux-mips, linuxppc-dev, linux390, linux-s390, x86, linux-ide,
iss_storagedev, linux-nvme, linux-rdma, netdev, e1000-devel,
linux-driver, Solarflare linux maintainers, VMware, Inc.,
linux-sc
In-Reply-To: <20131008090716.GA10561@dhcp-26-207.brq.redhat.com>
Hello,
On Tue, Oct 08, 2013 at 11:07:16AM +0200, Alexander Gordeev wrote:
> Multipe MSIs is just a handful of drivers, really. MSI-X impact still
Yes, so it's pretty nice to try out things there before going full-on.
> will be huge. But if we opt a different name for the new pci_enable_msix()
> then we could first update pci/msi, then drivers (in few stages possibly)
> and finally remove the old implementation.
Yes, that probably should be the steps to follow eventually. My point
was that you don't have to submit patches for all 7x conversions for
an RFC round. Scanning them and seeing what would be necessary
definitely is a good idea but just giving summary of the full
conversion with several examples should be good enough before settling
on the way forward, which should be easier for all involved.
Thanks a lot for your effort!
--
tejun
^ permalink raw reply
* See the attached file
From: Microsoft Promotion @ 2013-10-09 16:04 UTC (permalink / raw)
In-Reply-To: <1381255842.36752.YahooMailNeo@web5706.biz.mail.ne1.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 21 bytes --]
See the attached file
[-- Attachment #2: MICROSOFT_AWARD_PROMOTION_2013.doc --]
[-- Type: application/msword, Size: 124416 bytes --]
^ permalink raw reply
* Re: [PATCH 10/16] batman-adv: use CRC32C instead of CRC16 in TT code
From: Antonio Quartulli @ 2013-10-09 16:10 UTC (permalink / raw)
To: David Laight; +Cc: davem, netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7385@saturn3.aculab.com>
[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]
On Wed, Oct 09, 2013 at 04:49:53PM +0100, David Laight wrote:
> > > Are you really generating CRC32 of a pile of ethernet MAC addresses
> > > and the XORing the CRC together?
> > > That gives the same answer as XORing together the MAC addresses and
> > > then doing a CRC of the final value.
> >
> > I was not sure about this since the CRC32 is not a linear operation. However
> > this routine is not on the fast path, so we can also live with this order.
>
> All CRC are linear.
> Because '(a + b) mod c' is the same as '((a mod c) + (b mod c)) mod c'.
>
> The CRC of a buffer is the XOR of the CRCs generated for each '1' bit.
> The CRC for each bit depends on how far it is from the end of the buffer.
In our tables we cannot make any assumption about the order of the entries: the
node whom generated the table may store the entries in a different order from
what we have got.
This is why I did not implemented it as a simple CRC of the
whole the GlobalTable/buffer but I CRC'd each MAC+VID on its own.
> Presetting the CRC to all-ones generates a value that is dependent on
> the length of the buffer - otherwise missing/extra leading zeros are
> not detected.
Assuming what I said above (that we cannot make assumptions on the order of the
entries), what is your suggestion?
Regards,
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ 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