* RE: [PATCH v2 3/5] net: ep93xx_eth: allocate buffers using kmalloc()
From: H Hartley Sweeten @ 2011-06-09 20:53 UTC (permalink / raw)
To: Mika Westerberg, netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org, kernel@wantstofly.org,
ryan@bluewatersys.com
In-Reply-To: <7b20107efa24e0a0c956663ddc70b2189f64c04b.1307040443.git.mika.westerberg@iki.fi>
On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
>
> We can use simply kmalloc() to allocate the buffers. This also simplifies the
> code and allows us to perform DMA sync operations more easily.
>
> Memory is allocated with only GFP_KERNEL since there are no DMA allocation
> restrictions on this platform.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Looks ok to me.
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth
From: Mika Westerberg @ 2011-06-09 20:41 UTC (permalink / raw)
To: H Hartley Sweeten
Cc: netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
kernel@wantstofly.org, ryan@bluewatersys.com
In-Reply-To: <ADE657CA350FB648AAC2C43247A983F001F3820B85F3@AUSP01VMBX24.collaborationhost.net>
On Thu, Jun 09, 2011 at 03:27:11PM -0500, H Hartley Sweeten wrote:
> On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
> >
> > As the driver is now passing platform device to the DMA mapping functions,
> > we should give it valid DMA masks.
> >
> > Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> > Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> Since you made this patch the first in the series the commit message is not
> quite right. Other than that:
>
> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Ah, right. I forgot to change the commit message. How about following?
From: Mika Westerberg <mika.westerberg@iki.fi>
Subject: [PATCH 1/5] ep93xx: set DMA masks for the ep93xx_eth
Since the driver uses the DMA API, we should pass it valid DMA masks.
Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
---
arch/arm/mach-ep93xx/core.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index 8207954..1d4b65f 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -402,11 +402,15 @@ static struct resource ep93xx_eth_resource[] = {
}
};
+static u64 ep93xx_eth_dma_mask = DMA_BIT_MASK(32);
+
static struct platform_device ep93xx_eth_device = {
.name = "ep93xx-eth",
.id = -1,
.dev = {
- .platform_data = &ep93xx_eth_data,
+ .platform_data = &ep93xx_eth_data,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .dma_mask = &ep93xx_eth_dma_mask,
},
.num_resources = ARRAY_SIZE(ep93xx_eth_resource),
.resource = ep93xx_eth_resource,
--
1.7.4.4
^ permalink raw reply related
* RE: [PATCH v2 2/5] net: ep93xx_eth: pass struct device to DMA API functions
From: H Hartley Sweeten @ 2011-06-09 20:41 UTC (permalink / raw)
To: Mika Westerberg, netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org, kernel@wantstofly.org,
ryan@bluewatersys.com
In-Reply-To: <c0ddfc297e0ea1e64e58cedd6552c6b2e52c5fe8.1307040443.git.mika.westerberg@iki.fi>
On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
>
> We shouldn't use NULL for any DMA API functions, unless we are dealing with
> ISA or EISA device. So pass correct struct dev pointer to these functions.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Looks right to me..
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* Re: [PATCH 2/3] net: msm_ipc: Add user-space support for MSM_IPC Router
From: Bryan Huntsman @ 2011-06-09 20:41 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: David Miller, kramasub, netdev, linux-arm-msm
In-Reply-To: <201106092215.49079.arnd@arndb.de>
On 06/09/2011 01:15 PM, Arnd Bergmann wrote:
> I can see some good use cases for having a socket to do IPC between OS
> images that have a shared memory interconnect. What I see as most
> problematic is to have it defined in a way that is tightly connected
> to specific hardware from one vendor. If the protocol was defined
> in a way that is useful for communication between virtual machines
> (e.g. on top of virtio) and tranparent PCI bridges, it would probably
> be much more acceptable.
>
> Arnd
Yeah, we're trying to figure out the best way to do socket-based
communication between various images within a SoC. I was thinking that
some kind of registration scheme would be necessary for the new AF to
support different SoCs and communication mechanisms. We'll take a look
at ways to have a generic implementation. Thanks.
- Bryan
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [net-next-2.6 PATCH 4/4] enic: Bug Fix: Fix hardware transmit queue indexing in enic_poll_controller
From: Vasanthy Kolluri @ 2011-06-09 20:37 UTC (permalink / raw)
To: netdev, davem
In-Reply-To: <20110609203620.31838.61879.stgit@savbu-pc100.cisco.com>
From: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Christian Benvenuti <benve@cisco.com>
Signed-off-by: Danny Guo <dannguo@cisco.com>
Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
Signed-off-by: David Wang <dwang2@cisco.com>
---
drivers/net/enic/enic.h | 2 +-
drivers/net/enic/enic_main.c | 8 ++++++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index 2dcf310..f747bce 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -32,7 +32,7 @@
#define DRV_NAME "enic"
#define DRV_DESCRIPTION "Cisco VIC Ethernet NIC Driver"
-#define DRV_VERSION "2.1.1.19"
+#define DRV_VERSION "2.1.1.20"
#define DRV_COPYRIGHT "Copyright 2008-2011 Cisco Systems, Inc"
#define ENIC_BARS_MAX 6
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index eee2526..4c5546d 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -1777,8 +1777,12 @@ static void enic_poll_controller(struct net_device *netdev)
enic_isr_msix_rq(enic->msix_entry[intr].vector,
&enic->napi[i]);
}
- intr = enic_msix_wq_intr(enic, i);
- enic_isr_msix_wq(enic->msix_entry[intr].vector, enic);
+
+ for (i = 0; i < enic->wq_count; i++) {
+ intr = enic_msix_wq_intr(enic, i);
+ enic_isr_msix_wq(enic->msix_entry[intr].vector, enic);
+ }
+
break;
case VNIC_DEV_INTR_MODE_MSI:
enic_isr_msi(enic->pdev->irq, enic);
^ permalink raw reply related
* [net-next-2.6 PATCH 2/4] enic: Log device configuration in detail during driver load
From: Vasanthy Kolluri @ 2011-06-09 20:36 UTC (permalink / raw)
To: netdev, davem
In-Reply-To: <20110609203620.31838.61879.stgit@savbu-pc100.cisco.com>
From: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Christian Benvenuti <benve@cisco.com>
Signed-off-by: Danny Guo <dannguo@cisco.com>
Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
Signed-off-by: David Wang <dwang2@cisco.com>
---
drivers/net/enic/enic.h | 2 +-
drivers/net/enic/enic_res.c | 23 ++++++++++++++++++-----
drivers/net/enic/vnic_enet.h | 7 +++++++
3 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index e0d2ad1..23e2103 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -32,7 +32,7 @@
#define DRV_NAME "enic"
#define DRV_DESCRIPTION "Cisco VIC Ethernet NIC Driver"
-#define DRV_VERSION "2.1.1.16"
+#define DRV_VERSION "2.1.1.17"
#define DRV_COPYRIGHT "Copyright 2008-2011 Cisco Systems, Inc"
#define ENIC_BARS_MAX 6
diff --git a/drivers/net/enic/enic_res.c b/drivers/net/enic/enic_res.c
index 6e5c635..34f4207 100644
--- a/drivers/net/enic/enic_res.c
+++ b/drivers/net/enic/enic_res.c
@@ -97,11 +97,24 @@ int enic_get_vnic_config(struct enic *enic)
dev_info(enic_get_dev(enic),
"vNIC MAC addr %pM wq/rq %d/%d mtu %d\n",
enic->mac_addr, c->wq_desc_count, c->rq_desc_count, c->mtu);
- dev_info(enic_get_dev(enic), "vNIC csum tx/rx %d/%d "
- "tso %d intr timer %d usec rss %d\n",
- ENIC_SETTING(enic, TXCSUM), ENIC_SETTING(enic, RXCSUM),
- ENIC_SETTING(enic, TSO),
- c->intr_timer_usec, ENIC_SETTING(enic, RSS));
+
+ dev_info(enic_get_dev(enic), "vNIC csum tx/rx %s/%s "
+ "tso/lro %s/%s rss %s intr mode %s type %s timer %d usec "
+ "loopback tag 0x%04x\n",
+ ENIC_SETTING(enic, TXCSUM) ? "yes" : "no",
+ ENIC_SETTING(enic, RXCSUM) ? "yes" : "no",
+ ENIC_SETTING(enic, TSO) ? "yes" : "no",
+ ENIC_SETTING(enic, LRO) ? "yes" : "no",
+ ENIC_SETTING(enic, RSS) ? "yes" : "no",
+ c->intr_mode == VENET_INTR_MODE_INTX ? "INTx" :
+ c->intr_mode == VENET_INTR_MODE_MSI ? "MSI" :
+ c->intr_mode == VENET_INTR_MODE_ANY ? "any" :
+ "unknown",
+ c->intr_timer_type == VENET_INTR_TYPE_MIN ? "min" :
+ c->intr_timer_type == VENET_INTR_TYPE_IDLE ? "idle" :
+ "unknown",
+ c->intr_timer_usec,
+ c->loop_tag);
return 0;
}
diff --git a/drivers/net/enic/vnic_enet.h b/drivers/net/enic/vnic_enet.h
index e8740e3..061ad87 100644
--- a/drivers/net/enic/vnic_enet.h
+++ b/drivers/net/enic/vnic_enet.h
@@ -51,4 +51,11 @@ struct vnic_enet_config {
#define VENETF_RSSHASH_TCPIPV6_EX 0x400 /* Hash on TCP + IPv6 ext. fields */
#define VENETF_LOOP 0x800 /* Loopback enabled */
+#define VENET_INTR_TYPE_MIN 0 /* Timer specs min interrupt spacing */
+#define VENET_INTR_TYPE_IDLE 1 /* Timer specs idle time before irq */
+
+#define VENET_INTR_MODE_ANY 0 /* Try MSI-X, then MSI, then INTx */
+#define VENET_INTR_MODE_MSI 1 /* Try MSI then INTx */
+#define VENET_INTR_MODE_INTX 2 /* Try INTx only */
+
#endif /* _VNIC_ENIC_H_ */
^ permalink raw reply related
* [net-next-2.6 PATCH 3/4] enic: Get/Set interrupt resource index for transmit and receive queues
From: Vasanthy Kolluri @ 2011-06-09 20:37 UTC (permalink / raw)
To: netdev, davem
In-Reply-To: <20110609203620.31838.61879.stgit@savbu-pc100.cisco.com>
From: Vasanthy Kolluri <vkolluri@cisco.com>
Instead of deriving the index of a transmit/receive interrupt resource
from the transmit/receive queue index, always save and retrieve it
using an additional variable.
Signed-off-by: Christian Benvenuti <benve@cisco.com>
Signed-off-by: Danny Guo <dannguo@cisco.com>
Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
Signed-off-by: David Wang <dwang2@cisco.com>
---
drivers/net/enic/enic.h | 2 +-
drivers/net/enic/enic_main.c | 4 ++--
drivers/net/enic/vnic_cq.c | 2 ++
drivers/net/enic/vnic_cq.h | 1 +
4 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index 23e2103..2dcf310 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -32,7 +32,7 @@
#define DRV_NAME "enic"
#define DRV_DESCRIPTION "Cisco VIC Ethernet NIC Driver"
-#define DRV_VERSION "2.1.1.17"
+#define DRV_VERSION "2.1.1.19"
#define DRV_COPYRIGHT "Copyright 2008-2011 Cisco Systems, Inc"
#define ENIC_BARS_MAX 6
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index e990988..eee2526 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -153,12 +153,12 @@ static inline unsigned int enic_legacy_notify_intr(void)
static inline unsigned int enic_msix_rq_intr(struct enic *enic, unsigned int rq)
{
- return rq;
+ return enic->cq[enic_cq_rq(enic, rq)].interrupt_offset;
}
static inline unsigned int enic_msix_wq_intr(struct enic *enic, unsigned int wq)
{
- return enic->rq_count + wq;
+ return enic->cq[enic_cq_wq(enic, wq)].interrupt_offset;
}
static inline unsigned int enic_msix_err_intr(struct enic *enic)
diff --git a/drivers/net/enic/vnic_cq.c b/drivers/net/enic/vnic_cq.c
index b86d6ef..0daa1c7 100644
--- a/drivers/net/enic/vnic_cq.c
+++ b/drivers/net/enic/vnic_cq.c
@@ -74,6 +74,8 @@ void vnic_cq_init(struct vnic_cq *cq, unsigned int flow_control_enable,
iowrite32(cq_message_enable, &cq->ctrl->cq_message_enable);
iowrite32(interrupt_offset, &cq->ctrl->interrupt_offset);
writeq(cq_message_addr, &cq->ctrl->cq_message_addr);
+
+ cq->interrupt_offset = interrupt_offset;
}
void vnic_cq_clean(struct vnic_cq *cq)
diff --git a/drivers/net/enic/vnic_cq.h b/drivers/net/enic/vnic_cq.h
index 552d3da..579315c 100644
--- a/drivers/net/enic/vnic_cq.h
+++ b/drivers/net/enic/vnic_cq.h
@@ -57,6 +57,7 @@ struct vnic_cq {
struct vnic_dev_ring ring;
unsigned int to_clean;
unsigned int last_color;
+ unsigned int interrupt_offset;
};
static inline unsigned int vnic_cq_service(struct vnic_cq *cq,
^ permalink raw reply related
* [net-next-2.6 PATCH 1/4] enic: Pass 802.1p bits for packets tagged with vlan zero
From: Vasanthy Kolluri @ 2011-06-09 20:36 UTC (permalink / raw)
To: netdev, davem
In-Reply-To: <20110609203620.31838.61879.stgit@savbu-pc100.cisco.com>
From: Vasanthy Kolluri <vkolluri@cisco.com>
enic driver currently passes 802.1p bits to the upper layers for packets
tagged with non-zero vlan ids only. This patch extends such behaviour to
zero vlan tagged packets also.
The patch is dependant on the following kernel patches:
1) vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)
- net-next-2.6 git commit: ad1afb00393915a51c21b1ae8704562bf036855f
- Available 2.6.36 and later
2) vlan: Centralize handling of hardware acceleration.
- net-next-2.6 git commit: 3701e51382a026cba10c60b03efabe534fba4ca4
- Available 2.6.37 and later
Signed-off-by: Christian Benvenuti <benve@cisco.com>
Signed-off-by: Danny Guo <dannguo@cisco.com>
Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
Signed-off-by: David Wang <dwang2@cisco.com>
---
drivers/net/enic/enic_main.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 9600f43..e990988 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -1266,8 +1266,7 @@ static void enic_rq_indicate_buf(struct vnic_rq *rq,
skb->dev = netdev;
- if (enic->vlan_group && vlan_stripped &&
- (vlan_tci & CQ_ENET_RQ_DESC_VLAN_TCI_VLAN_MASK)) {
+ if (vlan_stripped) {
if (netdev->features & NETIF_F_GRO)
vlan_gro_receive(&enic->napi[q_number],
^ permalink raw reply related
* [net-next-2.6 PATCH 0/4] enic: updates to version 2.1.1.20
From: Vasanthy Kolluri @ 2011-06-09 20:36 UTC (permalink / raw)
To: netdev, davem
The following series implements enic driver updates:
1/4 - Pass 802.1p bits for packets tagged with vlan zero
2/4 - Change log message during driver load
3/4 - Get/Set interrupt resource index for transmit and receive queues
4/4 - Bug Fix: Fix hardware transmit queue indexing in enic_poll_controller
Signed-off-by: Christian Benvenuti <benve@cisco.com>
Signed-off-by: Danny Guo <dannguo@cisco.com>
Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
Signed-off-by: David Wang <dwang2@cisco.com>
^ permalink raw reply
* Re: [PATCH] ep93xx-eth: convert to phylib
From: Petr Štetiar @ 2011-06-09 20:30 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, Herbert Valerio Riedel, Mika Westerberg, davem, hsweeten,
ryan, Lennert Buytenhek, linux-arm-kernel
In-Reply-To: <201106052029.24742.f.fainelli@gmail.com>
Florian Fainelli <f.fainelli@gmail.com> [2011-06-05 20:29:24]:
> On Sunday 05 June 2011 19:57:36 Florian Fainelli wrote:
> > ep93xx-eth lacked support for monitoring link status changes, with this
> > patch, link changes are now watched and reported correctly.
> >
> > Signed-off-by: Florian Fainelli <florian@openwrt.org>
> > ---
>
> I just stumbled upon: http://www.mail-
> archive.com/netdev@vger.kernel.org/msg62549.html
> which does not seem to have been merged.
>
> I will respin my patch with Herbert's changes
Hi,
just FYI, I wanted to test recent Mika's DMA/ep93xx_eth fixes, so I've added
this patch also and it oopsed. If I revert this patch, it seems to work so
far. You can find the whole patchset I've been testing on the GitHub[1]. I've
tested it on ts-7250 and ts-7300, the oops is same. Here's the oops:
ep93xx-eth version 0.1 loading
ep93xx_eth_mii: probed
ep93xx_eth:ep93xx_mii_probe: no PHY found
ep93xx-eth ep93xx-eth: failed to probe MII bus
------------[ cut here ]------------
WARNING: at net/core/dev.c:5133 rollback_registered_many+0x90/0x2d4()
Modules linked in:
Backtrace:
[<c0027e78>] (dump_backtrace+0x0/0x10c) from [<c0263764>] (dump_stack+0x18/0x1c)
r6:0000140d r5:c01cd558 r4:00000000 r3:00000000
[<c026374c>] (dump_stack+0x0/0x1c) from [<c0037a48>] (warn_slowpath_common+0x50/0x68)
[<c00379f8>] (warn_slowpath_common+0x0/0x68) from [<c0037a84>] (warn_slowpath_null+0x24/0x2c)
r8:00100100 r7:00200200 r6:cf01bda0 r5:cf01bdf8 r4:cf0b6800
r3:00000009
[<c0037a60>] (warn_slowpath_null+0x0/0x2c) from [<c01cd558>] (rollback_registered_many+0x90/0x2d4)
[<c01cd4c8>] (rollback_registered_many+0x0/0x2d4) from [<c01cd834>] (rollback_registered+0x30/0x48)
r8:00000027 r7:cf0b6800 r6:cf0b6b40 r5:00000000 r4:cf0b6800
r3:cf0b6858
[<c01cd804>] (rollback_registered+0x0/0x48) from [<c01cd8a8>] (unregister_netdevice_queue+0x5c/0xa8)
[<c01cd84c>] (unregister_netdevice_queue+0x0/0xa8) from [<c01cd914>] (unregister_netdev+0x20/0x28)
r5:c030f638 r4:cf0b6800
[<c01cd8f4>] (unregister_netdev+0x0/0x28) from [<c01b03a0>] (ep93xx_eth_remove+0x34/0x90)
r4:cf0b6800 r3:cf039180
[<c01b036c>] (ep93xx_eth_remove+0x0/0x90) from [<c01b1348>] (ep93xx_eth_probe+0x218/0x43c)
r5:c030f630 r4:ffffffed
[<c01b1130>] (ep93xx_eth_probe+0x0/0x43c) from [<c018b7b8>] (platform_drv_probe+0x1c/0x20)
[<c018b79c>] (platform_drv_probe+0x0/0x20) from [<c018a5d0>] (driver_probe_device+0x8c/0x198)
[<c018a544>] (driver_probe_device+0x0/0x198) from [<c018a770>] (__driver_attach+0x94/0x98)
r8:c0017d40 r7:00000000 r6:c030f66c r5:c032080c r4:c030f638
r3:00000000
[<c018a6dc>] (__driver_attach+0x0/0x98) from [<c018974c>] (bus_for_each_dev+0x60/0x88)
r6:00000000 r5:c018a6dc r4:c032080c r3:c018a6dc
[<c01896ec>] (bus_for_each_dev+0x0/0x88) from [<c018a2a8>] (driver_attach+0x20/0x28)
r6:cf0ae860 r5:c031d4e0 r4:c032080c
[<c018a288>] (driver_attach+0x0/0x28) from [<c0189e94>] (bus_add_driver+0xa4/0x240)
[<c0189df0>] (bus_add_driver+0x0/0x240) from [<c018aae0>] (driver_register+0x80/0x144)
[<c018aa60>] (driver_register+0x0/0x144) from [<c018baf0>] (platform_driver_register+0x4c/0x60)
r8:c0017d40 r7:00000000 r6:cf01a000 r5:c0325960 r4:c001ee3c
r3:00000000
[<c018baa4>] (platform_driver_register+0x0/0x60) from [<c0017d5c>] (ep93xx_eth_init_module+0x1c/0x28)
[<c0017d40>] (ep93xx_eth_init_module+0x0/0x28) from [<c00244f0>] (do_one_initcall+0x3c/0x17c)
[<c00244b4>] (do_one_initcall+0x0/0x17c) from [<c0008a04>] (kernel_init+0x9c/0x140)
[<c0008968>] (kernel_init+0x0/0x140) from [<c003b158>] (do_exit+0x0/0x710)
r5:c0008968 r4:00000000
---[ end trace edc3043606fef430 ]---
network todo 'eth%d' but state 0
Backtrace:
[<c0027e78>] (dump_backtrace+0x0/0x10c) from [<c0263764>] (dump_stack+0x18/0x1c)
r6:cf0b6b40 r5:c0312560 r4:cf0b6800 r3:00000000
[<c026374c>] (dump_stack+0x0/0x1c) from [<c01d10e4>] (netdev_run_todo+0x2dc/0x33c)
[<c01d0e08>] (netdev_run_todo+0x0/0x33c) from [<c01dd824>] (rtnl_unlock+0x10/0x14)
[<c01dd814>] (rtnl_unlock+0x0/0x14) from [<c01cd918>] (unregister_netdev+0x24/0x28)
[<c01cd8f4>] (unregister_netdev+0x0/0x28) from [<c01b03a0>] (ep93xx_eth_remove+0x34/0x90)
r4:cf0b6800 r3:cf039180
[<c01b036c>] (ep93xx_eth_remove+0x0/0x90) from [<c01b1348>] (ep93xx_eth_probe+0x218/0x43c)
r5:c030f630 r4:ffffffed
[<c01b1130>] (ep93xx_eth_probe+0x0/0x43c) from [<c018b7b8>] (platform_drv_probe+0x1c/0x20)
[<c018b79c>] (platform_drv_probe+0x0/0x20) from [<c018a5d0>] (driver_probe_device+0x8c/0x198)
[<c018a544>] (driver_probe_device+0x0/0x198) from [<c018a770>] (__driver_attach+0x94/0x98)
r8:c0017d40 r7:00000000 r6:c030f66c r5:c032080c r4:c030f638
r3:00000000
[<c018a6dc>] (__driver_attach+0x0/0x98) from [<c018974c>] (bus_for_each_dev+0x60/0x88)
r6:00000000 r5:c018a6dc r4:c032080c r3:c018a6dc
[<c01896ec>] (bus_for_each_dev+0x0/0x88) from [<c018a2a8>] (driver_attach+0x20/0x28)
r6:cf0ae860 r5:c031d4e0 r4:c032080c
[<c018a288>] (driver_attach+0x0/0x28) from [<c0189e94>] (bus_add_driver+0xa4/0x240)
[<c0189df0>] (bus_add_driver+0x0/0x240) from [<c018aae0>] (driver_register+0x80/0x144)
[<c018aa60>] (driver_register+0x0/0x144) from [<c018baf0>] (platform_driver_register+0x4c/0x60)
r8:c0017d40 r7:00000000 r6:cf01a000 r5:c0325960 r4:c001ee3c
r3:00000000
[<c018baa4>] (platform_driver_register+0x0/0x60) from [<c0017d5c>] (ep93xx_eth_init_module+0x1c/0x28)
[<c0017d40>] (ep93xx_eth_init_module+0x0/0x28) from [<c00244f0>] (do_one_initcall+0x3c/0x17c)
[<c00244b4>] (do_one_initcall+0x0/0x17c) from [<c0008a04>] (kernel_init+0x9c/0x140)
[<c0008968>] (kernel_init+0x0/0x140) from [<c003b158>] (do_exit+0x0/0x710)
r5:c0008968 r4:00000000
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT
Modules linked in:
CPU: 0 Tainted: G W (3.0.0-rc2+ #35)
PC is at ep93xx_free_buffers+0x24/0xd4
LR is at ep93xx_eth_remove+0x5c/0x90
pc : [<c01b02bc>] lr : [<c01b03c8>] psr: 80000013
sp : cf01be20 ip : cf01be40 fp : cf01be3c
r10: 00000080 r9 : c0325bc8 r8 : 00000027
r7 : c030f638 r6 : cf0b6b40 r5 : cf0b6b54 r4 : 00000000
r3 : 00000000 r2 : 00000014 r1 : 00000800 r0 : cf0b6b40
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: c000717f Table: 00004000 DAC: 00000017
Process swapper (pid: 1, stack limit = 0xcf01a270)
Stack: (0xcf01be20 to 0xcf01c000)
be20: cf0b6800 cf0b6b40 cf0b6b40 cf0b6800 cf01be54 cf01be40 c01b03c8 c01b02a8
be40: ffffffed c030f630 cf01be94 cf01be58 c01b1348 c01b037c 00000000 c032080c
be60: c0017d40 c030f638 cf01be84 c030f638 c0340bd0 c030f638 c032080c c0017d40
be80: 00000000 00000000 cf01bea4 cf01be98 c018b7b8 c01b1140 cf01becc cf01bea8
bea0: c018a5d0 c018b7ac 00000000 c030f638 c032080c c030f66c 00000000 c0017d40
bec0: cf01beec cf01bed0 c018a770 c018a554 c018a6dc c032080c c018a6dc 00000000
bee0: cf01bf14 cf01bef0 c018974c c018a6ec cf02ebf8 cf0391b0 c01576c4 c032080c
bf00: c031d4e0 cf0ae860 cf01bf24 cf01bf18 c018a2a8 c01896fc cf01bf54 cf01bf28
bf20: c0189e94 c018a298 c02ce24c cf01bf38 c032080c c0325960 cf01a000 00000000
bf40: c0017d40 00000000 cf01bf7c cf01bf58 c018aae0cf01bfe0 c0008a04 c00244c4
bfe0: 00000000 c0008968 00000000 cf01bff8 c003b158 c0008978 e3a0105e e3a02030
Backtrace:
[<c01b0298>] (ep93xx_free_buffers+0x0/0xd4) from [<c01b03c8>] (ep93xx_eth_remove+0x5c/0x90)
r7:cf0b6800 r6:cf0b6b40 r5:cf0b6b40 r4:cf0b6800
[<c01b036c>] (ep93xx_eth_remove+0x0/0x90) from [<c01b1348>] (ep93xx_eth_probe+0x218/0x43c)
r5:c030f630 r4:ffffffed
[<c01b1130>] (ep93xx_eth_probe+0x0/0x43c) from [<c018b7b8>] (platform_drv_probe+0x1c/0x20)
[<c018b79c>] (platform_drv_probe+0x0/0x20) from [<c018a5d0>] (driver_probe_device+0x8c/0x198)
[<c018a544>] (driver_probe_device+0x0/0x198) from [<c018a770>] (__driver_attach+0x94/0x98)
r8:c0017d40 r7:00000000 r6:c030f66c r5:c032080c r4:c030f638
r3:00000000
[<c018a6dc>] (__driver_attach+0x0/0x98) from [<c018974c>] (bus_for_each_dev+0x60/0x88)
r6:00000000 r5:c018a6dc r4:c032080c r3:c018a6dc
[<c01896ec>] (bus_for_each_dev+0x0/0x88) from [<c018a2a8>] (driver_attach+0x20/0x28)
r6:cf0ae860 r5:c031d4e0 r4:c032080c
[<c018a288>] (driver_attach+0x0/0x28) from [<c0189e94>] (bus_add_driver+0xa4/0x240)
[<c0189df0>] (bus_add_driver+0x0/0x240) from [<c018aae0>] (driver_register+0x80/0x144)
[<c018aa60>] (driver_register+0x0/0x144) from [<c018baf0>] (platform_driver_register+0x4c/0x60)
r8:c0017d40 r7:00000000 r6:cf01a000 r5:c0325960 r4:c001ee3c
r3:00000000
[<c018baa4>] (platform_driver_register+0x0/0x60) from [<c0017d5c>] (ep93xx_eth_init_module+0x1c/0x28)
[<c0017d40>] (ep93xx_eth_init_module+0x0/0x28) from [<c00244f0>] (do_one_initcall+0x3c/0x17c)
[<c00244b4>] (do_one_initcall+0x0/0x17c) from [<c0008a04>] (kernel_init+0x9c/0x140)
[<c0008968>] (kernel_init+0x0/0x140) from [<c003b158>] (do_exit+0x0/0x710)
r5:c0008968 r4:00000000
Code: e2805014 e3a04000 e5963010 e3a01b02 (e7933184)
---[ end trace edc3043606fef431 ]---
Kernel panic - not syncing: Attempted to kill init!
Backtrace:
[<c0027e78>] (dump_backtrace+0x0/0x10c) from [<c0263764>] (dump_stack+0x18/0x1c)
r6:00000000 r5:c0312c40 r4:c0325cc0 r3:00000002
[<c026374c>] (dump_stack+0x0/0x1c) from [<c02637d0>] (panic+0x68/0x198)
[<c0263768>] (panic+0x0/0x198) from [<c003b7cc>] (do_exit+0x674/0x710)
r3:c0312c40 r2:c003b754 r1:cf01a000 r0:c02cf148
r7:cf019be0
[<c003b158>] (do_exit+0x0/0x710) from [<c00284e4>] (die+ cf0b6b40 00000800
bde0: 00000014 00000000 00000000 cf0b6b54 cf0b6b40 c030f638 00000027 c0325bc8
be00: 00000080 cf01be3c cf01be40 cf01be20 c01b03c8 c01b02bc 80000013 ffffffff
r8:00000027 r7:c030f638 r6:cf0b6b40 r5:cf01be0c r4:ffffffff
[<c01b0298>] (ep93xx_free_buffers+0x0/0xd4) from [<c01b03c8>] (ep93xx_eth_remove+0x5c/0x90)
r7:cf0b6800 r6:cf0b6b40 r5:cf0b6b40 r4:cf0b6800
[<c01b036c>] (ep93xx_eth_remove+0x0/0x90) from [<c01b1348>] (ep93xx_eth_probe+0x218/0x43c)
r5:c030f630 r4:ffffffed
[<c01b1130>] (ep93xx_eth_probe+0x0/0x43c) from [<c018b7b8>] (platform_drv_probe+0x1c/0x20)
[<c018b79c>] (platform_drv_probe+0x0/0x20) from [<c018a5d0>] (driver_probe_device+0x8c/0x198)
[<c018a544>] (driver_probe_device+0x0/0x198) from [<c018a770>] (__driver_attach+0x94/0x98)
r8:c0017d40 r7:00000000 r6:c030f66c r5:c032080c r4:c030f638
r3:00000000
[<c018a6dc>] (__driver_attach+0x0/0x98) from [<c018974c>] (bus_for_each_dev+0x60/0x88)
r6:00000000 r5:c018a6dc r4:c032080c r3:c018a6dc
[<c01896ec>] (bus_for_each_dev+0x0/0x88) from [<c018a2a8>] (driver_attach+0x20/0x28)
r6:cf0ae860 r5:c031d4e0 r4:c032080c
[<c018a288>] (driver_attach+0x0/0x28) from [<c0189e94>] (bus_add_driver+0xa4/0x240)
[<c0189df0>] (bus_add_driver+0x0/0x240) from [<c018aae0>] (driver_register+0x80/0x144)
[<c018aa60>] (driver_register+0x0/0x144) from [<c018baf0>] (platform_driver_register+0x4c/0x60)
r8:c0017d40 r7:00000000 r6:cf01a000 r5:c0325960 r4:c001ee3c
r3:00000000
[<c018baa4>] (platform_driver_register+0x0/0x60) from [<c0017d5c>] (ep93xx_eth_init_module+0x1c/0x28)
[<c0017d40>] (ep93xx_eth_init_module+0x0/0x28) from [<c00244f0>] (do_one_initcall+0x3c/0x17c)
[<c00244b4>] (do_one_initcall+0x0/0x17c) from [<c0008a04>] (kernel_init+0x9c/0x140)
[<c0008968>] (kernel_init+0x0/0x140) from [<c003b158>] (do_exit+0x0/0x710)
r5:c0008968 r4:00000000
1. https://github.com/ynezz/linux-2.6/commits/ts72xx-wip
-- ynezz
^ permalink raw reply
* RE: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth
From: H Hartley Sweeten @ 2011-06-09 20:27 UTC (permalink / raw)
To: Mika Westerberg, netdev@vger.kernel.org
Cc: ryan@bluewatersys.com, kernel@wantstofly.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <f20d8fe52f823e7e65423720c53f2935d3e08967.1307040443.git.mika.westerberg@iki.fi>
On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
>
> As the driver is now passing platform device to the DMA mapping functions,
> we should give it valid DMA masks.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Since you made this patch the first in the series the commit message is not
quite right. Other than that:
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth
From: Mika Westerberg @ 2011-06-09 20:23 UTC (permalink / raw)
To: H Hartley Sweeten
Cc: kernel@wantstofly.org, rmallon@gmail.com, netdev@vger.kernel.org,
florian@openwrt.org, ynezz@true.cz, David Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <ADE657CA350FB648AAC2C43247A983F001F3820B85E7@AUSP01VMBX24.collaborationhost.net>
On Thu, Jun 09, 2011 at 03:18:39PM -0500, H Hartley Sweeten wrote:
> On Thursday, June 09, 2011 12:51 PM, Mika Westerberg wrote:
> > On Mon, Jun 06, 2011 at 12:48:19PM -0500, H Hartley Sweeten wrote:
> >> If Lennert is no longer maintaining the this driver we really need someone to
> >> step up and handle it.
> >>
> >> I have no problem doing it but I really don't have a good grasp on the driver
> >> or the whole network subsystem.
> >>
> >> If Lennert is willing to hand it over, I have no problem being listed as a
> >> co-maintainer along with either yourself of Ryan. Between the two (or three)
> >> of us we should be able to handle it.
> >
> > Hartley,
> >
> > Can you take maintainership of this driver? Since you already maintain most of
> > the ep93xx core stuff I think that you are the right person for the job. If
> > you need any assistance I believe me and Ryan can help you out.
> >
> > We have now few patches queued:
> > - this series from me to fix the DMA API violations
> > - phylib patches from Florian Fainelli
> >
> > It would be great to get those in someday :-)
>
> Hmm.. Ok, fine ;-)
>
> I just submitted a patch to lkml changing the maintainership to myself.
>
> Patches will still need to be applied through someone's tree, probably
> David Miller's, since I don't have my own.
>
> I think your series and Florian's patches are still in my inbox. I'll try
> to look at them today and provide feedback.
Ok, thanks :-)
I was also going to test and review Florian's patches this week. I'll report
back when I'm done.
^ permalink raw reply
* Re: pull request: wireless-2.6 2011-06-09
From: David Miller @ 2011-06-09 20:20 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20110609191632.GA16198@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 9 Jun 2011 15:16:32 -0400
> There are two reverts, both in mac80211. One was found to cause a
> regression. The other revert was requested by the mac80211 maintainer
> (Johannes) on the basis of API abuse and a lack of faith that the
> implementation actual did anything useful. :-(
>
> This includes a fix for an IBSS-related race condition from Johannes,
> and a fix for an nl80211 integer overflow from Luca. Also included
> are a couple of rtlwifi fixes from Mike McCormack, one that fixes a
> packet dropping error, and another that avoids incorrectly modifying
> a resubmitted skb. But the big hero this round is Stanislaw, who
> not only identified a fix from Wey-Yi that need to go for 3.0 rather
> than 3.1, but he also fixed an rmmod crash in rt2x00, a locking issue
> in iwlgacy, a power setting bug in iwl4965, and an 802.11n general
> instability issue on iwlagn. As a result, I am researching popular
> beers in the Czech Republic... :-)
>
> Please let me know if there are problems!
Pulled, thanks!
^ permalink raw reply
* RE: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth
From: H Hartley Sweeten @ 2011-06-09 20:18 UTC (permalink / raw)
To: Mika Westerberg
Cc: kernel@wantstofly.org, rmallon@gmail.com, netdev@vger.kernel.org,
florian@openwrt.org, ynezz@true.cz, David Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20110609195052.GB2857@acer>
On Thursday, June 09, 2011 12:51 PM, Mika Westerberg wrote:
> On Mon, Jun 06, 2011 at 12:48:19PM -0500, H Hartley Sweeten wrote:
>> If Lennert is no longer maintaining the this driver we really need someone to
>> step up and handle it.
>>
>> I have no problem doing it but I really don't have a good grasp on the driver
>> or the whole network subsystem.
>>
>> If Lennert is willing to hand it over, I have no problem being listed as a
>> co-maintainer along with either yourself of Ryan. Between the two (or three)
>> of us we should be able to handle it.
>
> Hartley,
>
> Can you take maintainership of this driver? Since you already maintain most of
> the ep93xx core stuff I think that you are the right person for the job. If
> you need any assistance I believe me and Ryan can help you out.
>
> We have now few patches queued:
> - this series from me to fix the DMA API violations
> - phylib patches from Florian Fainelli
>
> It would be great to get those in someday :-)
Hmm.. Ok, fine ;-)
I just submitted a patch to lkml changing the maintainership to myself.
Patches will still need to be applied through someone's tree, probably
David Miller's, since I don't have my own.
I think your series and Florian's patches are still in my inbox. I'll try
to look at them today and provide feedback.
Regards,
Hartley
^ permalink raw reply
* Re: [PATCH 2/3] net: msm_ipc: Add user-space support for MSM_IPC Router
From: Arnd Bergmann @ 2011-06-09 20:15 UTC (permalink / raw)
To: David Miller; +Cc: kramasub, netdev, linux-arm-msm
In-Reply-To: <20110609.123553.784125057506332397.davem@davemloft.net>
On Thursday 09 June 2011 21:35:53 David Miller wrote:
> From: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
> Date: Thu, 09 Jun 2011 11:06:18 -0600
>
> > Please let me know if you need any other information.
>
> I don't agree with creating all of this non-trivial infrastructure
> for what seems to be an obscure protocol stack.
>
> You can do all of this in userspace, it seems.
I can see some good use cases for having a socket to do IPC between OS
images that have a shared memory interconnect. What I see as most
problematic is to have it defined in a way that is tightly connected
to specific hardware from one vendor. If the protocol was defined
in a way that is useful for communication between virtual machines
(e.g. on top of virtio) and tranparent PCI bridges, it would probably
be much more acceptable.
Arnd
^ permalink raw reply
* Re: [PATCHv3] net: Define enum for the bits used in features.
From: Michael S. Tsirkin @ 2011-06-09 20:12 UTC (permalink / raw)
To: David Miller; +Cc: maheshb, netdev, therbert, mirqus, shemminger
In-Reply-To: <20110609164645.GA10592@redhat.com>
On Thu, Jun 09, 2011 at 07:46:45PM +0300, Michael S. Tsirkin wrote:
> On Mon, Jun 06, 2011 at 11:35:15PM +0300, Michael S. Tsirkin wrote:
> > On Mon, Jun 06, 2011 at 12:20:59PM -0700, David Miller wrote:
> > > From: "Michael S. Tsirkin" <mst@redhat.com>
> > > Date: Mon, 6 Jun 2011 18:32:53 +0300
> > >
> > > > On Sun, Jun 05, 2011 at 10:15:37PM -0700, David Miller wrote:
> > > >> Since the GSO accessors deal with mutliple bits, you can create
> > > >> special GSO specific interfaces to manipulate them.
> > > >
> > > > Yes but it's not just GSO.
> > > > It's anything that includes more than 1 feature.
> > > > Examples:
> > > > NETIF_F_ALL_CSUM
> > > > NETIF_F_ALL_TX_OFFLOADS
> > > > NETIF_F_V6_CSUM
> > > > NETIF_F_SOFT_FEATURES
> > > >
> > > > etc
> > > >
> > > > Creating many accessors for each will need a lot
> > > > of code duplication ...
> > >
> > > Yet this is something you must resolve in order to change the feature
> > > bit implementation.
> > >
> > > Whether this issue is difficult or not to address, it has to be done
> > > either way.
> >
> > I think I found a truly elegant solution to this
> > problem which this margin is too narrow to contain ...
>
> OK, it looks like using variadic macros from C99 makes this
> possible, even though use of ungarded comma in macros
> below makes me cringe:
>
> /* Set all bits in the first 64 arguments, ignore the rest */
> #define NETIF_F_OR_64( \
> _000, _001 , _002 , _003 , _004 , _005 , _006 , _007, \
> _010, _011 , _012 , _013 , _014 , _015 , _016 , _017, \
> _020, _021 , _022 , _023 , _024 , _025 , _026 , _027, \
> _030, _031 , _032 , _033 , _034 , _035 , _036 , _037, \
> _040, _041 , _042 , _043 , _044 , _045 , _046 , _047, \
> _050, _051 , _052 , _053 , _054 , _055 , _056 , _057, \
> _060, _061 , _062 , _063 , _064 , _065 , _066 , _067, \
> _070, _071 , _072 , _073 , _074 , _075 , _076 , _077, \
> ... ) \
> ((_000) | (_001) | (_002) | (_003) | (_004) | (_005) | (_006) | (_007) | \
> (_010) | (_011) | (_012) | (_013) | (_014) | (_015) | (_016) | (_017) | \
> (_020) | (_021) | (_022) | (_023) | (_024) | (_025) | (_026) | (_027) | \
> (_030) | (_031) | (_032) | (_033) | (_034) | (_035) | (_036) | (_037) | \
> (_040) | (_041) | (_042) | (_043) | (_044) | (_045) | (_046) | (_047) | \
> (_050) | (_051) | (_052) | (_053) | (_054) | (_055) | (_056) | (_057) | \
> (_060) | (_061) | (_062) | (_063) | (_064) | (_065) | (_066) | (_067) | \
> (_070) | (_071) | (_072) | (_073) | (_074) | (_075) | (_076) | (_077) )
>
> /* Verify that argument #65 is zero */
> #define NETIF_F_BUG_ON_64( \
> _000, _001 , _002 , _003 , _004 , _005 , _006 , _007, \
> _010, _011 , _012 , _013 , _014 , _015 , _016 , _017, \
> _020, _021 , _022 , _023 , _024 , _025 , _026 , _027, \
> _030, _031 , _032 , _033 , _034 , _035 , _036 , _037, \
> _040, _041 , _042 , _043 , _044 , _045 , _046 , _047, \
> _050, _051 , _052 , _053 , _054 , _055 , _056 , _057, \
> _060, _061 , _062 , _063 , _064 , _065 , _066 , _067, \
> _070, _071 , _072 , _073 , _074 , _075 , _076 , _077, \
> _100, ... ) \
> BUG_ON((_100))
>
> /* Set multiple bits in f. At most 64 bits can be
> * set in this way.
> * Nested calls are padded with 0 arguments
> * to ensure there are at least 64 of them */
> #define NETIF_F_INIT(f, ...) do { \
> f |= NETIF_F_OR_64(__VA_ARGS__, \
> 0, 0, 0, 0, 0, 0, 0, 0,\
> 0, 0, 0, 0, 0, 0, 0, 0,\
> 0, 0, 0, 0, 0, 0, 0, 0,\
> 0, 0, 0, 0, 0, 0, 0, 0,\
> 0, 0, 0, 0, 0, 0, 0, 0,\
> 0, 0, 0, 0, 0, 0, 0, 0,\
> 0, 0, 0, 0, 0, 0, 0, 0,\
> 0, 0, 0, 0, 0, 0, 0, 0 \
> ); \
> NETIF_F_BUG_ON_64(__VA_ARGS__, \
> 0, 0, 0, 0, 0, 0, 0, 0,\
> 0, 0, 0, 0, 0, 0, 0, 0,\
> 0, 0, 0, 0, 0, 0, 0, 0,\
> 0, 0, 0, 0, 0, 0, 0, 0,\
> 0, 0, 0, 0, 0, 0, 0, 0,\
> 0, 0, 0, 0, 0, 0, 0, 0,\
> 0, 0, 0, 0, 0, 0, 0, 0,\
> 0, 0, 0, 0, 0, 0, 0, 0 \
> ); \
> } while (0)
One thing I realized is there's no reason for
NETIF_F_INIT to get the ellipsis ... as we don't want users
to pass arbitrary lists of features, just the
predefined sets. So this can be a simpler:
#define NETIF_F_INIT(f, bits) do { \
f |= NETIF_F_OR_64(bits, \
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0 \
);
> And now:
> #define NETIF_F_GSO_SOFTWARE NETIF_F_TSO , NETIF_F_TSO_ECN , \
> NETIF_F_TSO6 , NETIF_F_UFO
>
>
> which makes
>
> NETIF_F_INIT(z, NETIF_F_GSO_SOFTWARE);
>
> work as expected, and set all necessary bits,
> so all we need to do is replace
> z = NETIF_F_GSO_SOFTWARE;
> with call to macro above.
>
> At most 64 different bits can be passed in this way
> but NETIF_F_BUG_ON_64 above checks that.
> If we want more than 64 bits, we just update
> these macro definitions.
>
> It seems that behaviour above is guaranteed by the language spec,
> specifically the argument prescan rule.
> Any C99 experts want to comment on this?
OK, the confirmation was located in C99 standard,
chapter 6.10.3.1 Argument substitution.
> I have my doubts about whether the above is way too clever
> even if it works. What do others think?
>
>
> > --
> > MST
^ permalink raw reply
* Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth
From: Mika Westerberg @ 2011-06-09 19:50 UTC (permalink / raw)
To: H Hartley Sweeten
Cc: David Miller, netdev@vger.kernel.org, ynezz@true.cz, rmallon,
florian, linux-arm-kernel@lists.infradead.org,
kernel@wantstofly.org
In-Reply-To: <ADE657CA350FB648AAC2C43247A983F001F381FC56CE@AUSP01VMBX24.collaborationhost.net>
(corrected Ryan's email address, added Florian Fainelli)
On Mon, Jun 06, 2011 at 12:48:19PM -0500, H Hartley Sweeten wrote:
> On Monday, June 06, 2011 10:26 AM, Mika Westerberg wrote:
> > On Sun, Jun 05, 2011 at 02:08:01PM -0700, David Miller wrote:
> >> From: Mika Westerberg <mika.westerberg@iki.fi>
> >> Date: Sun, 5 Jun 2011 11:59:48 +0300
> >>
> >>> It looks like David Miller (CC'd) has been taking care of ep93xx_eth.c maybe
> >>> he knows this better.
> >>
> >> Someone needs to step up and take over as the real maintainer of this
> >> driver. The way the driver is currently being hacked on is
> >> unsustainable.
> >
> > Can't agree more.
> >
> > Hartley, Ryan: do you have any preferences? Are you guys already overwhelmed
> > with your current maintenance work, or could you consider taking this one as
> > well?
> >
> > If no one else steps up, I can volunteer but I have to admit that I don't know
> > much about that driver.
>
> I feel the same way.
>
> If Lennert is no longer maintaining the this driver we really need someone to
> step up and handle it.
>
> I have no problem doing it but I really don't have a good grasp on the driver
> or the whole network subsystem.
>
> If Lennert is willing to hand it over, I have no problem being listed as a
> co-maintainer along with either yourself of Ryan. Between the two (or three)
> of us we should be able to handle it.
Hartley,
Can you take maintainership of this driver? Since you already maintain most of
the ep93xx core stuff I think that you are the right person for the job. If
you need any assistance I believe me and Ryan can help you out.
We have now few patches queued:
- this series from me to fix the DMA API violations
- phylib patches from Florian Fainelli
It would be great to get those in someday :-)
^ permalink raw reply
* Re: [PATCH 2/3] net: msm_ipc: Add user-space support for MSM_IPC Router
From: David Miller @ 2011-06-09 19:35 UTC (permalink / raw)
To: kramasub; +Cc: netdev, linux-arm-msm
In-Reply-To: <4DF0FD8A.1000304@codeaurora.org>
From: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
Date: Thu, 09 Jun 2011 11:06:18 -0600
> Please let me know if you need any other information.
I don't agree with creating all of this non-trivial infrastructure
for what seems to be an obscure protocol stack.
You can do all of this in userspace, it seems.
^ permalink raw reply
* RE: Request for review on Hyper-V virtual network driver
From: Haiyang Zhang @ 2011-06-09 19:32 UTC (permalink / raw)
To: Greg KH
Cc: netdev@vger.kernel.org, Stephen Hemminger, KY Srinivasan,
Hank Janssen
In-Reply-To: <20110609192841.GA12036@kroah.com>
> You aren't going to get very far posting emails in HTML format, which is
> filtered out by the mailing list, and most sane email users...
>
> care to try again?
sure, I will correct it.
> Oh, and the best way to ask for a code review is to post the code in the
> message, in diff format, so that it can be read and reviewed and
> commented on inline, otherwise you are asking people to do a lot of
> extra work for you for no good reason.
will do.
Thanks,
- Haiyang
^ permalink raw reply
* Re: linux-next: build failure after merge of the net tree
From: Greg KH @ 2011-06-09 19:29 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, <netdev@vger.kernel.org>,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Alexey Dobriyan
In-Reply-To: <20110609153904.e602b317.sfr@canb.auug.org.au>
On Thu, Jun 09, 2011 at 03:39:04PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> On Wed, 8 Jun 2011 22:17:55 -0700 Greg K-H <greg@kroah.com> wrote:
> >
> > Sorry, this is something that Linus asked for and will be going to him
> > tomorrow with the rest of the staging-linus branch.
>
> Yeah, I remember the discussion, just not a conclusion. At least the
> x86_64 allmodconfig builds worked before I merged the net tree, so that is
> something.
>
> The powerpc allyesconfig build is going to be interesting :-(
>
> You might like to check the build results at
> http://kisskb.ellerman.id.au/kisskb/branch/9/ sometime tomorrow. Or
> point your janitors at it :-)
I don't see any failures in the staging tree in the powerpc allyesconfig
build, so all must be good :)
thanks,
greg k-h
^ permalink raw reply
* Re: Request for review on Hyper-V virtual network driver
From: Greg KH @ 2011-06-09 19:28 UTC (permalink / raw)
To: Haiyang Zhang
Cc: netdev@vger.kernel.org, Stephen Hemminger, KY Srinivasan,
Hank Janssen
In-Reply-To: <A1F3067C9B68744AA19F6802BAB8FFDC09603BC2@TK5EX14MBXC227.redmond.corp.microsoft.com>
On Thu, Jun 09, 2011 at 07:23:59PM +0000, Haiyang Zhang wrote:
> To network maintainers:
<snip>
You aren't going to get very far posting emails in HTML format, which is
filtered out by the mailing list, and most sane email users...
care to try again?
Oh, and the best way to ask for a code review is to post the code in the
message, in diff format, so that it can be read and reviewed and
commented on inline, otherwise you are asking people to do a lot of
extra work for you for no good reason.
greg k-h
^ permalink raw reply
* pull request: wireless-2.6 2011-06-09
From: John W. Linville @ 2011-06-09 19:16 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here are some more fixes intended for 3.0...
There are two reverts, both in mac80211. One was found to cause a
regression. The other revert was requested by the mac80211 maintainer
(Johannes) on the basis of API abuse and a lack of faith that the
implementation actual did anything useful. :-(
This includes a fix for an IBSS-related race condition from Johannes,
and a fix for an nl80211 integer overflow from Luca. Also included
are a couple of rtlwifi fixes from Mike McCormack, one that fixes a
packet dropping error, and another that avoids incorrectly modifying
a resubmitted skb. But the big hero this round is Stanislaw, who
not only identified a fix from Wey-Yi that need to go for 3.0 rather
than 3.1, but he also fixed an rmmod crash in rt2x00, a locking issue
in iwlgacy, a power setting bug in iwl4965, and an 802.11n general
instability issue on iwlagn. As a result, I am researching popular
beers in the Czech Republic... :-)
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 0c1ad04aecb975f2a2014e1bc5a2fa23923ecbd9:
netpoll: prevent netpoll setup on slave devices (2011-06-09 00:28:13 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git for-davem
Johannes Berg (1):
mac80211: fix IBSS teardown race
John W. Linville (3):
Revert "mac80211: Skip tailroom reservation for full HW-crypto devices"
Revert "mac80211: stop queues before rate control updation"
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6 into for-davem
Luciano Coelho (1):
nl80211: fix overflow in ssid_len
Mike McCormack (2):
rtlwifi: Fix logic in rx_interrupt
rtlwifi: Avoid modifying skbs that are resubmitted
Stanislaw Gruszka (4):
iwlagn: use cts-to-self protection on 5000 adapters series
rt2x00: fix rmmod crash
iwl4965: set tx power after rxon_assoc
iwlegacy: fix channel switch locking
Wey-Yi Guy (1):
iwlagn: send tx power command if defer cause by RXON not match
drivers/net/wireless/iwlegacy/iwl-4965.c | 12 ++++------
drivers/net/wireless/iwlegacy/iwl-core.c | 30 +++++++++++--------------
drivers/net/wireless/iwlegacy/iwl-core.h | 2 +-
drivers/net/wireless/iwlegacy/iwl-dev.h | 13 +----------
drivers/net/wireless/iwlegacy/iwl4965-base.c | 20 ++++++++--------
drivers/net/wireless/iwlwifi/iwl-5000.c | 1 -
drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c | 12 +--------
drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 13 +++++++++++
drivers/net/wireless/rt2x00/rt2x00config.c | 3 +-
drivers/net/wireless/rt2x00/rt2x00dev.c | 4 +++
drivers/net/wireless/rtlwifi/pci.c | 30 ++++++++++++-------------
net/mac80211/ibss.c | 6 +++-
net/mac80211/ieee80211_i.h | 3 --
net/mac80211/key.c | 21 +----------------
net/mac80211/mlme.c | 6 -----
net/mac80211/tx.c | 7 +++++-
net/wireless/nl80211.c | 9 +++----
17 files changed, 81 insertions(+), 111 deletions(-)
diff --git a/drivers/net/wireless/iwlegacy/iwl-4965.c b/drivers/net/wireless/iwlegacy/iwl-4965.c
index f9db25b..facc94e 100644
--- a/drivers/net/wireless/iwlegacy/iwl-4965.c
+++ b/drivers/net/wireless/iwlegacy/iwl-4965.c
@@ -1218,10 +1218,10 @@ static int iwl4965_commit_rxon(struct iwl_priv *priv, struct iwl_rxon_context *c
* receive commit_rxon request
* abort any previous channel switch if still in process
*/
- if (priv->switch_rxon.switch_in_progress &&
- (priv->switch_rxon.channel != ctx->staging.channel)) {
+ if (test_bit(STATUS_CHANNEL_SWITCH_PENDING, &priv->status) &&
+ (priv->switch_channel != ctx->staging.channel)) {
IWL_DEBUG_11H(priv, "abort channel switch on %d\n",
- le16_to_cpu(priv->switch_rxon.channel));
+ le16_to_cpu(priv->switch_channel));
iwl_legacy_chswitch_done(priv, false);
}
@@ -1237,7 +1237,7 @@ static int iwl4965_commit_rxon(struct iwl_priv *priv, struct iwl_rxon_context *c
memcpy(active_rxon, &ctx->staging, sizeof(*active_rxon));
iwl_legacy_print_rx_config_cmd(priv, ctx);
- return 0;
+ goto set_tx_power;
}
/* If we are currently associated and the new config requires
@@ -1317,6 +1317,7 @@ static int iwl4965_commit_rxon(struct iwl_priv *priv, struct iwl_rxon_context *c
iwl4965_init_sensitivity(priv);
+set_tx_power:
/* If we issue a new RXON command which required a tune then we must
* send a new TXPOWER command or we won't be able to Tx any frames */
ret = iwl_legacy_set_tx_power(priv, priv->tx_power_next, true);
@@ -1403,9 +1404,6 @@ static int iwl4965_hw_channel_switch(struct iwl_priv *priv,
return rc;
}
- priv->switch_rxon.channel = cmd.channel;
- priv->switch_rxon.switch_in_progress = true;
-
return iwl_legacy_send_cmd_pdu(priv,
REPLY_CHANNEL_SWITCH, sizeof(cmd), &cmd);
}
diff --git a/drivers/net/wireless/iwlegacy/iwl-core.c b/drivers/net/wireless/iwlegacy/iwl-core.c
index 42df832..3be76bd 100644
--- a/drivers/net/wireless/iwlegacy/iwl-core.c
+++ b/drivers/net/wireless/iwlegacy/iwl-core.c
@@ -859,12 +859,8 @@ void iwl_legacy_chswitch_done(struct iwl_priv *priv, bool is_success)
if (test_bit(STATUS_EXIT_PENDING, &priv->status))
return;
- if (priv->switch_rxon.switch_in_progress) {
+ if (test_and_clear_bit(STATUS_CHANNEL_SWITCH_PENDING, &priv->status))
ieee80211_chswitch_done(ctx->vif, is_success);
- mutex_lock(&priv->mutex);
- priv->switch_rxon.switch_in_progress = false;
- mutex_unlock(&priv->mutex);
- }
}
EXPORT_SYMBOL(iwl_legacy_chswitch_done);
@@ -876,19 +872,19 @@ void iwl_legacy_rx_csa(struct iwl_priv *priv, struct iwl_rx_mem_buffer *rxb)
struct iwl_rxon_context *ctx = &priv->contexts[IWL_RXON_CTX_BSS];
struct iwl_legacy_rxon_cmd *rxon = (void *)&ctx->active;
- if (priv->switch_rxon.switch_in_progress) {
- if (!le32_to_cpu(csa->status) &&
- (csa->channel == priv->switch_rxon.channel)) {
- rxon->channel = csa->channel;
- ctx->staging.channel = csa->channel;
- IWL_DEBUG_11H(priv, "CSA notif: channel %d\n",
- le16_to_cpu(csa->channel));
- iwl_legacy_chswitch_done(priv, true);
- } else {
- IWL_ERR(priv, "CSA notif (fail) : channel %d\n",
+ if (!test_bit(STATUS_CHANNEL_SWITCH_PENDING, &priv->status))
+ return;
+
+ if (!le32_to_cpu(csa->status) && csa->channel == priv->switch_channel) {
+ rxon->channel = csa->channel;
+ ctx->staging.channel = csa->channel;
+ IWL_DEBUG_11H(priv, "CSA notif: channel %d\n",
le16_to_cpu(csa->channel));
- iwl_legacy_chswitch_done(priv, false);
- }
+ iwl_legacy_chswitch_done(priv, true);
+ } else {
+ IWL_ERR(priv, "CSA notif (fail) : channel %d\n",
+ le16_to_cpu(csa->channel));
+ iwl_legacy_chswitch_done(priv, false);
}
}
EXPORT_SYMBOL(iwl_legacy_rx_csa);
diff --git a/drivers/net/wireless/iwlegacy/iwl-core.h b/drivers/net/wireless/iwlegacy/iwl-core.h
index bc66c60..c5fbda0 100644
--- a/drivers/net/wireless/iwlegacy/iwl-core.h
+++ b/drivers/net/wireless/iwlegacy/iwl-core.h
@@ -560,7 +560,7 @@ void iwl_legacy_free_geos(struct iwl_priv *priv);
#define STATUS_SCAN_HW 15
#define STATUS_POWER_PMI 16
#define STATUS_FW_ERROR 17
-
+#define STATUS_CHANNEL_SWITCH_PENDING 18
static inline int iwl_legacy_is_ready(struct iwl_priv *priv)
{
diff --git a/drivers/net/wireless/iwlegacy/iwl-dev.h b/drivers/net/wireless/iwlegacy/iwl-dev.h
index be0106c..ea30122 100644
--- a/drivers/net/wireless/iwlegacy/iwl-dev.h
+++ b/drivers/net/wireless/iwlegacy/iwl-dev.h
@@ -855,17 +855,6 @@ struct traffic_stats {
};
/*
- * iwl_switch_rxon: "channel switch" structure
- *
- * @ switch_in_progress: channel switch in progress
- * @ channel: new channel
- */
-struct iwl_switch_rxon {
- bool switch_in_progress;
- __le16 channel;
-};
-
-/*
* schedule the timer to wake up every UCODE_TRACE_PERIOD milliseconds
* to perform continuous uCode event logging operation if enabled
*/
@@ -1115,7 +1104,7 @@ struct iwl_priv {
struct iwl_rxon_context contexts[NUM_IWL_RXON_CTX];
- struct iwl_switch_rxon switch_rxon;
+ __le16 switch_channel;
/* 1st responses from initialize and runtime uCode images.
* _4965's initialize alive response contains some calibration data. */
diff --git a/drivers/net/wireless/iwlegacy/iwl4965-base.c b/drivers/net/wireless/iwlegacy/iwl4965-base.c
index af2ae22..7157ba5 100644
--- a/drivers/net/wireless/iwlegacy/iwl4965-base.c
+++ b/drivers/net/wireless/iwlegacy/iwl4965-base.c
@@ -2861,16 +2861,13 @@ void iwl4965_mac_channel_switch(struct ieee80211_hw *hw,
goto out;
if (test_bit(STATUS_EXIT_PENDING, &priv->status) ||
- test_bit(STATUS_SCANNING, &priv->status))
+ test_bit(STATUS_SCANNING, &priv->status) ||
+ test_bit(STATUS_CHANNEL_SWITCH_PENDING, &priv->status))
goto out;
if (!iwl_legacy_is_associated_ctx(ctx))
goto out;
- /* channel switch in progress */
- if (priv->switch_rxon.switch_in_progress == true)
- goto out;
-
if (priv->cfg->ops->lib->set_channel_switch) {
ch = channel->hw_value;
@@ -2919,15 +2916,18 @@ void iwl4965_mac_channel_switch(struct ieee80211_hw *hw,
* at this point, staging_rxon has the
* configuration for channel switch
*/
- if (priv->cfg->ops->lib->set_channel_switch(priv,
- ch_switch))
- priv->switch_rxon.switch_in_progress = false;
+ set_bit(STATUS_CHANNEL_SWITCH_PENDING, &priv->status);
+ priv->switch_channel = cpu_to_le16(ch);
+ if (priv->cfg->ops->lib->set_channel_switch(priv, ch_switch)) {
+ clear_bit(STATUS_CHANNEL_SWITCH_PENDING,
+ &priv->status);
+ priv->switch_channel = 0;
+ ieee80211_chswitch_done(ctx->vif, false);
+ }
}
}
out:
mutex_unlock(&priv->mutex);
- if (!priv->switch_rxon.switch_in_progress)
- ieee80211_chswitch_done(ctx->vif, false);
IWL_DEBUG_MAC80211(priv, "leave\n");
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c b/drivers/net/wireless/iwlwifi/iwl-5000.c
index 5b721c5..f99f9c1 100644
--- a/drivers/net/wireless/iwlwifi/iwl-5000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
@@ -423,7 +423,6 @@ static struct iwl_base_params iwl5000_base_params = {
};
static struct iwl_ht_params iwl5000_ht_params = {
.ht_greenfield_support = true,
- .use_rts_for_aggregation = true, /* use rts/cts protection */
};
#define IWL_DEVICE_5000 \
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c b/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
index b12c72d..23fa93d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
@@ -163,17 +163,9 @@ static void iwlagn_tx_cmd_protection(struct iwl_priv *priv,
__le16 fc, __le32 *tx_flags)
{
if (info->control.rates[0].flags & IEEE80211_TX_RC_USE_RTS_CTS ||
- info->control.rates[0].flags & IEEE80211_TX_RC_USE_CTS_PROTECT) {
+ info->control.rates[0].flags & IEEE80211_TX_RC_USE_CTS_PROTECT ||
+ info->flags & IEEE80211_TX_CTL_AMPDU)
*tx_flags |= TX_CMD_FLG_PROT_REQUIRE_MSK;
- return;
- }
-
- if (priv->cfg->ht_params &&
- priv->cfg->ht_params->use_rts_for_aggregation &&
- info->flags & IEEE80211_TX_CTL_AMPDU) {
- *tx_flags |= TX_CMD_FLG_PROT_REQUIRE_MSK;
- return;
- }
}
/* Calc max signal level (dBm) among 3 possible receivers */
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c b/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c
index 2532c7d..09f679d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c
@@ -325,6 +325,14 @@ int iwlagn_commit_rxon(struct iwl_priv *priv, struct iwl_rxon_context *ctx)
return 0;
}
+ /*
+ * force CTS-to-self frames protection if RTS-CTS is not preferred
+ * one aggregation protection method
+ */
+ if (!(priv->cfg->ht_params &&
+ priv->cfg->ht_params->use_rts_for_aggregation))
+ ctx->staging.flags |= RXON_FLG_SELF_CTS_EN;
+
if ((ctx->vif && ctx->vif->bss_conf.use_short_slot) ||
!(ctx->staging.flags & RXON_FLG_BAND_24G_MSK))
ctx->staging.flags |= RXON_FLG_SHORT_SLOT_MSK;
@@ -362,6 +370,11 @@ int iwlagn_commit_rxon(struct iwl_priv *priv, struct iwl_rxon_context *ctx)
}
memcpy(active, &ctx->staging, sizeof(*active));
+ /*
+ * We do not commit tx power settings while channel changing,
+ * do it now if after settings changed.
+ */
+ iwl_set_tx_power(priv, priv->tx_power_next, false);
return 0;
}
diff --git a/drivers/net/wireless/rt2x00/rt2x00config.c b/drivers/net/wireless/rt2x00/rt2x00config.c
index 555180d..b704e5b 100644
--- a/drivers/net/wireless/rt2x00/rt2x00config.c
+++ b/drivers/net/wireless/rt2x00/rt2x00config.c
@@ -250,7 +250,8 @@ void rt2x00lib_config(struct rt2x00_dev *rt2x00dev,
if (ieee80211_flags & IEEE80211_CONF_CHANGE_CHANNEL)
rt2x00link_reset_tuner(rt2x00dev, false);
- if (test_bit(REQUIRE_PS_AUTOWAKE, &rt2x00dev->cap_flags) &&
+ if (test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags) &&
+ test_bit(REQUIRE_PS_AUTOWAKE, &rt2x00dev->cap_flags) &&
(ieee80211_flags & IEEE80211_CONF_CHANGE_PS) &&
(conf->flags & IEEE80211_CONF_PS)) {
beacon_diff = (long)jiffies - (long)rt2x00dev->last_beacon;
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index c018d67..939821b 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -146,6 +146,9 @@ static void rt2x00lib_autowakeup(struct work_struct *work)
struct rt2x00_dev *rt2x00dev =
container_of(work, struct rt2x00_dev, autowakeup_work.work);
+ if (!test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags))
+ return;
+
if (rt2x00dev->ops->lib->set_device_state(rt2x00dev, STATE_AWAKE))
ERROR(rt2x00dev, "Device failed to wakeup.\n");
clear_bit(CONFIG_POWERSAVING, &rt2x00dev->flags);
@@ -1160,6 +1163,7 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
* Stop all work.
*/
cancel_work_sync(&rt2x00dev->intf_work);
+ cancel_delayed_work_sync(&rt2x00dev->autowakeup_work);
if (rt2x00_is_usb(rt2x00dev)) {
del_timer_sync(&rt2x00dev->txstatus_timer);
cancel_work_sync(&rt2x00dev->rxdone_work);
diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
index 89100e7..9f8ccae 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -669,6 +669,19 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
&rx_status,
(u8 *) pdesc, skb);
+ new_skb = dev_alloc_skb(rtlpci->rxbuffersize);
+ if (unlikely(!new_skb)) {
+ RT_TRACE(rtlpriv, (COMP_INTR | COMP_RECV),
+ DBG_DMESG,
+ ("can't alloc skb for rx\n"));
+ goto done;
+ }
+
+ pci_unmap_single(rtlpci->pdev,
+ *((dma_addr_t *) skb->cb),
+ rtlpci->rxbuffersize,
+ PCI_DMA_FROMDEVICE);
+
skb_put(skb, rtlpriv->cfg->ops->get_desc((u8 *) pdesc,
false,
HW_DESC_RXPKT_LEN));
@@ -685,22 +698,7 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
hdr = rtl_get_hdr(skb);
fc = rtl_get_fc(skb);
- /* try for new buffer - if allocation fails, drop
- * frame and reuse old buffer
- */
- new_skb = dev_alloc_skb(rtlpci->rxbuffersize);
- if (unlikely(!new_skb)) {
- RT_TRACE(rtlpriv, (COMP_INTR | COMP_RECV),
- DBG_DMESG,
- ("can't alloc skb for rx\n"));
- goto done;
- }
- pci_unmap_single(rtlpci->pdev,
- *((dma_addr_t *) skb->cb),
- rtlpci->rxbuffersize,
- PCI_DMA_FROMDEVICE);
-
- if (!stats.crc || !stats.hwerror) {
+ if (!stats.crc && !stats.hwerror) {
memcpy(IEEE80211_SKB_RXCB(skb), &rx_status,
sizeof(rx_status));
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 421eaa6..56c24ca 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -965,6 +965,10 @@ int ieee80211_ibss_leave(struct ieee80211_sub_if_data *sdata)
mutex_lock(&sdata->u.ibss.mtx);
+ sdata->u.ibss.state = IEEE80211_IBSS_MLME_SEARCH;
+ memset(sdata->u.ibss.bssid, 0, ETH_ALEN);
+ sdata->u.ibss.ssid_len = 0;
+
active_ibss = ieee80211_sta_active_ibss(sdata);
if (!active_ibss && !is_zero_ether_addr(ifibss->bssid)) {
@@ -999,8 +1003,6 @@ int ieee80211_ibss_leave(struct ieee80211_sub_if_data *sdata)
kfree_skb(skb);
skb_queue_purge(&sdata->skb_queue);
- memset(sdata->u.ibss.bssid, 0, ETH_ALEN);
- sdata->u.ibss.ssid_len = 0;
del_timer_sync(&sdata->u.ibss.timer);
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 2025af5..090b0ec 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -775,9 +775,6 @@ struct ieee80211_local {
int tx_headroom; /* required headroom for hardware/radiotap */
- /* count for keys needing tailroom space allocation */
- int crypto_tx_tailroom_needed_cnt;
-
/* Tasklet and skb queue to process calls from IRQ mode. All frames
* added to skb_queue will be processed, but frames in
* skb_queue_unreliable may be dropped if the total length of these
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index 31afd712..f825e2f 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -101,11 +101,6 @@ static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
if (!ret) {
key->flags |= KEY_FLAG_UPLOADED_TO_HARDWARE;
-
- if (!((key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_MMIC) ||
- (key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_IV)))
- key->local->crypto_tx_tailroom_needed_cnt--;
-
return 0;
}
@@ -161,10 +156,6 @@ static void ieee80211_key_disable_hw_accel(struct ieee80211_key *key)
key->conf.keyidx, sta ? sta->addr : bcast_addr, ret);
key->flags &= ~KEY_FLAG_UPLOADED_TO_HARDWARE;
-
- if (!((key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_MMIC) ||
- (key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_IV)))
- key->local->crypto_tx_tailroom_needed_cnt++;
}
void ieee80211_key_removed(struct ieee80211_key_conf *key_conf)
@@ -403,10 +394,8 @@ static void __ieee80211_key_destroy(struct ieee80211_key *key)
ieee80211_aes_key_free(key->u.ccmp.tfm);
if (key->conf.cipher == WLAN_CIPHER_SUITE_AES_CMAC)
ieee80211_aes_cmac_key_free(key->u.aes_cmac.tfm);
- if (key->local) {
+ if (key->local)
ieee80211_debugfs_key_remove(key);
- key->local->crypto_tx_tailroom_needed_cnt--;
- }
kfree(key);
}
@@ -468,8 +457,6 @@ int ieee80211_key_link(struct ieee80211_key *key,
ieee80211_debugfs_key_add(key);
- key->local->crypto_tx_tailroom_needed_cnt++;
-
ret = ieee80211_key_enable_hw_accel(key);
mutex_unlock(&sdata->local->key_mtx);
@@ -511,12 +498,8 @@ void ieee80211_enable_keys(struct ieee80211_sub_if_data *sdata)
mutex_lock(&sdata->local->key_mtx);
- sdata->local->crypto_tx_tailroom_needed_cnt = 0;
-
- list_for_each_entry(key, &sdata->key_list, list) {
- sdata->local->crypto_tx_tailroom_needed_cnt++;
+ list_for_each_entry(key, &sdata->key_list, list)
ieee80211_key_enable_hw_accel(key);
- }
mutex_unlock(&sdata->local->key_mtx);
}
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 456cccf..d595265 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -232,9 +232,6 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata,
WARN_ON(!ieee80211_set_channel_type(local, sdata, channel_type));
}
- ieee80211_stop_queues_by_reason(&sdata->local->hw,
- IEEE80211_QUEUE_STOP_REASON_CSA);
-
/* channel_type change automatically detected */
ieee80211_hw_config(local, 0);
@@ -248,9 +245,6 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata,
rcu_read_unlock();
}
- ieee80211_wake_queues_by_reason(&sdata->local->hw,
- IEEE80211_QUEUE_STOP_REASON_CSA);
-
ht_opmode = le16_to_cpu(hti->operation_mode);
/* if bss configuration changed store the new one */
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 64e0f75..3104c84 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1480,7 +1480,12 @@ static int ieee80211_skb_resize(struct ieee80211_local *local,
{
int tail_need = 0;
- if (may_encrypt && local->crypto_tx_tailroom_needed_cnt) {
+ /*
+ * This could be optimised, devices that do full hardware
+ * crypto (including TKIP MMIC) need no tailroom... But we
+ * have no drivers for such devices currently.
+ */
+ if (may_encrypt) {
tail_need = IEEE80211_ENCRYPT_TAILROOM;
tail_need -= skb_tailroom(skb);
tail_need = max_t(int, tail_need, 0);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 88a565f..98fa8eb 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3406,11 +3406,11 @@ static int nl80211_trigger_scan(struct sk_buff *skb, struct genl_info *info)
i = 0;
if (info->attrs[NL80211_ATTR_SCAN_SSIDS]) {
nla_for_each_nested(attr, info->attrs[NL80211_ATTR_SCAN_SSIDS], tmp) {
- request->ssids[i].ssid_len = nla_len(attr);
- if (request->ssids[i].ssid_len > IEEE80211_MAX_SSID_LEN) {
+ if (nla_len(attr) > IEEE80211_MAX_SSID_LEN) {
err = -EINVAL;
goto out_free;
}
+ request->ssids[i].ssid_len = nla_len(attr);
memcpy(request->ssids[i].ssid, nla_data(attr), nla_len(attr));
i++;
}
@@ -3572,12 +3572,11 @@ static int nl80211_start_sched_scan(struct sk_buff *skb,
if (info->attrs[NL80211_ATTR_SCAN_SSIDS]) {
nla_for_each_nested(attr, info->attrs[NL80211_ATTR_SCAN_SSIDS],
tmp) {
- request->ssids[i].ssid_len = nla_len(attr);
- if (request->ssids[i].ssid_len >
- IEEE80211_MAX_SSID_LEN) {
+ if (nla_len(attr) > IEEE80211_MAX_SSID_LEN) {
err = -EINVAL;
goto out_free;
}
+ request->ssids[i].ssid_len = nla_len(attr);
memcpy(request->ssids[i].ssid, nla_data(attr),
nla_len(attr));
i++;
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [PATCH 6/9] enic: update to support 64 bit stats
From: roprabhu @ 2011-06-09 17:43 UTC (permalink / raw)
To: Stephen Hemminger, David S. Miller, Christian Benvenuti,
Vasanthy Kolluri, David Wang
Cc: netdev
In-Reply-To: <20110609005417.630728228@vyatta.com>
On 6/8/11 5:54 PM, "Stephen Hemminger" <shemminger@vyatta.com> wrote:
> The device driver already uses 64 bit statistics, it just
> doesn't use the 64 bit interface.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> --- a/drivers/net/enic/enic_main.c 2011-06-07 16:58:31.317079332 -0700
> +++ b/drivers/net/enic/enic_main.c 2011-06-07 17:29:09.670195233 -0700
> @@ -801,10 +801,10 @@ static netdev_tx_t enic_hard_start_xmit(
> }
>
> /* dev_base_lock rwlock held, nominally process context */
> -static struct net_device_stats *enic_get_stats(struct net_device *netdev)
> +static struct rtnl_link_stats64 *enic_get_stats(struct net_device *netdev,
> + struct rtnl_link_stats64 *net_stats)
> {
> struct enic *enic = netdev_priv(netdev);
> - struct net_device_stats *net_stats = &netdev->stats;
> struct vnic_stats *stats;
>
> enic_dev_stats_dump(enic, &stats);
> @@ -2117,7 +2117,7 @@ static const struct net_device_ops enic_
> .ndo_open = enic_open,
> .ndo_stop = enic_stop,
> .ndo_start_xmit = enic_hard_start_xmit,
> - .ndo_get_stats = enic_get_stats,
> + .ndo_get_stats64 = enic_get_stats,
> .ndo_validate_addr = eth_validate_addr,
> .ndo_set_rx_mode = enic_set_rx_mode,
> .ndo_set_multicast_list = enic_set_rx_mode,
> @@ -2139,7 +2139,7 @@ static const struct net_device_ops enic_
> .ndo_open = enic_open,
> .ndo_stop = enic_stop,
> .ndo_start_xmit = enic_hard_start_xmit,
> - .ndo_get_stats = enic_get_stats,
> + .ndo_get_stats64 = enic_get_stats,
> .ndo_validate_addr = eth_validate_addr,
> .ndo_set_mac_address = enic_set_mac_address,
> .ndo_set_rx_mode = enic_set_rx_mode,
>
ACK..
Thanks Stephen.
^ permalink raw reply
* Re: [PATCH 2/3] net: msm_ipc: Add user-space support for MSM_IPC Router
From: Karthikeyan Ramasubramanian @ 2011-06-09 17:06 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-arm-msm
In-Reply-To: <20110609.001149.2112721409565728649.davem@davemloft.net>
On 6/9/2011 1:11 AM, David Miller wrote:
>
> There is no reason to create a whole new socket address family, use
> genetlink instead.
> --
> 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
The prospect of using NETLINK sockets was investigated and it seems to
be supporting the communication between user-space and kernel-space
processes.
One of the requirements/goals for this MSM_IPC Router is to enable the
communication between the processes running on different processors &
OSes, and the addressing mechanism of NETLINK sockets is insufficient to
address the processes running in different processors and OSes.
We also have the requirements of built-in name service, remote process's
status detection, location transparency etc. That is the reason for this
home-grown solution with a requirement for new socket address family.
Please let me know if you need any other information.
Thanks and Regards,
Karthik.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCHv3] net: Define enum for the bits used in features.
From: Michael S. Tsirkin @ 2011-06-09 16:46 UTC (permalink / raw)
To: David Miller; +Cc: maheshb, netdev, therbert, mirqus, shemminger
In-Reply-To: <20110606203515.GA2802@redhat.com>
On Mon, Jun 06, 2011 at 11:35:15PM +0300, Michael S. Tsirkin wrote:
> On Mon, Jun 06, 2011 at 12:20:59PM -0700, David Miller wrote:
> > From: "Michael S. Tsirkin" <mst@redhat.com>
> > Date: Mon, 6 Jun 2011 18:32:53 +0300
> >
> > > On Sun, Jun 05, 2011 at 10:15:37PM -0700, David Miller wrote:
> > >> Since the GSO accessors deal with mutliple bits, you can create
> > >> special GSO specific interfaces to manipulate them.
> > >
> > > Yes but it's not just GSO.
> > > It's anything that includes more than 1 feature.
> > > Examples:
> > > NETIF_F_ALL_CSUM
> > > NETIF_F_ALL_TX_OFFLOADS
> > > NETIF_F_V6_CSUM
> > > NETIF_F_SOFT_FEATURES
> > >
> > > etc
> > >
> > > Creating many accessors for each will need a lot
> > > of code duplication ...
> >
> > Yet this is something you must resolve in order to change the feature
> > bit implementation.
> >
> > Whether this issue is difficult or not to address, it has to be done
> > either way.
>
> I think I found a truly elegant solution to this
> problem which this margin is too narrow to contain ...
OK, it looks like using variadic macros from C99 makes this
possible, even though use of ungarded comma in macros
below makes me cringe:
/* Set all bits in the first 64 arguments, ignore the rest */
#define NETIF_F_OR_64( \
_000, _001 , _002 , _003 , _004 , _005 , _006 , _007, \
_010, _011 , _012 , _013 , _014 , _015 , _016 , _017, \
_020, _021 , _022 , _023 , _024 , _025 , _026 , _027, \
_030, _031 , _032 , _033 , _034 , _035 , _036 , _037, \
_040, _041 , _042 , _043 , _044 , _045 , _046 , _047, \
_050, _051 , _052 , _053 , _054 , _055 , _056 , _057, \
_060, _061 , _062 , _063 , _064 , _065 , _066 , _067, \
_070, _071 , _072 , _073 , _074 , _075 , _076 , _077, \
... ) \
((_000) | (_001) | (_002) | (_003) | (_004) | (_005) | (_006) | (_007) | \
(_010) | (_011) | (_012) | (_013) | (_014) | (_015) | (_016) | (_017) | \
(_020) | (_021) | (_022) | (_023) | (_024) | (_025) | (_026) | (_027) | \
(_030) | (_031) | (_032) | (_033) | (_034) | (_035) | (_036) | (_037) | \
(_040) | (_041) | (_042) | (_043) | (_044) | (_045) | (_046) | (_047) | \
(_050) | (_051) | (_052) | (_053) | (_054) | (_055) | (_056) | (_057) | \
(_060) | (_061) | (_062) | (_063) | (_064) | (_065) | (_066) | (_067) | \
(_070) | (_071) | (_072) | (_073) | (_074) | (_075) | (_076) | (_077) )
/* Verify that argument #65 is zero */
#define NETIF_F_BUG_ON_64( \
_000, _001 , _002 , _003 , _004 , _005 , _006 , _007, \
_010, _011 , _012 , _013 , _014 , _015 , _016 , _017, \
_020, _021 , _022 , _023 , _024 , _025 , _026 , _027, \
_030, _031 , _032 , _033 , _034 , _035 , _036 , _037, \
_040, _041 , _042 , _043 , _044 , _045 , _046 , _047, \
_050, _051 , _052 , _053 , _054 , _055 , _056 , _057, \
_060, _061 , _062 , _063 , _064 , _065 , _066 , _067, \
_070, _071 , _072 , _073 , _074 , _075 , _076 , _077, \
_100, ... ) \
BUG_ON((_100))
/* Set multiple bits in f. At most 64 bits can be
* set in this way.
* Nested calls are padded with 0 arguments
* to ensure there are at least 64 of them */
#define NETIF_F_INIT(f, ...) do { \
f |= NETIF_F_OR_64(__VA_ARGS__, \
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0 \
); \
NETIF_F_BUG_ON_64(__VA_ARGS__, \
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0 \
); \
} while (0)
And now:
#define NETIF_F_GSO_SOFTWARE NETIF_F_TSO , NETIF_F_TSO_ECN , \
NETIF_F_TSO6 , NETIF_F_UFO
which makes
NETIF_F_INIT(z, NETIF_F_GSO_SOFTWARE);
work as expected, and set all necessary bits,
so all we need to do is replace
z = NETIF_F_GSO_SOFTWARE;
with call to macro above.
At most 64 different bits can be passed in this way
but NETIF_F_BUG_ON_64 above checks that.
If we want more than 64 bits, we just update
these macro definitions.
It seems that behaviour above is guaranteed by the language spec,
specifically the argument prescan rule.
Any C99 experts want to comment on this?
I have my doubts about whether the above is way too clever
even if it works. What do others think?
> --
> MST
^ 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