* [PATCH] net: ibm_newemac: Don't start autonegotiation when disabled in BMCR (genmii)
From: Stefan Roese @ 2011-07-19 10:50 UTC (permalink / raw)
To: linuxppc-dev, netdev
As noticed on a custom 440GX board using the Micrel KSZ8041 PHY in
fiber mode, a strapped fixed PHY configuration will currently restart
the autonegotiation. This patch checks the BMCR_ANENABLE bit and
skips this autonegotiation if its disabled.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/net/ibm_newemac/phy.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_newemac/phy.c b/drivers/net/ibm_newemac/phy.c
index ac9d964..90afc58 100644
--- a/drivers/net/ibm_newemac/phy.c
+++ b/drivers/net/ibm_newemac/phy.c
@@ -116,6 +116,11 @@ static int genmii_setup_aneg(struct mii_phy *phy, u32 advertise)
ctl = phy_read(phy, MII_BMCR);
if (ctl < 0)
return ctl;
+
+ /* Don't start auto negotiation when its disabled in BMCR */
+ if (!(ctl & BMCR_ANENABLE))
+ return 0;
+
ctl &= ~(BMCR_FULLDPLX | BMCR_SPEED100 | BMCR_SPEED1000 | BMCR_ANENABLE);
/* First clear the PHY */
--
1.7.6
^ permalink raw reply related
* [PATCH RFC] vhost: fix zcopy reference counting
From: Michael S. Tsirkin @ 2011-07-19 10:33 UTC (permalink / raw)
To: mashirle; +Cc: kvm, virtualization, netdev, linux-kernel
Fix get/put refcount imbalance with zero copy,
which caused qemu to hang forever on guest driver unload.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
Dave, I've put this on my tree so no need for you to bother.
drivers/vhost/vhost.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 46822c0..c16d225 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1578,7 +1578,6 @@ struct vhost_ubuf_ref *vhost_ubuf_alloc(struct vhost_virtqueue *vq,
if (!ubufs)
return ERR_PTR(-ENOMEM);
kref_init(&ubufs->kref);
- kref_get(&ubufs->kref);
init_waitqueue_head(&ubufs->wait);
ubufs->vq = vq;
return ubufs;
--
1.7.5.53.gc233e
^ permalink raw reply related
* Re: [PATCH next] netfilter: nfqueue: batch verdict support
From: Patrick McHardy @ 2011-07-19 9:45 UTC (permalink / raw)
To: Eric Dumazet
Cc: Florian Westphal, netfilter-devel, Pablo Neira Ayuso, netdev,
Eric Leblond
In-Reply-To: <1309688655.2523.16.camel@edumazet-laptop>
On 03.07.2011 12:24, Eric Dumazet wrote:
> The real question hidden here is : "Should packet ids be monotonic" in
> current implementation and all future ones ?
>
> Before we accept this patch, we should make sure packets id are
> monotonic, and I am afraid its not the case right now.
>
> I suggest following patch then.
>
> [PATCH] netfilter: nfqueue: assert monotonic packet ids
>
> Packet identifier is currently setup in nfqnl_build_packet_message(),
> using one atomic_inc_return().
>
> Problem is that since several cpus might concurrently call
> nfqnl_enqueue_packet() for the same queue, we can deliver packets to
> consumer in non monotonic way (packet N+1 being delivered after packet
> N)
>
> This patch moves the packet id setup from nfqnl_build_packet_message()
> to nfqnl_enqueue_packet() to guarantee correct delivery order.
>
> This also removes one atomic operation.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Florian Westphal <fw@strlen.de>
> CC: Pablo Neira Ayuso <pablo@netfilter.org>
> CC: Eric Leblond <eric@regit.org>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH v2] net: filter: BPF 'JIT' compiler for PPC64
From: Benjamin Herrenschmidt @ 2011-07-19 9:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Matt Evans, netdev, linuxppc-dev
In-Reply-To: <1311066368.2375.13.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Tue, 2011-07-19 at 11:06 +0200, Eric Dumazet wrote:
> Please Matt add to your next version this check. I dont think I have
> to
> submit a one line patch later...
>
> On x86_64, cpu_number field is already 32bit, we have some time before
> it becomes 64bit ;)
>
> We probably should add some extra check to make sure segment doesnt
> change (%gs on x86_64, r13 on ppc64) on a future linux version.
r13 isn't really a "segment" per-se, it can change if you aren't preempt
disabled, it's the PACA pointer, which is basically a low level per-cpu
data structure, so it will change if you migrate around (but if you are
in softirq context like most of the network stack, then it won't
change).
As for the CPU number being 16-bit, this is really due to how our
spinlocks work, using that as a lock token within the same 32-bit word
as the lock flag etc... We can easily fix that later if needed but I
don't see any emergency for us.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] net: filter: BPF 'JIT' compiler for PPC64
From: Eric Dumazet @ 2011-07-19 9:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Matt Evans, netdev, linuxppc-dev
In-Reply-To: <1311062135.25044.409.camel@pasglop>
Le mardi 19 juillet 2011 à 17:55 +1000, Benjamin Herrenschmidt a écrit :
> On Tue, 2011-07-19 at 08:51 +0200, Eric Dumazet wrote:
>
> > > + case BPF_S_ANC_CPU:
> > > +#ifdef CONFIG_SMP
> > > + /*
> > > + * PACA ptr is r13:
> > > + * raw_smp_processor_id() = local_paca->paca_index
> > > + */
> >
> > This could break if one day linux supports more than 65536 cpus :)
> >
> > > + PPC_LHZ_OFFS(r_A, 13,
> > > + offsetof(struct paca_struct, paca_index));
> > > +#else
> > > + PPC_LI(r_A, 0);
> > > +#endif
> > > + break;
>
> As would our implementation of raw_smp_processor_id() and our
> spinlocks :-) I don't think we need to fix that -now- but you are
> welcome to add something like a
> BUILD_BUG_ON(sizeof(local_paca->paca_index) != 2); as a reminder :-)
Please Matt add to your next version this check. I dont think I have to
submit a one line patch later...
On x86_64, cpu_number field is already 32bit, we have some time before
it becomes 64bit ;)
We probably should add some extra check to make sure segment doesnt
change (%gs on x86_64, r13 on ppc64) on a future linux version.
^ permalink raw reply
* [PATCH 3/3] stmmac: remove warning when compile as built-in
From: Giuseppe CAVALLARO @ 2011-07-19 8:38 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
In-Reply-To: <1311064684-20246-1-git-send-email-peppe.cavallaro@st.com>
The patch removes the following serie of warnings
when the driver is compiled as built-in:
drivers/net/stmmac/stmmac_main.c: In function stmmac_cmdline_opt:
drivers/net/stmmac/stmmac_main.c:1855:12: warning: ignoring return
value of kstrtoul, declared with attribute warn_unused_result
[snip]
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/stmmac/stmmac_main.c | 65 ++++++++++++++++++++++++-------------
1 files changed, 42 insertions(+), 23 deletions(-)
diff --git a/drivers/net/stmmac/stmmac_main.c b/drivers/net/stmmac/stmmac_main.c
index a11a339..2856d66 100644
--- a/drivers/net/stmmac/stmmac_main.c
+++ b/drivers/net/stmmac/stmmac_main.c
@@ -1851,33 +1851,52 @@ static int __init stmmac_cmdline_opt(char *str)
if (!str || !*str)
return -EINVAL;
while ((opt = strsep(&str, ",")) != NULL) {
- if (!strncmp(opt, "debug:", 6))
- strict_strtoul(opt + 6, 0, (unsigned long *)&debug);
- else if (!strncmp(opt, "phyaddr:", 8))
- strict_strtoul(opt + 8, 0, (unsigned long *)&phyaddr);
- else if (!strncmp(opt, "dma_txsize:", 11))
- strict_strtoul(opt + 11, 0,
- (unsigned long *)&dma_txsize);
- else if (!strncmp(opt, "dma_rxsize:", 11))
- strict_strtoul(opt + 11, 0,
- (unsigned long *)&dma_rxsize);
- else if (!strncmp(opt, "buf_sz:", 7))
- strict_strtoul(opt + 7, 0, (unsigned long *)&buf_sz);
- else if (!strncmp(opt, "tc:", 3))
- strict_strtoul(opt + 3, 0, (unsigned long *)&tc);
- else if (!strncmp(opt, "watchdog:", 9))
- strict_strtoul(opt + 9, 0, (unsigned long *)&watchdog);
- else if (!strncmp(opt, "flow_ctrl:", 10))
- strict_strtoul(opt + 10, 0,
- (unsigned long *)&flow_ctrl);
- else if (!strncmp(opt, "pause:", 6))
- strict_strtoul(opt + 6, 0, (unsigned long *)&pause);
+ if (!strncmp(opt, "debug:", 6)) {
+ if (strict_strtoul(opt + 6, 0, (unsigned long *)&debug))
+ goto err;
+ } else if (!strncmp(opt, "phyaddr:", 8)) {
+ if (strict_strtoul(opt + 8, 0,
+ (unsigned long *)&phyaddr))
+ goto err;
+ } else if (!strncmp(opt, "dma_txsize:", 11)) {
+ if (strict_strtoul(opt + 11, 0,
+ (unsigned long *)&dma_txsize))
+ goto err;
+ } else if (!strncmp(opt, "dma_rxsize:", 11)) {
+ if (strict_strtoul(opt + 11, 0,
+ (unsigned long *)&dma_rxsize))
+ goto err;
+ } else if (!strncmp(opt, "buf_sz:", 7)) {
+ if (strict_strtoul(opt + 7, 0,
+ (unsigned long *)&buf_sz))
+ goto err;
+ } else if (!strncmp(opt, "tc:", 3)) {
+ if (strict_strtoul(opt + 3, 0, (unsigned long *)&tc))
+ goto err;
+ } else if (!strncmp(opt, "watchdog:", 9)) {
+ if (strict_strtoul(opt + 9, 0,
+ (unsigned long *)&watchdog))
+ goto err;
+ } else if (!strncmp(opt, "flow_ctrl:", 10)) {
+ if (strict_strtoul(opt + 10, 0,
+ (unsigned long *)&flow_ctrl))
+ goto err;
+ } else if (!strncmp(opt, "pause:", 6)) {
+ if (strict_strtoul(opt + 6, 0, (unsigned long *)&pause))
+ goto err;
#ifdef CONFIG_STMMAC_TIMER
- else if (!strncmp(opt, "tmrate:", 7))
- strict_strtoul(opt + 7, 0, (unsigned long *)&tmrate);
+ } else if (!strncmp(opt, "tmrate:", 7)) {
+ if (strict_strtoul(opt + 7, 0,
+ (unsigned long *)&tmrate))
+ goto err;
#endif
+ }
}
return 0;
+
+err:
+ pr_err("%s: ERROR broken module parameter conversion", __func__);
+ return -EINVAL;
}
__setup("stmmaceth=", stmmac_cmdline_opt);
--
1.7.4.4
^ permalink raw reply related
* [PATCH 2/3] stmmac: update the version
From: Giuseppe CAVALLARO @ 2011-07-19 8:38 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
In-Reply-To: <1311064684-20246-1-git-send-email-peppe.cavallaro@st.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/stmmac/stmmac.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/stmmac/stmmac.h b/drivers/net/stmmac/stmmac.h
index c2b6b8e..0b17429 100644
--- a/drivers/net/stmmac/stmmac.h
+++ b/drivers/net/stmmac/stmmac.h
@@ -20,7 +20,7 @@
Author: Giuseppe Cavallaro <peppe.cavallaro@st.com>
*******************************************************************************/
-#define DRV_MODULE_VERSION "Nov_2010"
+#define DRV_MODULE_VERSION "July_2011"
#include <linux/stmmac.h>
#include "common.h"
--
1.7.4.4
^ permalink raw reply related
* [PATCH 1/3] stmmac: unify MAC and PHY configuration parameters
From: Giuseppe CAVALLARO @ 2011-07-19 8:38 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro, Stuart Menefy
Prior to this change, most PHY configuration parameters were passed
into the STMMAC device as a separate PHY device. As well as being
unusual, this made it difficult to make changes to the MAC/PHY
relationship.
This patch moves all the PHY parameters into the MAC configuration
structure, mainly as a separate structure. This allows us to completly
ignore the MDIO bus attached to a stmmac if desired, and not create
the PHY bus. It also allows the stmmac driver to use a different PHY
from the one it is connected to, for example a fixed PHY or bit banging
PHY.
Also derive the stmmac/PHY connection type (MII/RMII etc) from the
mode can be passed into <platf>_configure_ethernet.
STLinux kernel at git://git.stlinux.com/stm/linux-sh4-2.6.32.y.git
provides several examples how to use this new infrastructure (that
actually is easier to maintain and clearer).
Signed-off-by: Stuart Menefy <stuart.menefy@st.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/stmmac/stmmac.h | 6 +--
drivers/net/stmmac/stmmac_main.c | 95 +++-----------------------------------
drivers/net/stmmac/stmmac_mdio.c | 83 +++++++++++++++++++++++----------
include/linux/stmmac.h | 24 +++++-----
4 files changed, 77 insertions(+), 131 deletions(-)
diff --git a/drivers/net/stmmac/stmmac.h b/drivers/net/stmmac/stmmac.h
index 2b076b3..c2b6b8e 100644
--- a/drivers/net/stmmac/stmmac.h
+++ b/drivers/net/stmmac/stmmac.h
@@ -56,14 +56,9 @@ struct stmmac_priv {
struct stmmac_extra_stats xstats;
struct napi_struct napi;
- phy_interface_t phy_interface;
- int phy_addr;
- int phy_mask;
- int (*phy_reset) (void *priv);
int rx_coe;
int no_csum_insertion;
- int phy_irq;
struct phy_device *phydev;
int oldlink;
int speed;
@@ -71,6 +66,7 @@ struct stmmac_priv {
unsigned int flow_ctrl;
unsigned int pause;
struct mii_bus *mii;
+ int mii_irq[PHY_MAX_ADDR];
u32 msg_enable;
spinlock_t lock;
diff --git a/drivers/net/stmmac/stmmac_main.c b/drivers/net/stmmac/stmmac_main.c
index 0e0134e..a11a339 100644
--- a/drivers/net/stmmac/stmmac_main.c
+++ b/drivers/net/stmmac/stmmac_main.c
@@ -49,7 +49,6 @@
#include "stmmac.h"
#define STMMAC_RESOURCE_NAME "stmmaceth"
-#define PHY_RESOURCE_NAME "stmmacphy"
#undef STMMAC_DEBUG
/*#define STMMAC_DEBUG*/
@@ -305,18 +304,13 @@ static int stmmac_init_phy(struct net_device *dev)
priv->speed = 0;
priv->oldduplex = -1;
- if (priv->phy_addr == -1) {
- /* We don't have a PHY, so do nothing */
- return 0;
- }
-
snprintf(bus_id, MII_BUS_ID_SIZE, "%x", priv->plat->bus_id);
snprintf(phy_id, MII_BUS_ID_SIZE + 3, PHY_ID_FMT, bus_id,
- priv->phy_addr);
+ priv->plat->phy_addr);
pr_debug("stmmac_init_phy: trying to attach to %s\n", phy_id);
phydev = phy_connect(dev, phy_id, &stmmac_adjust_link, 0,
- priv->phy_interface);
+ priv->plat->interface);
if (IS_ERR(phydev)) {
pr_err("%s: Could not attach to PHY\n", dev->name);
@@ -335,7 +329,7 @@ static int stmmac_init_phy(struct net_device *dev)
return -ENODEV;
}
pr_debug("stmmac_init_phy: %s: attached to PHY (UID 0x%x)"
- " Link = %d\n", dev->name, phydev->phy_id, phydev->link);
+ " Link = %d\n", dev->name, phydev->phy_id, phydev->link);
priv->phydev = phydev;
@@ -1543,71 +1537,6 @@ static int stmmac_mac_device_setup(struct net_device *dev)
return 0;
}
-static int stmmacphy_dvr_probe(struct platform_device *pdev)
-{
- struct plat_stmmacphy_data *plat_dat = pdev->dev.platform_data;
-
- pr_debug("stmmacphy_dvr_probe: added phy for bus %d\n",
- plat_dat->bus_id);
-
- return 0;
-}
-
-static int stmmacphy_dvr_remove(struct platform_device *pdev)
-{
- return 0;
-}
-
-static struct platform_driver stmmacphy_driver = {
- .driver = {
- .name = PHY_RESOURCE_NAME,
- },
- .probe = stmmacphy_dvr_probe,
- .remove = stmmacphy_dvr_remove,
-};
-
-/**
- * stmmac_associate_phy
- * @dev: pointer to device structure
- * @data: points to the private structure.
- * Description: Scans through all the PHYs we have registered and checks if
- * any are associated with our MAC. If so, then just fill in
- * the blanks in our local context structure
- */
-static int stmmac_associate_phy(struct device *dev, void *data)
-{
- struct stmmac_priv *priv = (struct stmmac_priv *)data;
- struct plat_stmmacphy_data *plat_dat = dev->platform_data;
-
- DBG(probe, DEBUG, "%s: checking phy for bus %d\n", __func__,
- plat_dat->bus_id);
-
- /* Check that this phy is for the MAC being initialised */
- if (priv->plat->bus_id != plat_dat->bus_id)
- return 0;
-
- /* OK, this PHY is connected to the MAC.
- Go ahead and get the parameters */
- DBG(probe, DEBUG, "%s: OK. Found PHY config\n", __func__);
- priv->phy_irq =
- platform_get_irq_byname(to_platform_device(dev), "phyirq");
- DBG(probe, DEBUG, "%s: PHY irq on bus %d is %d\n", __func__,
- plat_dat->bus_id, priv->phy_irq);
-
- /* Override with kernel parameters if supplied XXX CRS XXX
- * this needs to have multiple instances */
- if ((phyaddr >= 0) && (phyaddr <= 31))
- plat_dat->phy_addr = phyaddr;
-
- priv->phy_addr = plat_dat->phy_addr;
- priv->phy_mask = plat_dat->phy_mask;
- priv->phy_interface = plat_dat->interface;
- priv->phy_reset = plat_dat->phy_reset;
-
- DBG(probe, DEBUG, "%s: exiting\n", __func__);
- return 1; /* forces exit of driver_for_each_device() */
-}
-
/**
* stmmac_dvr_probe
* @pdev: platform device pointer
@@ -1698,14 +1627,10 @@ static int stmmac_dvr_probe(struct platform_device *pdev)
if (ret < 0)
goto out_plat_exit;
- /* associate a PHY - it is provided by another platform bus */
- if (!driver_for_each_device
- (&(stmmacphy_driver.driver), NULL, (void *)priv,
- stmmac_associate_phy)) {
- pr_err("No PHY device is associated with this MAC!\n");
- ret = -ENODEV;
- goto out_unregister;
- }
+ /* Override with kernel parameters if supplied XXX CRS XXX
+ * this needs to have multiple instances */
+ if ((phyaddr >= 0) && (phyaddr <= 31))
+ priv->plat->phy_addr = phyaddr;
pr_info("\t%s - (dev. name: %s - id: %d, IRQ #%d\n"
"\tIO base addr: 0x%p)\n", ndev->name, pdev->name,
@@ -1905,11 +1830,6 @@ static int __init stmmac_init_module(void)
{
int ret;
- if (platform_driver_register(&stmmacphy_driver)) {
- pr_err("No PHY devices registered!\n");
- return -ENODEV;
- }
-
ret = platform_driver_register(&stmmac_driver);
return ret;
}
@@ -1920,7 +1840,6 @@ static int __init stmmac_init_module(void)
*/
static void __exit stmmac_cleanup_module(void)
{
- platform_driver_unregister(&stmmacphy_driver);
platform_driver_unregister(&stmmac_driver);
}
diff --git a/drivers/net/stmmac/stmmac_mdio.c b/drivers/net/stmmac/stmmac_mdio.c
index 234b406..b1c3ecf 100644
--- a/drivers/net/stmmac/stmmac_mdio.c
+++ b/drivers/net/stmmac/stmmac_mdio.c
@@ -112,9 +112,9 @@ static int stmmac_mdio_reset(struct mii_bus *bus)
struct stmmac_priv *priv = netdev_priv(ndev);
unsigned int mii_address = priv->hw->mii.addr;
- if (priv->phy_reset) {
+ if (priv->plat->mdio_bus_data->phy_reset) {
pr_debug("stmmac_mdio_reset: calling phy_reset\n");
- priv->phy_reset(priv->plat->bsp_priv);
+ priv->plat->mdio_bus_data->phy_reset(priv->plat->bsp_priv);
}
/* This is a workaround for problems with the STE101P PHY.
@@ -137,30 +137,29 @@ int stmmac_mdio_register(struct net_device *ndev)
struct mii_bus *new_bus;
int *irqlist;
struct stmmac_priv *priv = netdev_priv(ndev);
+ struct stmmac_mdio_bus_data *mdio_bus_data = priv->plat->mdio_bus_data;
int addr, found;
+ if (!mdio_bus_data)
+ return 0;
+
new_bus = mdiobus_alloc();
if (new_bus == NULL)
return -ENOMEM;
- irqlist = kzalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL);
- if (irqlist == NULL) {
- err = -ENOMEM;
- goto irqlist_alloc_fail;
- }
-
- /* Assign IRQ to phy at address phy_addr */
- if (priv->phy_addr != -1)
- irqlist[priv->phy_addr] = priv->phy_irq;
+ if (mdio_bus_data->irqs)
+ irqlist = mdio_bus_data->irqs;
+ else
+ irqlist = priv->mii_irq;
new_bus->name = "STMMAC MII Bus";
new_bus->read = &stmmac_mdio_read;
new_bus->write = &stmmac_mdio_write;
new_bus->reset = &stmmac_mdio_reset;
- snprintf(new_bus->id, MII_BUS_ID_SIZE, "%x", priv->plat->bus_id);
+ snprintf(new_bus->id, MII_BUS_ID_SIZE, "%x", mdio_bus_data->bus_id);
new_bus->priv = ndev;
new_bus->irq = irqlist;
- new_bus->phy_mask = priv->phy_mask;
+ new_bus->phy_mask = mdio_bus_data->phy_mask;
new_bus->parent = priv->device;
err = mdiobus_register(new_bus);
if (err != 0) {
@@ -171,18 +170,50 @@ int stmmac_mdio_register(struct net_device *ndev)
priv->mii = new_bus;
found = 0;
- for (addr = 0; addr < 32; addr++) {
+ for (addr = 0; addr < PHY_MAX_ADDR; addr++) {
struct phy_device *phydev = new_bus->phy_map[addr];
if (phydev) {
- if (priv->phy_addr == -1) {
- priv->phy_addr = addr;
- phydev->irq = priv->phy_irq;
- irqlist[addr] = priv->phy_irq;
+ int act = 0;
+ char irq_num[4];
+ char *irq_str;
+
+ /*
+ * If an IRQ was provided to be assigned after
+ * the bus probe, do it here.
+ */
+ if ((mdio_bus_data->irqs == NULL) &&
+ (mdio_bus_data->probed_phy_irq > 0)) {
+ irqlist[addr] = mdio_bus_data->probed_phy_irq;
+ phydev->irq = mdio_bus_data->probed_phy_irq;
}
- pr_info("%s: PHY ID %08x at %d IRQ %d (%s)%s\n",
- ndev->name, phydev->phy_id, addr,
- phydev->irq, dev_name(&phydev->dev),
- (addr == priv->phy_addr) ? " active" : "");
+
+ /*
+ * If we're going to bind the MAC to this PHY bus,
+ * and no PHY number was provided to the MAC,
+ * use the one probed here.
+ */
+ if ((priv->plat->bus_id == mdio_bus_data->bus_id) &&
+ (priv->plat->phy_addr == -1))
+ priv->plat->phy_addr = addr;
+
+ act = (priv->plat->bus_id == mdio_bus_data->bus_id) &&
+ (priv->plat->phy_addr == addr);
+ switch (phydev->irq) {
+ case PHY_POLL:
+ irq_str = "POLL";
+ break;
+ case PHY_IGNORE_INTERRUPT:
+ irq_str = "IGNORE";
+ break;
+ default:
+ sprintf(irq_num, "%d", phydev->irq);
+ irq_str = irq_num;
+ break;
+ }
+ pr_info("%s: PHY ID %08x at %d IRQ %s (%s)%s\n",
+ ndev->name, phydev->phy_id, addr,
+ irq_str, dev_name(&phydev->dev),
+ act ? " active" : "");
found = 1;
}
}
@@ -191,10 +222,9 @@ int stmmac_mdio_register(struct net_device *ndev)
pr_warning("%s: No PHY found\n", ndev->name);
return 0;
+
bus_register_fail:
- kfree(irqlist);
-irqlist_alloc_fail:
- kfree(new_bus);
+ mdiobus_free(new_bus);
return err;
}
@@ -209,7 +239,8 @@ int stmmac_mdio_unregister(struct net_device *ndev)
mdiobus_unregister(priv->mii);
priv->mii->priv = NULL;
- kfree(priv->mii);
+ mdiobus_free(priv->mii);
+ priv->mii = NULL;
return 0;
}
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 05d7756..57e583a 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -28,11 +28,21 @@
#include <linux/platform_device.h>
-/* platform data for platform device structure's platform_data field */
+/* Platfrom data for platform device structure's platform_data field */
+
+struct stmmac_mdio_bus_data {
+ int bus_id;
+ int (*phy_reset)(void *priv);
+ unsigned int phy_mask;
+ int *irqs; /* List of IRQs, one per PHY */
+ int probed_phy_irq; /* If irqs is NULL, use this for probed PHY */
+};
-/* Private data for the STM on-board ethernet driver */
struct plat_stmmacenet_data {
int bus_id;
+ int phy_addr;
+ int interface;
+ struct stmmac_mdio_bus_data *mdio_bus_data;
int pbl;
int clk_csr;
int has_gmac;
@@ -48,14 +58,4 @@ struct plat_stmmacenet_data {
void *custom_cfg;
void *bsp_priv;
};
-
-struct plat_stmmacphy_data {
- int bus_id;
- int phy_addr;
- unsigned int phy_mask;
- int interface;
- int (*phy_reset)(void *priv);
- void *priv;
-};
#endif
-
--
1.7.4.4
^ permalink raw reply related
* Re: [patch net-next-2.6] vlan: introduce ndo_vlan_[enable/disable]
From: Michał Mirosław @ 2011-07-19 8:27 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, shemminger, eric.dumazet, greearb
In-Reply-To: <CAHXqBFKZ2Y+SgFLFaBD6rpHoVX30PMp1ECwxhie3AAUqjMZ6UQ@mail.gmail.com>
W dniu 19 lipca 2011 10:24 użytkownik Michał Mirosław
<mirqus@gmail.com> napisał:
> W dniu 19 lipca 2011 10:13 użytkownik Jiri Pirko <jpirko@redhat.com> napisał:
>> Tue, Jul 19, 2011 at 09:24:29AM CEST, mirqus@gmail.com wrote:
>>>W dniu 18 lipca 2011 09:13 użytkownik Jiri Pirko <jpirko@redhat.com> napisał:
>>>> static u32 atl1c_fix_features(struct net_device *netdev, u32 features)
>>>> {
>>>> + u32 changed = netdev->features ^ features;
>>>> +
>>>> + /*
>>>> + * Since there is no support for separate rx/tx vlan accel
>>>> + * enable/disable make sure these are always set in pair.
>>>> + */
>>>> + if ((changed & NETIF_F_HW_VLAN_TX && features & NETIF_F_HW_VLAN_TX) ||
>>>> + (changed & NETIF_F_HW_VLAN_RX && features & NETIF_F_HW_VLAN_RX))
>>>> + features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
>>>> + else
>>>> + features &= ~(NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX);
>>>> +
>>>
>>>You ignored my hint about combined TX/RX offload. Is that on purpose?
>> Sorry but I'm probably missing what you mean.
>
> You could replace above code with:
>
> if (!(features & NETIF_F_HW_VLAN_RX))
> features &= ~NETIF_F_HW_VLAN_TX;
Or you could invert the test and effect:
if (features & NETIF_F_HW_VLAN_TX)
features |= NETIF_F_HW_VLAN_RX;
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [patch net-next-2.6] vlan: introduce ndo_vlan_[enable/disable]
From: Michał Mirosław @ 2011-07-19 8:24 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, shemminger, eric.dumazet, greearb
In-Reply-To: <20110719081332.GA2219@minipsycho>
W dniu 19 lipca 2011 10:13 użytkownik Jiri Pirko <jpirko@redhat.com> napisał:
> Tue, Jul 19, 2011 at 09:24:29AM CEST, mirqus@gmail.com wrote:
>>W dniu 18 lipca 2011 09:13 użytkownik Jiri Pirko <jpirko@redhat.com> napisał:
>>> static u32 atl1c_fix_features(struct net_device *netdev, u32 features)
>>> {
>>> + u32 changed = netdev->features ^ features;
>>> +
>>> + /*
>>> + * Since there is no support for separate rx/tx vlan accel
>>> + * enable/disable make sure these are always set in pair.
>>> + */
>>> + if ((changed & NETIF_F_HW_VLAN_TX && features & NETIF_F_HW_VLAN_TX) ||
>>> + (changed & NETIF_F_HW_VLAN_RX && features & NETIF_F_HW_VLAN_RX))
>>> + features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
>>> + else
>>> + features &= ~(NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX);
>>> +
>>
>>You ignored my hint about combined TX/RX offload. Is that on purpose?
> Sorry but I'm probably missing what you mean.
You could replace above code with:
if (!(features & NETIF_F_HW_VLAN_RX))
features &= ~NETIF_F_HW_VLAN_TX;
>>Your code will toggle VLAN acceleration on every
>>netdev_update_features call when user requests one offload on and one
>>off.
>
> Well for hw which cannot no/off rx/tx accel separately I thought that if
> user wants one accel on, the accel should be enabled. According to
> following table (bits set when calling driver's fix_features):
>
> NETIF_F_HW_VLAN_TX NETIF_F_HW_VLAN_RX -> enable
> NETIF_F_HW_VLAN_TX !NETIF_F_HW_VLAN_RX -> enable
> !NETIF_F_HW_VLAN_TX NETIF_F_HW_VLAN_RX -> enable
> !NETIF_F_HW_VLAN_TX !NETIF_F_HW_VLAN_RX -> disable
>
> This looks logical to me...
If user requests eg. +TX -RX, you will have ndo_fix_features called
with +TX -RX, possibly multiple times. This generates this sequence:
current features: -TX,-RX
-> changed: TX -> return +TX,+RX
-> set_features +TX,+TX
current_features: +TX,+RX
-> changed: RX -> return -TX,-RX
-> set_features -TX,-RX
...
(And you cannot control when fix_features will be called.)
If you don't agree with the hint above (about forcing TX off when RX
is off, leaving the rest alone), then its better to remove TX from
hw_features and copy it's state from RX in ndo_fix_features. Like
this:
[init]
netdev->hw_features |= NETIF_F_HW_VLAN_RX;
[fix_features]
if (features & NETIF_F_HW_VLAN_RX)
features |= NETIF_F_HW_VLAN_TX;
else
features &= ~NETIF_F_HW_VLAN_TX;
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [patch net-next-2.6] vlan: introduce ndo_vlan_[enable/disable]
From: Jiri Pirko @ 2011-07-19 8:13 UTC (permalink / raw)
To: Michał Mirosław
Cc: netdev, davem, shemminger, eric.dumazet, greearb
In-Reply-To: <CAHXqBFKgZUuLFoe+U+2nT3NVBCaPfY13BsrK=Hxqsw7oiOZe3A@mail.gmail.com>
Tue, Jul 19, 2011 at 09:24:29AM CEST, mirqus@gmail.com wrote:
>W dniu 18 lipca 2011 09:13 użytkownik Jiri Pirko <jpirko@redhat.com> napisał:
>> Sun, Jul 17, 2011 at 11:06:57PM CEST, mirqus@gmail.com wrote:
>>>W dniu 17 lipca 2011 21:44 użytkownik Jiri Pirko <jpirko@redhat.com> napisał:
>>>> Sun, Jul 17, 2011 at 10:36:04AM CEST, mirqus@gmail.com wrote:
>>>>>W dniu 17 lipca 2011 09:30 użytkownik Jiri Pirko <jpirko@redhat.com> napisał:
>>>>>> Sat, Jul 16, 2011 at 04:14:36PM CEST, mirqus@gmail.com wrote:
>>>>>>>2011/7/16 Jiri Pirko <jpirko@redhat.com>:
>>>>>>>> Some devices are not able to enable/disable rx/tw vlan accel separately.
>>>>>>>> they depend on ndo_vlan_rx_register to know if to enable of disable
>>>>>>>> hw accel. And since ndo_vlan_rx_register is going to die soon,
>>>>>>>> this must be resolved.
>>>>>>>>
>>>>>>>> One solution might be to enable accel on device start every time, even
>>>>>>>> if there are no vlan up on. But this would change behaviour and might
>>>>>>>> lead to possible regression (on older devices).
>>>>>>>[...]
>>>>>>>
>>>>>>>Please describe the possible regression. As I see it, there won't be
>>>>>>>any user visible change of behaviour - network code takes care of
>>>>>>>reinserting VLAN tag when necessary. If you think that disabling tag
>>>>>>>stripping is beneficial for cases where no VLANs are configured, it's
>>>>>>>better to do that in netdev_fix_features() for devices which advertise
>>>>>>>NETIF_F_HW_VLAN_RX in hw_features.
>>>>>>
>>>>>> Well I just wanted to preserve current behaviour which is that in many
>>>>>> drivers vlan accel is enabled only if some vid is registered upon the
>>>>>> device and it's disabled again when no vid is registered. I can see
>>>>>> no way to do this with current code after removing ndo_vlan_rx_register.
>>>>>>
>>>>>> I expect unexpected
>>>>>
>>>>>:-D
>>>>>
>>>>>> ... problems on old cards when vlan accel would be
>>>>>> enabled all the time, but maybe I'm wrong...
>>>>>
>>>>>Device has no way of knowing how the system uses VLAN tags, stripped
>>>>>or not. Any problems would be driver problems and since you're making
>>>>>it all use generic code, bugs will hit all drivers simultaneously or
>>>>>(preferably) won't happen at all.
>>>>>
>>>>>> One idea is for device which do not support sepatate rx/tx vlan accel
>>>>>> enabling/disabling they can probably use ndo_fix_features force to
>>>>>> enable/disable rx/tx pair together. That would resolve the situation as
>>>>>> well giving user possibility to turn off vlan accel in case of any issues.
>>>>>
>>>>>That is exactly the idea behind ndo_fix_features.
>>>
>>>> In netdev_fix_features add check if either one of NETIF_F_HW_VLAN_TX or
>>>> NETIF_F_HW_VLAN_RX is set and in that case set the other one. Of course
>>>> this would be done only for devices what do not support separate rx/tx
>>>> vlan on/off. But how to distinguish? NETIF_F_HW_VLAN_BOTH feature flag?
>>>
>>>Not in netdev_fix_features(). This case you describe should be handled
>>>in driver-specific
>>
>> Well since the code would be the same in many drivers I was thinking
>> about putting it in general code...
>>
>> Anyway, would you please look at following example patch and tell me if
>> it looks good to you?
>
>[...]
>> static u32 atl1c_fix_features(struct net_device *netdev, u32 features)
>> {
>> + u32 changed = netdev->features ^ features;
>> +
>> + /*
>> + * Since there is no support for separate rx/tx vlan accel
>> + * enable/disable make sure these are always set in pair.
>> + */
>> + if ((changed & NETIF_F_HW_VLAN_TX && features & NETIF_F_HW_VLAN_TX) ||
>> + (changed & NETIF_F_HW_VLAN_RX && features & NETIF_F_HW_VLAN_RX))
>> + features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
>> + else
>> + features &= ~(NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX);
>> +
>
>You ignored my hint about combined TX/RX offload. Is that on purpose?
Sorry but I'm probably missing what you mean.
>Your code will toggle VLAN acceleration on every
>netdev_update_features call when user requests one offload on and one
>off.
Well for hw which cannot no/off rx/tx accel separately I thought that if
user wants one accel on, the accel should be enabled. According to
following table (bits set when calling driver's fix_features):
NETIF_F_HW_VLAN_TX NETIF_F_HW_VLAN_RX -> enable
NETIF_F_HW_VLAN_TX !NETIF_F_HW_VLAN_RX -> enable
!NETIF_F_HW_VLAN_TX NETIF_F_HW_VLAN_RX -> enable
!NETIF_F_HW_VLAN_TX !NETIF_F_HW_VLAN_RX -> disable
This looks logical to me...
>
>BTW, the register flag name (MAC_CTRL_RMV_VLAN) suggests that it
>controls only tag stripping. Was it tested or documented that this
>also links with tag insertion?
comment says "/* enable VLAN tag insert/strip */" therefore it looks
like this register controls both.
>
>[...]
>> +static int atl1c_set_features(struct net_device *netdev, u32 features)
>> +{
>> + u32 changed = netdev->features ^ features;
>> +
>> + /*
>> + * Test for NETIF_F_HW_VLAN_TX as it's paired with NETIF_F_HW_VLAN_RX
>> + * by atl1c_fix_features.
>> + */
>> + if (changed & NETIF_F_HW_VLAN_TX)
>> + atl1c_vlan_mode(netdev, features);
>> +
>
>Test for RX is better, as it will match the name of control bit
>(MAC_CTRL_RMV_VLAN).
Yeah, why not, I think this does not matter.
>
>Best Regards,
>Michał Mirosław
^ permalink raw reply
* [PATCH] slcan: remove unused 'leased', 'line' and 'pid' fields from the 'slcan' structure
From: Matvejchikov Ilya @ 2011-07-19 7:58 UTC (permalink / raw)
To: netdev
Signed-off-by: Matvejchikov Ilya <matvejchikov@gmail.com>
---
drivers/net/can/slcan.c | 10 +---------
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/drivers/net/can/slcan.c b/drivers/net/can/slcan.c
index 1b49df6..805ee29 100644
--- a/drivers/net/can/slcan.c
+++ b/drivers/net/can/slcan.c
@@ -95,10 +95,6 @@ struct slcan {
unsigned long flags; /* Flag values/ mode etc */
#define SLF_INUSE 0 /* Channel in use */
#define SLF_ERROR 1 /* Parity, etc. error */
-
- unsigned char leased;
- dev_t line;
- pid_t pid;
};
static struct net_device **slcan_devs;
@@ -462,7 +458,7 @@ static void slc_sync(void)
break;
sl = netdev_priv(dev);
- if (sl->tty || sl->leased)
+ if (sl->tty)
continue;
if (dev->flags & IFF_UP)
dev_close(dev);
@@ -565,8 +561,6 @@ static int slcan_open(struct tty_struct *tty)
sl->tty = tty;
tty->disc_data = sl;
- sl->line = tty_devnum(tty);
- sl->pid = current->pid;
if (!test_bit(SLF_INUSE, &sl->flags)) {
/* Perform the low-level SLCAN initialization. */
@@ -617,8 +611,6 @@ static void slcan_close(struct tty_struct *tty)
tty->disc_data = NULL;
sl->tty = NULL;
- if (!sl->leased)
- sl->line = 0;
/* Flush network side */
unregister_netdev(sl->dev);
--
1.7.6
^ permalink raw reply related
* [PATCH] slip: remove unused 'line' field from the 'slip' structure
From: Matvejchikov Ilya @ 2011-07-19 7:56 UTC (permalink / raw)
To: netdev
Signed-off-by: Matvejchikov Ilya <matvejchikov@gmail.com>
---
drivers/net/slip.c | 3 ---
drivers/net/slip.h | 1 -
2 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/net/slip.c b/drivers/net/slip.c
index 2f110fb..77c4798 100644
--- a/drivers/net/slip.c
+++ b/drivers/net/slip.c
@@ -823,7 +823,6 @@ static int slip_open(struct tty_struct *tty)
sl->tty = tty;
tty->disc_data = sl;
- sl->line = tty_devnum(tty);
sl->pid = current->pid;
if (!test_bit(SLF_INUSE, &sl->flags)) {
@@ -890,8 +889,6 @@ static void slip_close(struct tty_struct *tty)
tty->disc_data = NULL;
sl->tty = NULL;
- if (!sl->leased)
- sl->line = 0;
/* VSV = very important to remove timers */
#ifdef CONFIG_SLIP_SMART
diff --git a/drivers/net/slip.h b/drivers/net/slip.h
index 914e958..aa0764c 100644
--- a/drivers/net/slip.h
+++ b/drivers/net/slip.h
@@ -90,7 +90,6 @@ struct slip {
unsigned char mode; /* SLIP mode */
unsigned char leased;
- dev_t line;
pid_t pid;
#define SL_MODE_SLIP 0
#define SL_MODE_CSLIP 1
--
1.7.6
^ permalink raw reply related
* Re: [PATCH v2] net: filter: BPF 'JIT' compiler for PPC64
From: Benjamin Herrenschmidt @ 2011-07-19 7:55 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Matt Evans, netdev, linuxppc-dev
In-Reply-To: <1311058260.16961.12.camel@edumazet-laptop>
On Tue, 2011-07-19 at 08:51 +0200, Eric Dumazet wrote:
> > + case BPF_S_ANC_CPU:
> > +#ifdef CONFIG_SMP
> > + /*
> > + * PACA ptr is r13:
> > + * raw_smp_processor_id() = local_paca->paca_index
> > + */
>
> This could break if one day linux supports more than 65536 cpus :)
>
> > + PPC_LHZ_OFFS(r_A, 13,
> > + offsetof(struct paca_struct, paca_index));
> > +#else
> > + PPC_LI(r_A, 0);
> > +#endif
> > + break;
As would our implementation of raw_smp_processor_id() and our
spinlocks :-) I don't think we need to fix that -now- but you are
welcome to add something like a
BUILD_BUG_ON(sizeof(local_paca->paca_index) != 2); as a reminder :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [Patch] bluetooth: make 3 functions in hci_conn.c static
From: Américo Wang @ 2011-07-19 7:29 UTC (permalink / raw)
To: Linux Kernel Network Developers
Cc: linux-bluetooth, David S. Miller, Gustavo F. Padovan,
Marcel Holtmann
In-Reply-To: <CAM_iQpUHynJZBJ29qeu_fv4Rko0=7chE5BrhavOKVyzaTDf28A@mail.gmail.com>
On Tue, Jul 19, 2011 at 3:18 PM, Américo Wang <xiyou.wangcong@gmail.com> wrote:
> hci_acl_connect()
> hci_add_sco()
> hci_conn_enter_sniff_mode()
>
> these three functions can become static as there are no callers outside.
>
Self-NAK.
Seems these 3 functions have no callers just accidentally.
^ permalink raw reply
* Re: [patch net-next-2.6] vlan: introduce ndo_vlan_[enable/disable]
From: Michał Mirosław @ 2011-07-19 7:24 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, shemminger, eric.dumazet, greearb
In-Reply-To: <20110718071300.GA2244@minipsycho>
W dniu 18 lipca 2011 09:13 użytkownik Jiri Pirko <jpirko@redhat.com> napisał:
> Sun, Jul 17, 2011 at 11:06:57PM CEST, mirqus@gmail.com wrote:
>>W dniu 17 lipca 2011 21:44 użytkownik Jiri Pirko <jpirko@redhat.com> napisał:
>>> Sun, Jul 17, 2011 at 10:36:04AM CEST, mirqus@gmail.com wrote:
>>>>W dniu 17 lipca 2011 09:30 użytkownik Jiri Pirko <jpirko@redhat.com> napisał:
>>>>> Sat, Jul 16, 2011 at 04:14:36PM CEST, mirqus@gmail.com wrote:
>>>>>>2011/7/16 Jiri Pirko <jpirko@redhat.com>:
>>>>>>> Some devices are not able to enable/disable rx/tw vlan accel separately.
>>>>>>> they depend on ndo_vlan_rx_register to know if to enable of disable
>>>>>>> hw accel. And since ndo_vlan_rx_register is going to die soon,
>>>>>>> this must be resolved.
>>>>>>>
>>>>>>> One solution might be to enable accel on device start every time, even
>>>>>>> if there are no vlan up on. But this would change behaviour and might
>>>>>>> lead to possible regression (on older devices).
>>>>>>[...]
>>>>>>
>>>>>>Please describe the possible regression. As I see it, there won't be
>>>>>>any user visible change of behaviour - network code takes care of
>>>>>>reinserting VLAN tag when necessary. If you think that disabling tag
>>>>>>stripping is beneficial for cases where no VLANs are configured, it's
>>>>>>better to do that in netdev_fix_features() for devices which advertise
>>>>>>NETIF_F_HW_VLAN_RX in hw_features.
>>>>>
>>>>> Well I just wanted to preserve current behaviour which is that in many
>>>>> drivers vlan accel is enabled only if some vid is registered upon the
>>>>> device and it's disabled again when no vid is registered. I can see
>>>>> no way to do this with current code after removing ndo_vlan_rx_register.
>>>>>
>>>>> I expect unexpected
>>>>
>>>>:-D
>>>>
>>>>> ... problems on old cards when vlan accel would be
>>>>> enabled all the time, but maybe I'm wrong...
>>>>
>>>>Device has no way of knowing how the system uses VLAN tags, stripped
>>>>or not. Any problems would be driver problems and since you're making
>>>>it all use generic code, bugs will hit all drivers simultaneously or
>>>>(preferably) won't happen at all.
>>>>
>>>>> One idea is for device which do not support sepatate rx/tx vlan accel
>>>>> enabling/disabling they can probably use ndo_fix_features force to
>>>>> enable/disable rx/tx pair together. That would resolve the situation as
>>>>> well giving user possibility to turn off vlan accel in case of any issues.
>>>>
>>>>That is exactly the idea behind ndo_fix_features.
>>
>>> In netdev_fix_features add check if either one of NETIF_F_HW_VLAN_TX or
>>> NETIF_F_HW_VLAN_RX is set and in that case set the other one. Of course
>>> this would be done only for devices what do not support separate rx/tx
>>> vlan on/off. But how to distinguish? NETIF_F_HW_VLAN_BOTH feature flag?
>>
>>Not in netdev_fix_features(). This case you describe should be handled
>>in driver-specific
>
> Well since the code would be the same in many drivers I was thinking
> about putting it in general code...
>
> Anyway, would you please look at following example patch and tell me if
> it looks good to you?
[...]
> static u32 atl1c_fix_features(struct net_device *netdev, u32 features)
> {
> + u32 changed = netdev->features ^ features;
> +
> + /*
> + * Since there is no support for separate rx/tx vlan accel
> + * enable/disable make sure these are always set in pair.
> + */
> + if ((changed & NETIF_F_HW_VLAN_TX && features & NETIF_F_HW_VLAN_TX) ||
> + (changed & NETIF_F_HW_VLAN_RX && features & NETIF_F_HW_VLAN_RX))
> + features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
> + else
> + features &= ~(NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX);
> +
You ignored my hint about combined TX/RX offload. Is that on purpose?
Your code will toggle VLAN acceleration on every
netdev_update_features call when user requests one offload on and one
off.
BTW, the register flag name (MAC_CTRL_RMV_VLAN) suggests that it
controls only tag stripping. Was it tested or documented that this
also links with tag insertion?
[...]
> +static int atl1c_set_features(struct net_device *netdev, u32 features)
> +{
> + u32 changed = netdev->features ^ features;
> +
> + /*
> + * Test for NETIF_F_HW_VLAN_TX as it's paired with NETIF_F_HW_VLAN_RX
> + * by atl1c_fix_features.
> + */
> + if (changed & NETIF_F_HW_VLAN_TX)
> + atl1c_vlan_mode(netdev, features);
> +
Test for RX is better, as it will match the name of control bit
(MAC_CTRL_RMV_VLAN).
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH v2] net: filter: BPF 'JIT' compiler for PPC64
From: Matt Evans @ 2011-07-19 7:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, netdev
In-Reply-To: <CBA05A49-86F1-40FF-9244-0E4D29EBBA48@kernel.crashing.org>
On 19/07/11 17:17, Kumar Gala wrote:
>
> On Jul 19, 2011, at 2:06 AM, Matt Evans wrote:
>
>> On 19/07/11 16:59, Kumar Gala wrote:
>>>
>>> On Jul 18, 2011, at 9:13 PM, Matt Evans wrote:
>>>
>>>> [snip]
>>>>
>>>> V2: Removed some cut/paste woe in setting SEEN_X even on writes.
>>>> Merci for le review, Eric!
>>>>
>>>> arch/powerpc/Kconfig | 1 +
>>>> arch/powerpc/Makefile | 3 +-
>>>> arch/powerpc/include/asm/ppc-opcode.h | 40 ++
>>>> arch/powerpc/net/Makefile | 4 +
>>>> arch/powerpc/net/bpf_jit.S | 138 +++++++
>>>
>>> can we rename to bpf_jit_64.S, since this doesn't work on PPC32.
>>>
>>>> arch/powerpc/net/bpf_jit.h | 227 +++++++++++
>>>> arch/powerpc/net/bpf_jit_comp.c | 690 +++++++++++++++++++++++++++++++++
>>>
>>> same here, or split between bpf_jit_comp.c (shared between ppc32 & ppc64) and
>>> bpf_jit_comp_64.c
>>
>> A reasonable suggestion -- bpf_jit_64.S certainly. I think it may not be worth
>> splitting bpf_jit_comp.c until we support both tho? (I'm thinking
>> bpf_jit_comp_{32,64}.c would just house the stackframe generation code which is
>> the main difference, plus compile-time switched macros for the odd LD vs LWZ.)
>
> If its most 64-bit specific than just go with bpf_jit_comp_64.c for now. We can refactor later.
Nah, other way round -- it's almost all agnostic but with a couple of functions
that I was recommending moving out to a _64.c and _32.c later, leaving the bulk
still in bpf_jit_comp.c.
Matt
^ permalink raw reply
* [Patch] bluetooth: make 3 functions in hci_conn.c static
From: Américo Wang @ 2011-07-19 7:18 UTC (permalink / raw)
To: Linux Kernel Network Developers
Cc: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
Gustavo F. Padovan, Marcel Holtmann
[-- Attachment #1: Type: text/plain, Size: 134 bytes --]
hci_acl_connect()
hci_add_sco()
hci_conn_enter_sniff_mode()
these three functions can become static as there are no callers outside.
[-- Attachment #2: net-bluetooth-hci_conn_c-make-static.diff --]
[-- Type: text/x-patch, Size: 4460 bytes --]
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
---
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 6c994c0..608e28b 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -409,9 +409,7 @@ static inline struct hci_conn *hci_conn_hash_lookup_state(struct hci_dev *hdev,
return NULL;
}
-void hci_acl_connect(struct hci_conn *conn);
void hci_acl_disconn(struct hci_conn *conn, __u8 reason);
-void hci_add_sco(struct hci_conn *conn, __u16 handle);
void hci_setup_sync(struct hci_conn *conn, __u16 handle);
void hci_sco_setup(struct hci_conn *conn, __u8 status);
@@ -428,7 +426,6 @@ int hci_conn_change_link_key(struct hci_conn *conn);
int hci_conn_switch_role(struct hci_conn *conn, __u8 role);
void hci_conn_enter_active_mode(struct hci_conn *conn);
-void hci_conn_enter_sniff_mode(struct hci_conn *conn);
void hci_conn_hold_device(struct hci_conn *conn);
void hci_conn_put_device(struct hci_conn *conn);
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index bcd158f..983a337 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -72,7 +72,7 @@ static void hci_le_connect_cancel(struct hci_conn *conn)
hci_send_cmd(conn->hdev, HCI_OP_LE_CREATE_CONN_CANCEL, 0, NULL);
}
-void hci_acl_connect(struct hci_conn *conn)
+static void hci_acl_connect(struct hci_conn *conn)
{
struct hci_dev *hdev = conn->hdev;
struct inquiry_entry *ie;
@@ -141,7 +141,7 @@ void hci_acl_disconn(struct hci_conn *conn, __u8 reason)
hci_send_cmd(conn->hdev, HCI_OP_DISCONNECT, sizeof(cp), &cp);
}
-void hci_add_sco(struct hci_conn *conn, __u16 handle)
+static void hci_add_sco(struct hci_conn *conn, __u16 handle)
{
struct hci_dev *hdev = conn->hdev;
struct hci_cp_add_sco cp;
@@ -260,6 +260,42 @@ static void hci_conn_timeout(unsigned long arg)
hci_dev_unlock(hdev);
}
+/* Enter sniff mode */
+static void hci_conn_enter_sniff_mode(struct hci_conn *conn)
+{
+ struct hci_dev *hdev = conn->hdev;
+
+ BT_DBG("conn %p mode %d", conn, conn->mode);
+
+ if (test_bit(HCI_RAW, &hdev->flags))
+ return;
+
+ if (!lmp_sniff_capable(hdev) || !lmp_sniff_capable(conn))
+ return;
+
+ if (conn->mode != HCI_CM_ACTIVE || !(conn->link_policy & HCI_LP_SNIFF))
+ return;
+
+ if (lmp_sniffsubr_capable(hdev) && lmp_sniffsubr_capable(conn)) {
+ struct hci_cp_sniff_subrate cp;
+ cp.handle = cpu_to_le16(conn->handle);
+ cp.max_latency = cpu_to_le16(0);
+ cp.min_remote_timeout = cpu_to_le16(0);
+ cp.min_local_timeout = cpu_to_le16(0);
+ hci_send_cmd(hdev, HCI_OP_SNIFF_SUBRATE, sizeof(cp), &cp);
+ }
+
+ if (!test_and_set_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend)) {
+ struct hci_cp_sniff_mode cp;
+ cp.handle = cpu_to_le16(conn->handle);
+ cp.max_interval = cpu_to_le16(hdev->sniff_max_interval);
+ cp.min_interval = cpu_to_le16(hdev->sniff_min_interval);
+ cp.attempt = cpu_to_le16(4);
+ cp.timeout = cpu_to_le16(1);
+ hci_send_cmd(hdev, HCI_OP_SNIFF_MODE, sizeof(cp), &cp);
+ }
+}
+
static void hci_conn_idle(unsigned long arg)
{
struct hci_conn *conn = (void *) arg;
@@ -703,42 +739,6 @@ timer:
jiffies + msecs_to_jiffies(hdev->idle_timeout));
}
-/* Enter sniff mode */
-void hci_conn_enter_sniff_mode(struct hci_conn *conn)
-{
- struct hci_dev *hdev = conn->hdev;
-
- BT_DBG("conn %p mode %d", conn, conn->mode);
-
- if (test_bit(HCI_RAW, &hdev->flags))
- return;
-
- if (!lmp_sniff_capable(hdev) || !lmp_sniff_capable(conn))
- return;
-
- if (conn->mode != HCI_CM_ACTIVE || !(conn->link_policy & HCI_LP_SNIFF))
- return;
-
- if (lmp_sniffsubr_capable(hdev) && lmp_sniffsubr_capable(conn)) {
- struct hci_cp_sniff_subrate cp;
- cp.handle = cpu_to_le16(conn->handle);
- cp.max_latency = cpu_to_le16(0);
- cp.min_remote_timeout = cpu_to_le16(0);
- cp.min_local_timeout = cpu_to_le16(0);
- hci_send_cmd(hdev, HCI_OP_SNIFF_SUBRATE, sizeof(cp), &cp);
- }
-
- if (!test_and_set_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend)) {
- struct hci_cp_sniff_mode cp;
- cp.handle = cpu_to_le16(conn->handle);
- cp.max_interval = cpu_to_le16(hdev->sniff_max_interval);
- cp.min_interval = cpu_to_le16(hdev->sniff_min_interval);
- cp.attempt = cpu_to_le16(4);
- cp.timeout = cpu_to_le16(1);
- hci_send_cmd(hdev, HCI_OP_SNIFF_MODE, sizeof(cp), &cp);
- }
-}
-
/* Drop all connection on the device */
void hci_conn_hash_flush(struct hci_dev *hdev)
{
^ permalink raw reply related
* Re: [PATCH v2] net: filter: BPF 'JIT' compiler for PPC64
From: Kumar Gala @ 2011-07-19 7:17 UTC (permalink / raw)
To: Matt Evans; +Cc: linuxppc-dev, netdev
In-Reply-To: <4E252CFE.4070408@ozlabs.org>
On Jul 19, 2011, at 2:06 AM, Matt Evans wrote:
> On 19/07/11 16:59, Kumar Gala wrote:
>>
>> On Jul 18, 2011, at 9:13 PM, Matt Evans wrote:
>>
>>> An implementation of a code generator for BPF programs to speed up packet
>>> filtering on PPC64, inspired by Eric Dumazet's x86-64 version.
>>>
>>> Filter code is generated as an ABI-compliant function in module_alloc()'d mem
>>> with stackframe & prologue/epilogue generated if required (simple filters don't
>>> need anything more than an li/blr). The filter's local variables, M[], live in
>>> registers. Supports all BPF opcodes, although "complicated" loads from negative
>>> packet offsets (e.g. SKF_LL_OFF) are not yet supported.
>>>
>>> There are a couple of further optimisations left for future work; many-pass
>>> assembly with branch-reach reduction and a register allocator to push M[]
>>> variables into volatile registers would improve the code quality further.
>>>
>>> This currently supports big-endian 64-bit PowerPC only (but is fairly simple
>>> to port to PPC32 or LE!).
>>>
>>> Enabled in the same way as x86-64:
>>>
>>> echo 1 > /proc/sys/net/core/bpf_jit_enable
>>>
>>> Or, enabled with extra debug output:
>>>
>>> echo 2 > /proc/sys/net/core/bpf_jit_enable
>>>
>>> Signed-off-by: Matt Evans <matt@ozlabs.org>
>>> ---
>>>
>>> V2: Removed some cut/paste woe in setting SEEN_X even on writes.
>>> Merci for le review, Eric!
>>>
>>> arch/powerpc/Kconfig | 1 +
>>> arch/powerpc/Makefile | 3 +-
>>> arch/powerpc/include/asm/ppc-opcode.h | 40 ++
>>> arch/powerpc/net/Makefile | 4 +
>>> arch/powerpc/net/bpf_jit.S | 138 +++++++
>>
>> can we rename to bpf_jit_64.S, since this doesn't work on PPC32.
>>
>>> arch/powerpc/net/bpf_jit.h | 227 +++++++++++
>>> arch/powerpc/net/bpf_jit_comp.c | 690 +++++++++++++++++++++++++++++++++
>>
>> same here, or split between bpf_jit_comp.c (shared between ppc32 & ppc64) and
>> bpf_jit_comp_64.c
>
> A reasonable suggestion -- bpf_jit_64.S certainly. I think it may not be worth
> splitting bpf_jit_comp.c until we support both tho? (I'm thinking
> bpf_jit_comp_{32,64}.c would just house the stackframe generation code which is
> the main difference, plus compile-time switched macros for the odd LD vs LWZ.)
If its most 64-bit specific than just go with bpf_jit_comp_64.c for now. We can refactor later.
>
> Sorry it's not 32bit-friendly just yet (I knew you'd ask, hehe), I've postponed
> that for when I get a mo :-)
:)
^ permalink raw reply
* Re: [PATCH v2] net: filter: BPF 'JIT' compiler for PPC64
From: Matt Evans @ 2011-07-19 7:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, netdev
In-Reply-To: <51978BAA-10A1-483D-B551-CCC2B69C72EA@kernel.crashing.org>
On 19/07/11 16:59, Kumar Gala wrote:
>
> On Jul 18, 2011, at 9:13 PM, Matt Evans wrote:
>
>> An implementation of a code generator for BPF programs to speed up packet
>> filtering on PPC64, inspired by Eric Dumazet's x86-64 version.
>>
>> Filter code is generated as an ABI-compliant function in module_alloc()'d mem
>> with stackframe & prologue/epilogue generated if required (simple filters don't
>> need anything more than an li/blr). The filter's local variables, M[], live in
>> registers. Supports all BPF opcodes, although "complicated" loads from negative
>> packet offsets (e.g. SKF_LL_OFF) are not yet supported.
>>
>> There are a couple of further optimisations left for future work; many-pass
>> assembly with branch-reach reduction and a register allocator to push M[]
>> variables into volatile registers would improve the code quality further.
>>
>> This currently supports big-endian 64-bit PowerPC only (but is fairly simple
>> to port to PPC32 or LE!).
>>
>> Enabled in the same way as x86-64:
>>
>> echo 1 > /proc/sys/net/core/bpf_jit_enable
>>
>> Or, enabled with extra debug output:
>>
>> echo 2 > /proc/sys/net/core/bpf_jit_enable
>>
>> Signed-off-by: Matt Evans <matt@ozlabs.org>
>> ---
>>
>> V2: Removed some cut/paste woe in setting SEEN_X even on writes.
>> Merci for le review, Eric!
>>
>> arch/powerpc/Kconfig | 1 +
>> arch/powerpc/Makefile | 3 +-
>> arch/powerpc/include/asm/ppc-opcode.h | 40 ++
>> arch/powerpc/net/Makefile | 4 +
>> arch/powerpc/net/bpf_jit.S | 138 +++++++
>
> can we rename to bpf_jit_64.S, since this doesn't work on PPC32.
>
>> arch/powerpc/net/bpf_jit.h | 227 +++++++++++
>> arch/powerpc/net/bpf_jit_comp.c | 690 +++++++++++++++++++++++++++++++++
>
> same here, or split between bpf_jit_comp.c (shared between ppc32 & ppc64) and
> bpf_jit_comp_64.c
A reasonable suggestion -- bpf_jit_64.S certainly. I think it may not be worth
splitting bpf_jit_comp.c until we support both tho? (I'm thinking
bpf_jit_comp_{32,64}.c would just house the stackframe generation code which is
the main difference, plus compile-time switched macros for the odd LD vs LWZ.)
Sorry it's not 32bit-friendly just yet (I knew you'd ask, hehe), I've postponed
that for when I get a mo :-)
Cheers,
Matt
^ permalink raw reply
* Re: [PATCH v2] net: filter: BPF 'JIT' compiler for PPC64
From: Kumar Gala @ 2011-07-19 6:59 UTC (permalink / raw)
To: Matt Evans; +Cc: linuxppc-dev, netdev
In-Reply-To: <4E24E867.9050909@ozlabs.org>
On Jul 18, 2011, at 9:13 PM, Matt Evans wrote:
> An implementation of a code generator for BPF programs to speed up packet
> filtering on PPC64, inspired by Eric Dumazet's x86-64 version.
>
> Filter code is generated as an ABI-compliant function in module_alloc()'d mem
> with stackframe & prologue/epilogue generated if required (simple filters don't
> need anything more than an li/blr). The filter's local variables, M[], live in
> registers. Supports all BPF opcodes, although "complicated" loads from negative
> packet offsets (e.g. SKF_LL_OFF) are not yet supported.
>
> There are a couple of further optimisations left for future work; many-pass
> assembly with branch-reach reduction and a register allocator to push M[]
> variables into volatile registers would improve the code quality further.
>
> This currently supports big-endian 64-bit PowerPC only (but is fairly simple
> to port to PPC32 or LE!).
>
> Enabled in the same way as x86-64:
>
> echo 1 > /proc/sys/net/core/bpf_jit_enable
>
> Or, enabled with extra debug output:
>
> echo 2 > /proc/sys/net/core/bpf_jit_enable
>
> Signed-off-by: Matt Evans <matt@ozlabs.org>
> ---
>
> V2: Removed some cut/paste woe in setting SEEN_X even on writes.
> Merci for le review, Eric!
>
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/Makefile | 3 +-
> arch/powerpc/include/asm/ppc-opcode.h | 40 ++
> arch/powerpc/net/Makefile | 4 +
> arch/powerpc/net/bpf_jit.S | 138 +++++++
can we rename to bpf_jit_64.S, since this doesn't work on PPC32.
> arch/powerpc/net/bpf_jit.h | 227 +++++++++++
> arch/powerpc/net/bpf_jit_comp.c | 690 +++++++++++++++++++++++++++++++++
same here, or split between bpf_jit_comp.c (shared between ppc32 & ppc64) and bpf_jit_comp_64.c
- k
^ permalink raw reply
* Re: [PATCH v2] net: filter: BPF 'JIT' compiler for PPC64
From: Eric Dumazet @ 2011-07-19 6:51 UTC (permalink / raw)
To: Matt Evans; +Cc: linuxppc-dev, netdev
In-Reply-To: <4E24E867.9050909@ozlabs.org>
Le mardi 19 juillet 2011 à 12:13 +1000, Matt Evans a écrit :
> An implementation of a code generator for BPF programs to speed up packet
> filtering on PPC64, inspired by Eric Dumazet's x86-64 version.
>
> Filter code is generated as an ABI-compliant function in module_alloc()'d mem
> with stackframe & prologue/epilogue generated if required (simple filters don't
> need anything more than an li/blr). The filter's local variables, M[], live in
> registers. Supports all BPF opcodes, although "complicated" loads from negative
> packet offsets (e.g. SKF_LL_OFF) are not yet supported.
>
> There are a couple of further optimisations left for future work; many-pass
> assembly with branch-reach reduction and a register allocator to push M[]
> variables into volatile registers would improve the code quality further.
>
> This currently supports big-endian 64-bit PowerPC only (but is fairly simple
> to port to PPC32 or LE!).
>
> Enabled in the same way as x86-64:
>
> echo 1 > /proc/sys/net/core/bpf_jit_enable
>
> Or, enabled with extra debug output:
>
> echo 2 > /proc/sys/net/core/bpf_jit_enable
>
> Signed-off-by: Matt Evans <matt@ozlabs.org>
> ---
>
> V2: Removed some cut/paste woe in setting SEEN_X even on writes.
> Merci for le review, Eric!
>
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/Makefile | 3 +-
> arch/powerpc/include/asm/ppc-opcode.h | 40 ++
> arch/powerpc/net/Makefile | 4 +
> arch/powerpc/net/bpf_jit.S | 138 +++++++
> arch/powerpc/net/bpf_jit.h | 227 +++++++++++
> arch/powerpc/net/bpf_jit_comp.c | 690 +++++++++++++++++++++++++++++++++
> 7 files changed, 1102 insertions(+), 1 deletions(-)
>
> + case BPF_S_ANC_CPU:
> +#ifdef CONFIG_SMP
> + /*
> + * PACA ptr is r13:
> + * raw_smp_processor_id() = local_paca->paca_index
> + */
This could break if one day linux supports more than 65536 cpus :)
> + PPC_LHZ_OFFS(r_A, 13,
> + offsetof(struct paca_struct, paca_index));
> +#else
> + PPC_LI(r_A, 0);
> +#endif
> + break;
> +
> +
> + case BPF_S_LDX_B_MSH:
> + /*
> + * x86 version drops packet (RET 0) when K<0, whereas
> + * interpreter does allow K<0 (__load_pointer, special
> + * ancillary data).
> + */
Hmm, thanks I'll take a look at this.
> + func = sk_load_byte_msh;
> + goto common_load;
> + break;
> +
> + /*** Jump and branches ***/
> + default:
> + /* The filter contains something cruel & unusual.
> + * We don't handle it, but also there shouldn't be
> + * anything missing from our list.
> + */
> + pr_err("BPF filter opcode %04x (@%d) unsupported\n",
> + filter[i].code, i);
You should at least ratelimit this message ?
On x86_64 I chose to silently fall back to interpretor for a "complex
filter" or "unsupported opcode".
> + return -ENOTSUPP;
> + }
> +
> + }
> + /* Set end-of-body-code address for exit. */
> + addrs[i] = ctx->idx * 4;
> +
> + return 0;
> +}
> +
^ permalink raw reply
* Re: ath: Unable to reset channel (2412 MHz), reset status -5
From: Mohammed Shafi @ 2011-07-19 6:46 UTC (permalink / raw)
To: Justin P. Mattock
Cc: netdev@vger.kernel.org, linux-wireless,
linux-kernel@vger.kernel.org
In-Reply-To: <4E2525BA.4090902@gmail.com>
On Tue, Jul 19, 2011 at 12:05 PM, Justin P. Mattock
<justinmattock@gmail.com> wrote:
> On 07/18/2011 11:25 PM, Mohammed Shafi wrote:
>>
>> On Tue, Jul 19, 2011 at 11:43 AM, Justin P. Mattock
>> <justinmattock@gmail.com> wrote:
>>>
>>> seems with the latest Mainline I am getting the ath9k carpping out after
>>> a
>>> while of streaming(dmesg below)..:
>>> http://fpaste.org/D7wM/
>>>
>>> will try a bisect if I have the time..
>>
>> I will try to recreate here with 3.0.0-rc7-wl, we can get more
>> information by ath9k debug=0xffffffff.
>> thanks.
>>
>
> cool!
> seems to fire off randomly over here.
I have got AR5416, will try with that.
--
shafi
^ permalink raw reply
* Re: ath: Unable to reset channel (2412 MHz), reset status -5
From: Justin P. Mattock @ 2011-07-19 6:35 UTC (permalink / raw)
To: Mohammed Shafi
Cc: netdev@vger.kernel.org, linux-wireless,
linux-kernel@vger.kernel.org
In-Reply-To: <CAD2nsn12vOXv-msWR+GF7edz3Q26P-pb4H-SO4rf2RHjC7mG+w@mail.gmail.com>
On 07/18/2011 11:25 PM, Mohammed Shafi wrote:
> On Tue, Jul 19, 2011 at 11:43 AM, Justin P. Mattock
> <justinmattock@gmail.com> wrote:
>> seems with the latest Mainline I am getting the ath9k carpping out after a
>> while of streaming(dmesg below)..:
>> http://fpaste.org/D7wM/
>>
>> will try a bisect if I have the time..
>
> I will try to recreate here with 3.0.0-rc7-wl, we can get more
> information by ath9k debug=0xffffffff.
> thanks.
>
cool!
seems to fire off randomly over here.
Justin P. Mattock
^ permalink raw reply
* Re: ath: Unable to reset channel (2412 MHz), reset status -5
From: Mohammed Shafi @ 2011-07-19 6:25 UTC (permalink / raw)
To: Justin P. Mattock
Cc: netdev@vger.kernel.org, linux-wireless,
linux-kernel@vger.kernel.org
In-Reply-To: <4E252076.1050309@gmail.com>
On Tue, Jul 19, 2011 at 11:43 AM, Justin P. Mattock
<justinmattock@gmail.com> wrote:
> seems with the latest Mainline I am getting the ath9k carpping out after a
> while of streaming(dmesg below)..:
> http://fpaste.org/D7wM/
>
> will try a bisect if I have the time..
I will try to recreate here with 3.0.0-rc7-wl, we can get more
information by ath9k debug=0xffffffff.
thanks.
--
shafi
^ 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