* Re: rndis gadget: Inconsistent locking
From: David Brownell @ 2011-01-10 12:14 UTC (permalink / raw)
To: Michał Nazarewicz, Neil Jones; +Cc: linux-usb, netdev
In-Reply-To: <AANLkTikkkit_L3qHgoyfVUwDYwahbFDJdF8eosH+woAz@mail.gmail.com>
> I have just retested Michals patch but I have found another
> lockdep failure.
>
> It looks like rndis_msg_parser() can call dev_get_stats> too:
Can someone provide a fully working patch then?
Or maybe just revert the one that caused all the
breakage??
Rememeber that this driver was working fine for
years before netdev changes added multiple bugs
because (at least) they didn't update all callers.
^ permalink raw reply
* Re: weird network problem - stalls, reload works
From: Michael Tokarev @ 2011-01-10 12:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <4CFC17B8.4050908@msgid.tls.msk.ru>
Replying to my old email, full details below.
So I replaced the motherboard on this machine,
and now everything is working fine. Difficult
to tell if it was really hardware issue or a
software problem specific to this hardware,
but the problem is weird enough.
It's more: I can't reproduce the issue on this
motherboard in a test environment.
/mjt
06.12.2010 01:52, Michael Tokarev wrote:
> Hello.
>
> I've a weird networking problem here, which I'm
> trying to hunt for some time.
>
> Small LAN, just 3 machines and a server, all in
> single small room, all connected to a 100Mbps switch.
>
> Sometimes, network between the (linux) server and
> workstations just stops. It may happen after
> transferring a few megabytes of data (rare), or
> whole thing may work for several days or even
> weeks in a row, but end result is the same: at
> some point it stalls.
>
> Reloading the interface in question, like this:
>
> ifdown eth0; sleep 2; ifup eth0
>
> restores the network back, till it breaks again.
> Note here that, say, sleep 1 is not sufficient
> to restore the functionality, it has little effect.
> No sleep at all makes almost no difference, ie,
> such reload does not help.
>
> The stalls looks like the server is suffering from
> massive packet loss in receive path. It does not
> lose all packets, and the amount of lost packets
> increases with time, in a timeframe of several
> minutes.
>
> Doing a data transfer from a client machine to this
> linux box, it goes at full ~10MB/s speed, next when
> the stall is about to happen the speed drops to 6MB/s,
> 4, 1MB/s, 600KB/s, till eventually the connection just
> times out.
>
> The interesting data point is that the NIC does not
> generate any interrupts during such stalls, as if
> there's no packets are coming from the network at
> all - even if during that time, the client workstations
> are sending ARP requests (if nothing more).
>
> Here's how ping on the server looks like (pinging one
> of the machine on the LAN):
>
> 64 bytes from 192.168.78.20: icmp_seq=1 ttl=128 time=5008 ms
> 64 bytes from 192.168.78.20: icmp_seq=2 ttl=128 time=5000 ms
> 64 bytes from 192.168.78.20: icmp_seq=3 ttl=128 time=6000 ms
> 64 bytes from 192.168.78.20: icmp_seq=4 ttl=128 time=7000 ms
> 64 bytes from 192.168.78.20: icmp_seq=5 ttl=128 time=7000 ms
> 64 bytes from 192.168.78.20: icmp_seq=6 ttl=128 time=7000 ms
> 64 bytes from 192.168.78.20: icmp_seq=7 ttl=128 time=7000 ms
> 64 bytes from 192.168.78.20: icmp_seq=8 ttl=128 time=7000 ms
> 64 bytes from 192.168.78.20: icmp_seq=9 ttl=128 time=7000 ms
> 64 bytes from 192.168.78.20: icmp_seq=10 ttl=128 time=7000 ms
> 64 bytes from 192.168.78.20: icmp_seq=11 ttl=128 time=7000 ms
> 64 bytes from 192.168.78.20: icmp_seq=12 ttl=128 time=6320 ms
> 64 bytes from 192.168.78.20: icmp_seq=13 ttl=128 time=6000 ms
> 64 bytes from 192.168.78.20: icmp_seq=14 ttl=128 time=6000 ms
> 64 bytes from 192.168.78.20: icmp_seq=15 ttl=128 time=6000 ms
> 64 bytes from 192.168.78.20: icmp_seq=16 ttl=128 time=6000 ms
> 64 bytes from 192.168.78.20: icmp_seq=17 ttl=128 time=6000 ms
> 64 bytes from 192.168.78.20: icmp_seq=18 ttl=128 time=6000 ms
> 64 bytes from 192.168.78.20: icmp_seq=19 ttl=128 time=7000 ms
> 64 bytes from 192.168.78.20: icmp_seq=20 ttl=128 time=7000 ms
> 64 bytes from 192.168.78.20: icmp_seq=21 ttl=128 time=7000 ms
> 64 bytes from 192.168.78.20: icmp_seq=22 ttl=128 time=7000 ms
> 64 bytes from 192.168.78.20: icmp_seq=23 ttl=128 time=7000 ms
> 64 bytes from 192.168.78.20: icmp_seq=24 ttl=128 time=6007 ms
> 64 bytes from 192.168.78.20: icmp_seq=25 ttl=128 time=6001 ms
> 64 bytes from 192.168.78.20: icmp_seq=26 ttl=128 time=6010 ms
> 64 bytes from 192.168.78.20: icmp_seq=27 ttl=128 time=5014 ms
> 64 bytes from 192.168.78.20: icmp_seq=28 ttl=128 time=5011 ms
> 64 bytes from 192.168.78.20: icmp_seq=29 ttl=128 time=5020 ms
> 64 bytes from 192.168.78.20: icmp_seq=30 ttl=128 time=5020 ms
> 64 bytes from 192.168.78.20: icmp_seq=31 ttl=128 time=6018 ms
> 64 bytes from 192.168.78.20: icmp_seq=32 ttl=128 time=7010 ms
> 64 bytes from 192.168.78.20: icmp_seq=33 ttl=128 time=7008 ms
> 64 bytes from 192.168.78.20: icmp_seq=34 ttl=128 time=7000 ms
> 64 bytes from 192.168.78.20: icmp_seq=35 ttl=128 time=7000 ms
>
> It looks like the NIC does not deliver any packets by its
> own, but notices something arrived when you actually try
> to _send_ sometihng - hence the delays above, almost whole
> seconds (since ping sends data with 1sec intervals).
>
> Here's normal ping output right after "restarting" the interface:
>
> 64 bytes from 192.168.78.20: icmp_seq=1 ttl=128 time=0.161 ms
> 64 bytes from 192.168.78.20: icmp_seq=2 ttl=128 time=0.119 ms
> 64 bytes from 192.168.78.20: icmp_seq=3 ttl=128 time=0.117 ms
> 64 bytes from 192.168.78.20: icmp_seq=4 ttl=128 time=0.381 ms
> 64 bytes from 192.168.78.20: icmp_seq=5 ttl=128 time=0.131 ms
> 64 bytes from 192.168.78.20: icmp_seq=6 ttl=128 time=0.133 ms
>
> And at restart, the following gets printed in dmesg:
>
> [ 3439.360831] forcedeth 0000:00:0a.0: irq 47 for MSI/MSI-X
>
>
> So far we tried to replace everything in this network:
> started with the NIC on the server, all wires, the switch,
> and even replaced the client computers (upgraded them from
> some old to current hardware). Even changing the NIC on
> the server did not help - rtl8139 behaves the same way,
> but it needs a bit more time to trigger the issue.
>
> The problem happens with several different kernels - at
> least 2.6.27 triggers it, 2.6.32 and 2.6.35 all behaves
> the same, 32 or 64bit.
>
> The machine is based on Asus M2N-VM DVI motherboard, which
> is nVidia MCP67-based system. The NIC is on-board forcedeth
> (and as I mentioned above the same prob happens with rtl8139
> card).
>
> This machine has 2 more NICs inserted (used for WAN link and
> for another tiny LAN segment) - these does not show the issue,
> but they both run at 10Mbps, so maybe it needs 10x more time.
> When the eth0 LAN segment stops working, the rest of the system
> works just fine, including these 2 NICs and hard drives.
>
> I also tried to disable MSI, loading forcedeth with msi=0, -
> this results in usage of IO-APIC-fasteoi for the NIC instead
> of usual PCI-MSI-edge, but does not change the situation.
>
> So I'm quite stuck here, and don't know what to do next.
> My next bet is to try another motherboard, in a hope that
> this is just some broken interrupt controller, but it is
> a bit too unreal...
>
> Any hints on what to try are greatly apprecated...
>
> Thanks!
>
> /mjt
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next 07/12] e1000: Add support for the CE4100 reference platform
From: Florian Fainelli @ 2011-01-10 12:44 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: davem, Dirk Brandewie, netdev, gosp, bphilips
In-Reply-To: <1294360199-9860-8-git-send-email-jeffrey.t.kirsher@intel.com>
Hello,
On Friday 07 January 2011 01:29:54 jeffrey.t.kirsher@intel.com wrote:
> From: Dirk Brandewie <dirk.j.brandewie@intel.com>
>
> This patch adds support for the gigabit phys present on the CE4100
> reference platforms.
>
> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/e1000/e1000_hw.c | 328
> +++++++++++++++++++++++++++++++-------- drivers/net/e1000/e1000_hw.h |
> 59 +++++++-
> drivers/net/e1000/e1000_main.c | 35 ++++
> drivers/net/e1000/e1000_osdep.h | 19 ++-
> 4 files changed, 365 insertions(+), 76 deletions(-)
>
[snip]
> @@ -2840,7 +2985,7 @@ static s32 e1000_write_phy_reg_ex(struct e1000_hw
> *hw, u32 reg_addr, {
> u32 i;
> u32 mdic = 0;
> - const u32 phy_addr = 1;
> + const u32 phy_addr = (hw->mac_type == e1000_ce4100) ? hw->phy_addr : 1;
Why not simply use hw->phy_addr and set it to 1 when mac_type is not e1000_ce4100?
hw->phy_addr for CE4100 is auto detected later in this patch, so this should be safe.
>
> e_dbg("e1000_write_phy_reg_ex");
>
[snip]
> @@ -1135,6 +1153,20 @@ static int __devinit e1000_probe(struct pci_dev
> *pdev, adapter->wol = adapter->eeprom_wol;
> device_set_wakeup_enable(&adapter->pdev->dev, adapter->wol);
>
> + /* Auto detect PHY address */
> + if (hw->mac_type == e1000_ce4100) {
> + for (i = 0; i < 32; i++) {
^PHY_MAX_ADDR (in linux/phy.h)
> + hw->phy_addr = i;
> + e1000_read_phy_reg(hw, PHY_ID2, &tmp);
> + if (tmp == 0 || tmp == 0xFF) {
> + if (i == 31)
> + goto err_eeprom;
> + continue;
> + } else
> + break;
> + }
> + }
Do not you want to also autodetect the PHY address for all e1000
variants?
> +
> /* reset the hardware with the new settings */
> e1000_reset(adapter);
>
> @@ -1171,6 +1203,8 @@ err_eeprom:
> kfree(adapter->rx_ring);
> err_dma:
> err_sw_init:
> +err_mdio_ioremap:
> + iounmap(ce4100_gbe_mdio_base_virt);
> iounmap(hw->hw_addr);
> err_ioremap:
> free_netdev(netdev);
> @@ -1409,6 +1443,7 @@ static bool e1000_check_64k_bound(struct
> e1000_adapter *adapter, void *start, /* First rev 82545 and 82546 need to
> not allow any memory
> * write location to cross 64k boundary due to errata 23 */
> if (hw->mac_type == e1000_82545 ||
> + hw->mac_type == e1000_ce4100 ||
> hw->mac_type == e1000_82546) {
> return ((begin ^ (end - 1)) >> 16) != 0 ? false : true;
> }
> diff --git a/drivers/net/e1000/e1000_osdep.h
> b/drivers/net/e1000/e1000_osdep.h index edd1c75..55c1711 100644
> --- a/drivers/net/e1000/e1000_osdep.h
> +++ b/drivers/net/e1000/e1000_osdep.h
> @@ -34,12 +34,21 @@
> #ifndef _E1000_OSDEP_H_
> #define _E1000_OSDEP_H_
>
> -#include <linux/types.h>
> -#include <linux/pci.h>
> -#include <linux/delay.h>
> #include <asm/io.h>
> -#include <linux/interrupt.h>
> -#include <linux/sched.h>
> +
> +#define CONFIG_RAM_BASE 0x60000
> +#define GBE_CONFIG_OFFSET 0x0
> +
> +#define GBE_CONFIG_RAM_BASE \
> + ((unsigned int)(CONFIG_RAM_BASE + GBE_CONFIG_OFFSET))
> +
> +#define GBE_CONFIG_BASE_VIRT phys_to_virt(GBE_CONFIG_RAM_BASE)
> +
> +#define GBE_CONFIG_FLASH_WRITE(base, offset, count, data) \
> + (iowrite16_rep(base + offset, data, count))
> +
> +#define GBE_CONFIG_FLASH_READ(base, offset, count, data) \
> + (ioread16_rep(base + (offset << 1), data, count))
In my opinion, this is unsafe, especially because not everyone places a valid
e1000 "fake" EEPROM at 0x60000. Also, this is done by the bootloader, so there
is no guarantee chainloading, kexec/kdump or anything overwrites the zone.
Rather I'd go with doing a request_firmware() of the eeprom or, a platform-
specific callback to access it.
Retrieving such board specific informations is really integrator specific.
--
Florian
^ permalink raw reply
* [PATCH 2/5] netdev: bfin_mac: mark setup_system_regs as static
From: Mike Frysinger @ 2011-01-10 12:54 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: uclinux-dist-devel
In-Reply-To: <1294664073-1950-1-git-send-email-vapier@gentoo.org>
No need for this to be exported since it is only used in this driver.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
drivers/net/bfin_mac.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c
index a572bcb..e712be4 100644
--- a/drivers/net/bfin_mac.c
+++ b/drivers/net/bfin_mac.c
@@ -558,7 +558,7 @@ static const struct ethtool_ops bfin_mac_ethtool_ops = {
};
/**************************************************************************/
-void setup_system_regs(struct net_device *dev)
+static void setup_system_regs(struct net_device *dev)
{
struct bfin_mac_local *lp = netdev_priv(dev);
int i;
--
1.7.4.rc1
^ permalink raw reply related
* [PATCH 3/5] netdev: bfin_mac: drop unused Mac data
From: Mike Frysinger @ 2011-01-10 12:54 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: uclinux-dist-devel
In-Reply-To: <1294664073-1950-1-git-send-email-vapier@gentoo.org>
We don't use this local "Mac" data anywhere (since we rely on the
netdev's storage), so punt it.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
drivers/net/bfin_mac.h | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bfin_mac.h b/drivers/net/bfin_mac.h
index aed68be..4827f6b 100644
--- a/drivers/net/bfin_mac.h
+++ b/drivers/net/bfin_mac.h
@@ -68,7 +68,6 @@ struct bfin_mac_local {
*/
struct net_device_stats stats;
- unsigned char Mac[6]; /* MAC address of the board */
spinlock_t lock;
int wol; /* Wake On Lan */
--
1.7.4.rc1
^ permalink raw reply related
* [PATCH 4/5] netdev: bfin_mac: let boards set vlan masks
From: Mike Frysinger @ 2011-01-10 12:54 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: uclinux-dist-devel
In-Reply-To: <1294664073-1950-1-git-send-email-vapier@gentoo.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
drivers/net/bfin_mac.c | 7 +++++++
drivers/net/bfin_mac.h | 3 +++
include/linux/bfin_mac.h | 1 +
3 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c
index e712be4..0b9fc51 100644
--- a/drivers/net/bfin_mac.c
+++ b/drivers/net/bfin_mac.c
@@ -588,6 +588,10 @@ static void setup_system_regs(struct net_device *dev)
bfin_write_EMAC_MMC_CTL(RSTC | CROLL);
+ /* Set vlan regs to let 1522 bytes long packets pass through */
+ bfin_write_EMAC_VLAN1(lp->vlan1_mask);
+ bfin_write_EMAC_VLAN2(lp->vlan2_mask);
+
/* Initialize the TX DMA channel registers */
bfin_write_DMA2_X_COUNT(0);
bfin_write_DMA2_X_MODIFY(4);
@@ -1520,6 +1524,9 @@ static int __devinit bfin_mac_probe(struct platform_device *pdev)
goto out_err_mii_probe;
}
+ lp->vlan1_mask = ETH_P_8021Q | mii_bus_data->vlan1_mask;
+ lp->vlan2_mask = ETH_P_8021Q | mii_bus_data->vlan2_mask;
+
/* Fill in the fields of the device structure with ethernet values. */
ether_setup(ndev);
diff --git a/drivers/net/bfin_mac.h b/drivers/net/bfin_mac.h
index 4827f6b..c1a0d66 100644
--- a/drivers/net/bfin_mac.h
+++ b/drivers/net/bfin_mac.h
@@ -75,6 +75,9 @@ struct bfin_mac_local {
struct timer_list tx_reclaim_timer;
struct net_device *ndev;
+ /* Data for EMAC_VLAN1 regs */
+ u16 vlan1_mask, vlan2_mask;
+
/* MII and PHY stuffs */
int old_link; /* used by bf537_adjust_link */
int old_speed;
diff --git a/include/linux/bfin_mac.h b/include/linux/bfin_mac.h
index 904dec7..a69554e 100644
--- a/include/linux/bfin_mac.h
+++ b/include/linux/bfin_mac.h
@@ -24,6 +24,7 @@ struct bfin_mii_bus_platform_data {
const unsigned short *mac_peripherals;
int phy_mode;
unsigned int phy_mask;
+ unsigned short vlan1_mask, vlan2_mask;
};
#endif
--
1.7.4.rc1
^ permalink raw reply related
* [PATCH 5/5] netdev: bfin_mac: disable hardware checksum if writeback cache is enabled
From: Mike Frysinger @ 2011-01-10 12:54 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: uclinux-dist-devel, Sonic Zhang
In-Reply-To: <1294664073-1950-1-git-send-email-vapier@gentoo.org>
From: Sonic Zhang <sonic.zhang@analog.com>
With writeback caches, corrupted RX packets will be sent up the stack
without any error markings.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
drivers/net/bfin_mac.h | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/net/bfin_mac.h b/drivers/net/bfin_mac.h
index c1a0d66..f8559ac 100644
--- a/drivers/net/bfin_mac.h
+++ b/drivers/net/bfin_mac.h
@@ -17,7 +17,14 @@
#include <linux/etherdevice.h>
#include <linux/bfin_mac.h>
+/*
+ * Disable hardware checksum for bug #5600 if writeback cache is
+ * enabled. Otherwize, corrupted RX packet will be sent up stack
+ * without error mark.
+ */
+#ifndef CONFIG_BFIN_EXTMEM_WRITEBACK
#define BFIN_MAC_CSUM_OFFLOAD
+#endif
#define TX_RECLAIM_JIFFIES (HZ / 5)
--
1.7.4.rc1
^ permalink raw reply related
* [PATCH 1/5] netdev: bfin_mac: clean up printk messages
From: Mike Frysinger @ 2011-01-10 12:54 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller
Cc: uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
Use netdev_* and pr_* helper funcs for output rather than printk.
Signed-off-by: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
---
drivers/net/bfin_mac.c | 65 +++++++++++++++++++++--------------------------
1 files changed, 29 insertions(+), 36 deletions(-)
diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c
index ce1e5e9..a572bcb 100644
--- a/drivers/net/bfin_mac.c
+++ b/drivers/net/bfin_mac.c
@@ -8,6 +8,11 @@
* Licensed under the GPL-2 or later.
*/
+#define DRV_VERSION "1.1"
+#define DRV_DESC "Blackfin on-chip Ethernet MAC driver"
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
@@ -41,12 +46,7 @@
#include "bfin_mac.h"
-#define DRV_NAME "bfin_mac"
-#define DRV_VERSION "1.1"
-#define DRV_AUTHOR "Bryan Wu, Luke Yang"
-#define DRV_DESC "Blackfin on-chip Ethernet MAC driver"
-
-MODULE_AUTHOR(DRV_AUTHOR);
+MODULE_AUTHOR("Bryan Wu, Luke Yang");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION(DRV_DESC);
MODULE_ALIAS("platform:bfin_mac");
@@ -189,8 +189,7 @@ static int desc_list_init(void)
/* allocate a new skb for next time receive */
new_skb = dev_alloc_skb(PKT_BUF_SZ + NET_IP_ALIGN);
if (!new_skb) {
- printk(KERN_NOTICE DRV_NAME
- ": init: low on mem - packet dropped\n");
+ pr_notice("init: low on mem - packet dropped\n");
goto init_error;
}
skb_reserve(new_skb, NET_IP_ALIGN);
@@ -240,7 +239,7 @@ static int desc_list_init(void)
init_error:
desc_list_free();
- printk(KERN_ERR DRV_NAME ": kmalloc failed\n");
+ pr_err("kmalloc failed\n");
return -ENOMEM;
}
@@ -259,8 +258,7 @@ static int bfin_mdio_poll(void)
while ((bfin_read_EMAC_STAADD()) & STABUSY) {
udelay(1);
if (timeout_cnt-- < 0) {
- printk(KERN_ERR DRV_NAME
- ": wait MDC/MDIO transaction to complete timeout\n");
+ pr_err("wait MDC/MDIO transaction to complete timeout\n");
return -ETIMEDOUT;
}
}
@@ -350,9 +348,9 @@ static void bfin_mac_adjust_link(struct net_device *dev)
opmode &= ~RMII_10;
break;
default:
- printk(KERN_WARNING
- "%s: Ack! Speed (%d) is not 10/100!\n",
- DRV_NAME, phydev->speed);
+ netdev_warn(dev,
+ "Ack! Speed (%d) is not 10/100!\n",
+ phydev->speed);
break;
}
bfin_write_EMAC_OPMODE(opmode);
@@ -417,14 +415,13 @@ static int mii_probe(struct net_device *dev, int phy_mode)
/* now we are supposed to have a proper phydev, to attach to... */
if (!phydev) {
- printk(KERN_INFO "%s: Don't found any phy device at all\n",
- dev->name);
+ netdev_err(dev, "no phy device found\n");
return -ENODEV;
}
if (phy_mode != PHY_INTERFACE_MODE_RMII &&
phy_mode != PHY_INTERFACE_MODE_MII) {
- printk(KERN_INFO "%s: Invalid phy interface mode\n", dev->name);
+ netdev_err(dev, "invalid phy interface mode\n");
return -EINVAL;
}
@@ -432,7 +429,7 @@ static int mii_probe(struct net_device *dev, int phy_mode)
0, phy_mode);
if (IS_ERR(phydev)) {
- printk(KERN_ERR "%s: Could not attach to PHY\n", dev->name);
+ netdev_err(dev, "could not attach PHY\n");
return PTR_ERR(phydev);
}
@@ -453,11 +450,10 @@ static int mii_probe(struct net_device *dev, int phy_mode)
lp->old_duplex = -1;
lp->phydev = phydev;
- printk(KERN_INFO "%s: attached PHY driver [%s] "
- "(mii_bus:phy_addr=%s, irq=%d, mdc_clk=%dHz(mdc_div=%d)"
- "@sclk=%dMHz)\n",
- DRV_NAME, phydev->drv->name, dev_name(&phydev->dev), phydev->irq,
- MDC_CLK, mdc_div, sclk/1000000);
+ pr_info("attached PHY driver [%s] "
+ "(mii_bus:phy_addr=%s, irq=%d, mdc_clk=%dHz(mdc_div=%d)@sclk=%dMHz)\n",
+ phydev->drv->name, dev_name(&phydev->dev), phydev->irq,
+ MDC_CLK, mdc_div, sclk/1000000);
return 0;
}
@@ -502,7 +498,7 @@ bfin_mac_ethtool_setsettings(struct net_device *dev, struct ethtool_cmd *cmd)
static void bfin_mac_ethtool_getdrvinfo(struct net_device *dev,
struct ethtool_drvinfo *info)
{
- strcpy(info->driver, DRV_NAME);
+ strcpy(info->driver, KBUILD_MODNAME);
strcpy(info->version, DRV_VERSION);
strcpy(info->fw_version, "N/A");
strcpy(info->bus_info, dev_name(&dev->dev));
@@ -827,8 +823,7 @@ static void bfin_tx_hwtstamp(struct net_device *netdev, struct sk_buff *skb)
while ((!(bfin_read_EMAC_PTP_ISTAT() & TXTL)) && (--timeout_cnt))
udelay(1);
if (timeout_cnt == 0)
- printk(KERN_ERR DRV_NAME
- ": fails to timestamp the TX packet\n");
+ netdev_err(netdev, "timestamp the TX packet failed\n");
else {
struct skb_shared_hwtstamps shhwtstamps;
u64 ns;
@@ -1083,8 +1078,7 @@ static void bfin_mac_rx(struct net_device *dev)
* we which case we simply drop the packet
*/
if (current_rx_ptr->status.status_word & RX_ERROR_MASK) {
- printk(KERN_NOTICE DRV_NAME
- ": rx: receive error - packet dropped\n");
+ netdev_notice(dev, "rx: receive error - packet dropped\n");
dev->stats.rx_dropped++;
goto out;
}
@@ -1094,8 +1088,7 @@ static void bfin_mac_rx(struct net_device *dev)
new_skb = dev_alloc_skb(PKT_BUF_SZ + NET_IP_ALIGN);
if (!new_skb) {
- printk(KERN_NOTICE DRV_NAME
- ": rx: low on mem - packet dropped\n");
+ netdev_notice(dev, "rx: low on mem - packet dropped\n");
dev->stats.rx_dropped++;
goto out;
}
@@ -1213,7 +1206,7 @@ static int bfin_mac_enable(struct phy_device *phydev)
int ret;
u32 opmode;
- pr_debug("%s: %s\n", DRV_NAME, __func__);
+ pr_debug("%s\n", __func__);
/* Set RX DMA */
bfin_write_DMA1_NEXT_DESC_PTR(&(rx_list_head->desc_a));
@@ -1323,7 +1316,7 @@ static void bfin_mac_set_multicast_list(struct net_device *dev)
u32 sysctl;
if (dev->flags & IFF_PROMISC) {
- printk(KERN_INFO "%s: set to promisc mode\n", dev->name);
+ netdev_info(dev, "set promisc mode\n");
sysctl = bfin_read_EMAC_OPMODE();
sysctl |= PR;
bfin_write_EMAC_OPMODE(sysctl);
@@ -1393,7 +1386,7 @@ static int bfin_mac_open(struct net_device *dev)
* address using ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx
*/
if (!is_valid_ether_addr(dev->dev_addr)) {
- printk(KERN_WARNING DRV_NAME ": no valid ethernet hw addr\n");
+ netdev_warn(dev, "no valid ethernet hw addr\n");
return -EINVAL;
}
@@ -1558,7 +1551,7 @@ static int __devinit bfin_mac_probe(struct platform_device *pdev)
bfin_mac_hwtstamp_init(ndev);
/* now, print out the card info, in a short format.. */
- dev_info(&pdev->dev, "%s, Version %s\n", DRV_DESC, DRV_VERSION);
+ netdev_info(ndev, "%s, Version %s\n", DRV_DESC, DRV_VERSION);
return 0;
@@ -1650,7 +1643,7 @@ static int __devinit bfin_mii_bus_probe(struct platform_device *pdev)
* so set the GPIO pins to Ethernet mode
*/
pin_req = mii_bus_pd->mac_peripherals;
- rc = peripheral_request_list(pin_req, DRV_NAME);
+ rc = peripheral_request_list(pin_req, KBUILD_MODNAME);
if (rc) {
dev_err(&pdev->dev, "Requesting peripherals failed!\n");
return rc;
@@ -1739,7 +1732,7 @@ static struct platform_driver bfin_mac_driver = {
.resume = bfin_mac_resume,
.suspend = bfin_mac_suspend,
.driver = {
- .name = DRV_NAME,
+ .name = KBUILD_MODNAME,
.owner = THIS_MODULE,
},
};
--
1.7.4.rc1
^ permalink raw reply related
* Re: [PATCH 3/3] netlink: support setting devgroup parameters
From: jamal @ 2011-01-10 13:14 UTC (permalink / raw)
To: Vlad Dogaru; +Cc: netdev, Octavian Purdila
In-Reply-To: <1294659524-22509-4-git-send-email-ddvlad@rosedu.org>
Nice - short and sweet.
IMO: I dont think you need this new attribute, IFLA_GROUP
should suffice...
You can use the trick that if a <=0 ifindex is specified,
and no name is passed but a GROUP is passed, then we
operate on the group i.e something like:
if (ifm->ifi_index > 0)
dev = __dev_get_by_index(net, ifm->ifi_index);
else {
if (tb[IFLA_IFNAME])
dev = __dev_get_by_name(net, ifname);
else if (tb[IFLA_GROUP])
new/get/set/del specific stuff..
else
return -EINVAL;
}
cheers,
jamal
On Mon, 2011-01-10 at 13:38 +0200, Vlad Dogaru wrote:
> Add a new type of message, IFLA_FILTERGROUP, which, if present in a
> userspace request, specifies that parameters should be changed for all
> devices in the group.
>
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 1/2] can: add driver for Softing card
From: Kurt Van Dijck @ 2011-01-10 13:31 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D24DB2C.9040104-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Wolfgang,
A few thoughts ...
On Wed, Jan 05, 2011 at 09:57:16PM +0100, Wolfgang Grandegger wrote:
> >
> > obj-y += usb/
> > +obj-y += softing/
>
> Please use "obj-$(CONFIG_CAN_SOFTING)" here.
As I explained, softing does not depend on softing_cs or vice versa,
which makes "obj-$(CONFIG_CAN_SOFTING)" not right.
> > + if (type != 0xffff) {
> > + dev_alert(&card->pdev->dev, "firware starts with type 0x%04x\n",
>
> Typo?
>
??
> > +
> > +int softing_default_output(struct net_device *netdev)
> > +{
> > + struct softing_priv *priv = netdev_priv(netdev);
> > + struct softing *card = priv->card;
> > +
> > + switch (priv->chip) {
> > + case 1000:
> > + if (card->pdat->generation < 2)
> > + return 0xfb;
> > + return 0xfa;
> > + case 5:
> > + return 0x60;
> > + default:
> > + return 0x40;
> > + }
> > +}
>
> Again, some magic constants.
The thing is, I didn't create those number, nor do I precisely know
which are the right ones, or how I would name those.
Since they're used one, I tought this would work.
>
> > + ret = netif_rx(skb);
> > + if (ret == NET_RX_DROP)
> > + ++netdev->stats.rx_dropped;
>
> Hm, I wonder if all Socket-CAN drivers should handle the return value of
> netif_rx that way?
>
No, they should not.
After a seconds look, I'm a tiny little bit wrong here.
I should only increment rx_dropped when it's a real received message,
and not a virtual constructed one (bus crtls).
I moved this thing to the rx data handler.
Maybe, a common CAN rx function is usefull to properly deal with
the can_echo_skb & friends.
>
> > + priv->can.ctrlmode_supported =
> > + CAN_CTRLMODE_3_SAMPLES;/* | CAN_CTRLMODE_BERR_REPORTING */;
>
> Hm, any chance to support CAN_CTRLMODE_BERR_REPORTING? If not, please
> remove the comment.
I think I better try to write it properly without, and add error reporting
later, after serious testing of the error reporting on a softing card.
The primary goal now is get this driver in mainline kernel since PCMCIA
has been changing recently, and I found it hard to keep up. So, first things
first ...
Kurt
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 1/2] can: add driver for Softing card
From: Wolfram Sang @ 2011-01-10 13:40 UTC (permalink / raw)
To: Kurt Van Dijck
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, Wolfgang Grandegger
In-Reply-To: <20110110133112.GA324-MxZ6Iy/zr/UdbCeoMzGj59i2O/JbrIOy@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 770 bytes --]
> > > + if (type != 0xffff) {
> > > + dev_alert(&card->pdev->dev, "firware starts with type 0x%04x\n",
> >
> > Typo?
> >
> ??
I think he means "fir[m]ware"
> > > +
> > > +int softing_default_output(struct net_device *netdev)
> > > +{
> > > + struct softing_priv *priv = netdev_priv(netdev);
> > > + struct softing *card = priv->card;
> > > +
> > > + switch (priv->chip) {
> > > + case 1000:
> > > + if (card->pdat->generation < 2)
> > > + return 0xfb;
> > > + return 0xfa;
A ternary operator might look nicer here because of just a single return.
Best wishes,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH 0/3] net: add device groups
From: Johannes Berg @ 2011-01-10 13:41 UTC (permalink / raw)
To: Vlad Dogaru; +Cc: jamal, Octavian Purdila, netdev
In-Reply-To: <1294659524-22509-1-git-send-email-ddvlad@rosedu.org>
On Mon, 2011-01-10 at 13:38 +0200, Vlad Dogaru wrote:
> This patchset implements network device grouping and simple manipulation
> of groups. Netlink has been update to provide group information and
> means of applying changes to members of a specific group via a single
> message.
Can you explain the purpose of this? I'm wondering if it would make
sense to automatically group all virtual interfaces belonging to a
single 802.11 device, for instance.
johannes
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 1/2] can: add driver for Softing card
From: Kurt Van Dijck @ 2011-01-10 13:44 UTC (permalink / raw)
To: Wolfram Sang
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, Wolfgang Grandegger
In-Reply-To: <20110110134006.GC31011-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Mon, Jan 10, 2011 at 02:40:06PM +0100, Wolfram Sang wrote:
> > > > + if (type != 0xffff) {
> > > > + dev_alert(&card->pdev->dev, "firware starts with type 0x%04x\n",
> > >
> > > Typo?
> > >
> > ??
>
> I think he means "fir[m]ware"
>
Thanks. Can't imagine anymore how I couldn't see it.
Kurt
^ permalink raw reply
* Re: [RFC] sched: CHOKe packet scheduler (v0.2)
From: Eric Dumazet @ 2011-01-10 13:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20110106205549.0de56de1@nehalam>
Le jeudi 06 janvier 2011 à 20:55 -0800, Stephen Hemminger a écrit :
>
> The problem is that large tables of pointers in kernel require either
> contiguous allocation or some indirect table algorithm.
>
Here is a v3 version with an array based queue for O(1) peek_random
complexity.
Could you send the iproute2 patch so that I can test it ?
Thanks !
diff --git a/net/sched/sch_choke.c b/net/sched/sch_choke.c
index e69de29..ea9db00 100644
--- a/net/sched/sch_choke.c
+++ b/net/sched/sch_choke.c
@@ -0,0 +1,388 @@
+/*
+ * net/sched/sch_choke.c CHOKE scheduler
+ *
+ * Copyright (c) 2011 Stephen Hemminger <shemminger@vyatta.com>
+ * Copyright (c) 2011 Eric Dumazet <eric.dumazet@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/skbuff.h>
+#include <linux/reciprocal_div.h>
+#include <net/pkt_sched.h>
+#include <net/inet_ecn.h>
+#include <net/red.h>
+
+/* CHOKe stateless AQM for fair bandwidth allocation
+ =================================================
+
+ CHOKe (CHOose and Keep for responsive flows, CHOose and Kill for
+ unresponsive flows) is a variant of RED that penalizes misbehaving flows but
+ maintains no flow state. The difference from RED is an additional step
+ during the enqueuing process. If average queue size is over the
+ low threshold (qmin), a packet is chosen at random from the queue.
+ If both the new and chosen packet are from the same flow, both
+ are dropped. Unlike RED, CHOKe is not a "classful" qdisc because it
+ needs to access packets in queue randomly.
+
+ Source:
+ R. Pan, B. Prabhakar, and K. Psounis, "CHOKe, A Stateless
+ Active Queue Management Scheme for Approximating Fair Bandwidth Allocation",
+ IEEE INFOCOM, 2000.
+
+ A. Tang, J. Wang, S. Low, "Understanding CHOKe: Throughput and Spatial
+ Characteristics", IEEE/ACM Transactions on Networking, 2004
+
+ */
+
+struct choke_sched_data {
+ u32 limit;
+ unsigned char flags;
+
+ struct red_parms parms;
+ struct red_stats stats;
+
+ unsigned int head;
+ unsigned int tail;
+ unsigned int holes;
+ unsigned int tab_mask; /* size - 1 */
+ struct sk_buff **tab;
+};
+
+static inline unsigned int choke_len(const struct choke_sched_data *q)
+{
+ return (q->tail - q->head) & q->tab_mask;
+}
+
+/* deliver a random number between 0 and N - 1 */
+static inline u32 random_N(unsigned int N)
+{
+ return reciprocal_divide(random32(), N);
+}
+
+/* Select a packet at random from the queue in O(1) */
+static struct sk_buff *choke_peek_random(struct choke_sched_data *q, unsigned int *pidx)
+{
+ *pidx = (q->head + random_N(choke_len(q))) & q->tab_mask;
+ return q->tab[*pidx];
+}
+
+
+static inline int use_ecn(const struct choke_sched_data *q)
+{
+ return q->flags & TC_RED_ECN;
+}
+
+static inline int use_harddrop(const struct choke_sched_data *q)
+{
+ return q->flags & TC_RED_HARDDROP;
+}
+
+static inline void choke_zap_head_holes(struct choke_sched_data *q)
+{
+ while (q->holes && q->tab[q->head] == NULL) {
+ q->head = (q->head + 1) & q->tab_mask;
+ q->holes--;
+ }
+}
+
+static inline void choke_zap_tail_holes(struct choke_sched_data *q)
+{
+ while (q->holes && q->tab[q->tail - 1] == NULL) {
+ q->tail = (q->tail - 1) & q->tab_mask;
+ q->holes--;
+ }
+}
+
+static void choke_drop_by_idx(struct choke_sched_data *q, unsigned int idx)
+{
+ q->tab[idx] = NULL;
+ q->holes++;
+ choke_zap_head_holes(q);
+ choke_zap_tail_holes(q);
+}
+
+
+static int choke_enqueue(struct sk_buff *skb, struct Qdisc *sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct red_parms *p = &q->parms;
+
+ p->qavg = red_calc_qavg(p, choke_len(q) - q->holes);
+ if (red_is_idling(p))
+ red_end_of_idle_period(p);
+
+ if (p->qavg <= p->qth_min)
+ p->qcount = -1;
+ else {
+ struct sk_buff *oskb;
+ unsigned int idx;
+
+ /* Draw a packet at random from queue */
+ oskb = choke_peek_random(q, &idx);
+
+ /* Both packets from same flow ? */
+ if (oskb && skb_get_rxhash(oskb) == skb_get_rxhash(skb)) {
+ /* Drop both packets */
+ choke_drop_by_idx(q, idx);
+ qdisc_drop(oskb, sch);
+ goto congestion_drop;
+ }
+
+ if (p->qavg > p->qth_max) {
+ p->qcount = -1;
+
+ sch->qstats.overlimits++;
+ if (use_harddrop(q) || !use_ecn(q) ||
+ !INET_ECN_set_ce(skb)) {
+ q->stats.forced_drop++;
+ goto congestion_drop;
+ }
+
+ q->stats.forced_mark++;
+ }
+
+ if (++p->qcount) {
+ if (red_mark_probability(p, p->qavg)) {
+ p->qcount = 0;
+ p->qR = red_random(p);
+
+ sch->qstats.overlimits++;
+ if (!use_ecn(q) || !INET_ECN_set_ce(skb)) {
+ q->stats.prob_drop++;
+ goto congestion_drop;
+ }
+
+ q->stats.prob_mark++;
+ }
+ } else
+ p->qR = red_random(p);
+ }
+
+ /* Admit new packet */
+ if (likely(choke_len(q) < q->limit)) {
+ q->tab[q->tail] = skb;
+ q->tail = (q->tail + 1) & q->tab_mask;
+ sch->qstats.backlog += qdisc_pkt_len(skb);
+ __qdisc_update_bstats(sch, qdisc_pkt_len(skb));
+ return NET_XMIT_SUCCESS;
+ }
+ q->stats.pdrop++;
+ sch->qstats.drops++;
+ kfree_skb(skb);
+ return NET_XMIT_DROP;
+
+ congestion_drop:
+ qdisc_drop(skb, sch);
+ return NET_XMIT_CN;
+}
+
+static struct sk_buff *choke_dequeue(struct Qdisc *sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct sk_buff *skb;
+
+ if (q->head == q->tail) {
+ if (!red_is_idling(&q->parms))
+ red_start_of_idle_period(&q->parms);
+ return NULL;
+ }
+ skb = q->tab[q->head];
+ q->tab[q->head] = NULL; /* not really needed */
+ q->head = (q->head + 1) & q->tab_mask;
+ choke_zap_head_holes(q);
+ sch->qstats.backlog -= qdisc_pkt_len(skb);
+
+ return skb;
+}
+
+static unsigned int choke_drop(struct Qdisc *sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ unsigned int len;
+
+ len = qdisc_queue_drop(sch);
+
+ if (len > 0)
+ q->stats.other++;
+ else {
+ if (!red_is_idling(&q->parms))
+ red_start_of_idle_period(&q->parms);
+ }
+
+ return len;
+}
+
+static void choke_reset(struct Qdisc* sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+
+ red_restart(&q->parms);
+}
+
+static const struct nla_policy choke_policy[TCA_RED_MAX + 1] = {
+ [TCA_RED_PARMS] = { .len = sizeof(struct tc_red_qopt) },
+ [TCA_RED_STAB] = { .len = RED_STAB_SIZE },
+};
+
+
+static void choke_free(void *addr)
+{
+ if (addr) {
+ if (is_vmalloc_addr(addr))
+ vfree(addr);
+ else
+ kfree(addr);
+ }
+}
+
+static int choke_change(struct Qdisc *sch, struct nlattr *opt)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct nlattr *tb[TCA_RED_MAX + 1];
+ struct tc_red_qopt *ctl;
+ int err;
+ struct sk_buff **old = NULL;
+ unsigned int mask;
+
+ if (opt == NULL)
+ return -EINVAL;
+
+ err = nla_parse_nested(tb, TCA_RED_MAX, opt, choke_policy);
+ if (err < 0)
+ return err;
+
+ if (tb[TCA_RED_PARMS] == NULL ||
+ tb[TCA_RED_STAB] == NULL)
+ return -EINVAL;
+
+ ctl = nla_data(tb[TCA_RED_PARMS]);
+
+ mask = roundup_pow_of_two(ctl->limit + 1) - 1;
+ if (mask != q->tab_mask) {
+ struct sk_buff **ntab = kcalloc(mask + 1, sizeof(struct sk_buff *),
+ GFP_KERNEL);
+ if (!ntab)
+ ntab = vzalloc((mask + 1) * sizeof(struct sk_buff *));
+ if (!ntab)
+ return -ENOMEM;
+ sch_tree_lock(sch);
+ old = q->tab;
+ if (old) {
+ unsigned int tail = 0;
+
+ while (q->head != q->tail) {
+ ntab[tail++] = q->tab[q->head];
+ q->head = (q->head + 1) & q->tab_mask;
+ }
+ q->head = 0;
+ q->tail = tail;
+ }
+ q->tab_mask = mask;
+ q->holes = 0;
+ } else
+ sch_tree_lock(sch);
+ q->flags = ctl->flags;
+ q->limit = ctl->limit;
+
+ red_set_parms(&q->parms, ctl->qth_min, ctl->qth_max, ctl->Wlog,
+ ctl->Plog, ctl->Scell_log,
+ nla_data(tb[TCA_RED_STAB]));
+
+ if (q->head == q->tail)
+ red_end_of_idle_period(&q->parms);
+
+ sch_tree_unlock(sch);
+ choke_free(old);
+ return 0;
+}
+
+static int choke_init(struct Qdisc* sch, struct nlattr *opt)
+{
+ return choke_change(sch, opt);
+}
+
+static int choke_dump(struct Qdisc *sch, struct sk_buff *skb)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct nlattr *opts = NULL;
+ struct tc_red_qopt opt = {
+ .limit = q->limit,
+ .flags = q->flags,
+ .qth_min = q->parms.qth_min >> q->parms.Wlog,
+ .qth_max = q->parms.qth_max >> q->parms.Wlog,
+ .Wlog = q->parms.Wlog,
+ .Plog = q->parms.Plog,
+ .Scell_log = q->parms.Scell_log,
+ };
+
+ sch->q.qlen = choke_len(q) - q->holes;
+ opts = nla_nest_start(skb, TCA_OPTIONS);
+ if (opts == NULL)
+ goto nla_put_failure;
+
+ NLA_PUT(skb, TCA_RED_PARMS, sizeof(opt), &opt);
+ return nla_nest_end(skb, opts);
+
+nla_put_failure:
+ nla_nest_cancel(skb, opts);
+ return -EMSGSIZE;
+}
+
+static int choke_dump_stats(struct Qdisc *sch, struct gnet_dump *d)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct tc_red_xstats st = {
+ .early = q->stats.prob_drop + q->stats.forced_drop,
+ .pdrop = q->stats.pdrop,
+ .other = q->stats.other,
+ .marked = q->stats.prob_mark + q->stats.forced_mark,
+ };
+
+ return gnet_stats_copy_app(d, &st, sizeof(st));
+}
+
+static void choke_destroy(struct Qdisc *sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+
+ choke_free(q->tab);
+}
+
+static struct Qdisc_ops choke_qdisc_ops __read_mostly = {
+ .id = "choke",
+ .priv_size = sizeof(struct choke_sched_data),
+
+ .enqueue = choke_enqueue,
+ .dequeue = choke_dequeue,
+ .peek = qdisc_peek_head,
+ .drop = choke_drop,
+ .init = choke_init,
+ .destroy = choke_destroy,
+ .reset = choke_reset,
+ .change = choke_change,
+ .dump = choke_dump,
+ .dump_stats = choke_dump_stats,
+ .owner = THIS_MODULE,
+};
+
+static int __init choke_module_init(void)
+{
+ return register_qdisc(&choke_qdisc_ops);
+}
+
+static void __exit choke_module_exit(void)
+{
+ unregister_qdisc(&choke_qdisc_ops);
+}
+
+module_init(choke_module_init)
+module_exit(choke_module_exit)
+
+MODULE_LICENSE("GPL");
^ permalink raw reply related
* Re: [PATCH 0/3] net: add device groups
From: jamal @ 2011-01-10 14:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: Vlad Dogaru, Octavian Purdila, netdev
In-Reply-To: <1294666875.3583.6.camel@jlt3.sipsolutions.net>
On Mon, 2011-01-10 at 14:41 +0100, Johannes Berg wrote:
> Can you explain the purpose of this? I'm wondering if it would make
> sense to automatically group all virtual interfaces belonging to a
> single 802.11 device, for instance.
It depends what you want to do with that grouping.
In a nutshell, this greatly reduces the amount of kernel-user netlink
traffic in presence of multi interfaces.
you can do things like:
ip link set dev ppp0 group 1
...
...
ip link set dev pppN group 1
ip link ls group 1
ip link set down group 1
ip link set mtu 512 group 1
etc
Although now that i am thinking of it,
I am not sure whether it would be a legit thing to change
the MAC address of a group of devices - we may need to put
some restrictions.
Note: this grouping thing can also be potentially used in
packet policies etc (but i dont want to distract the simple
requirement we have at the moment).
cheers,
jamal
^ permalink raw reply
* Re: [patch] phonet: some signedness bugs
From: Dan Carpenter @ 2011-01-10 14:01 UTC (permalink / raw)
To: Rémi Denis-Courmont
Cc: David S. Miller, netdev, kernel-janitors, dan.j.rosenberg
In-Reply-To: <201101100958.32549.remi.denis-courmont@nokia.com>
On Mon, Jan 10, 2011 at 09:58:32AM +0200, Rémi Denis-Courmont wrote:
> On Friday 07 January 2011 22:37:55 ext Dan Carpenter, you wrote:
> > Dan Rosenberg pointed out that there were some signed comparison bugs
> > in the phonet protocol.
>
> There are two ways to solve this: change *only* the proto_get function to use
> an unsigned parameter, or cast the protocol to unsigned in the comparison.
>
> As David pointed out, your patch breaks the socket() callback prototype.
>
Yes. I really appologize for that. I'll send version 2 with that create()
change dropped. It's not needed.
I would like to keep the change to phonet_proto_register() because the
check in there isn't right and it's similar to phonet_proto_get(). We
may as well keep phonet_proto_unregister() as well so it's symmetric.
Let me know if you disagree and I'll redo it.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 1/2] can: add driver for Softing card
From: Wolfgang Grandegger @ 2011-01-10 14:05 UTC (permalink / raw)
To: Kurt Van Dijck; +Cc: socketcan-core, netdev
In-Reply-To: <20110110133112.GA324@e-circ.dyndns.org>
On 01/10/2011 02:31 PM, Kurt Van Dijck wrote:
> Wolfgang,
>
> A few thoughts ...
>
> On Wed, Jan 05, 2011 at 09:57:16PM +0100, Wolfgang Grandegger wrote:
>>>
>>> obj-y += usb/
>>> +obj-y += softing/
>>
>> Please use "obj-$(CONFIG_CAN_SOFTING)" here.
> As I explained, softing does not depend on softing_cs or vice versa,
> which makes "obj-$(CONFIG_CAN_SOFTING)" not right.
OK, another good reason to make softing_cs depend on CONFIG_CAN_SOFTING.
Does it make sense to compile softing_cs without CONFIG_CAN_SOFTING for
the *real* user?
...
>>> + priv->can.ctrlmode_supported =
>>> + CAN_CTRLMODE_3_SAMPLES;/* | CAN_CTRLMODE_BERR_REPORTING */;
>>
>> Hm, any chance to support CAN_CTRLMODE_BERR_REPORTING? If not, please
>> remove the comment.
>
> I think I better try to write it properly without, and add error reporting
> later, after serious testing of the error reporting on a softing card.
OK, then just cleanup properly.
> The primary goal now is get this driver in mainline kernel since PCMCIA
> has been changing recently, and I found it hard to keep up. So, first things
> first ...
Fine for me. You can then add my:
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Thanks.
Wolfgang.
^ permalink raw reply
* [patch v2] phonet: some signedness bugs
From: Dan Carpenter @ 2011-01-10 14:06 UTC (permalink / raw)
To: Rémi Denis-Courmont
Cc: David S. Miller, netdev, kernel-janitors, dan.j.rosenberg
In-Reply-To: <201101100958.32549.remi.denis-courmont@nokia.com>
Dan Rosenberg pointed out that there were some signed comparison bugs
in the phonet protocol.
http://marc.info/?l=full-disclosure&m=129424528425330&w=2
The problem is that we check for array overflows but "protocol" is
signed and we don't check for array underflows. If you have already
have CAP_SYS_ADMIN then you could use the bugs to get root, or someone
could cause an oops by mistake.
Signed-off-by: Dan Carpenter <error27@gmail.com>
---
v2: in v1 I changed pn_socket_create() but that change caused a
compiler warning. That part of the patch wasn't needed so I've just
dropped.
diff --git a/include/net/phonet/phonet.h b/include/net/phonet/phonet.h
index d5df797..5395e09 100644
--- a/include/net/phonet/phonet.h
+++ b/include/net/phonet/phonet.h
@@ -107,8 +107,8 @@ struct phonet_protocol {
int sock_type;
};
-int phonet_proto_register(int protocol, struct phonet_protocol *pp);
-void phonet_proto_unregister(int protocol, struct phonet_protocol *pp);
+int phonet_proto_register(unsigned int protocol, struct phonet_protocol *pp);
+void phonet_proto_unregister(unsigned int protocol, struct phonet_protocol *pp);
int phonet_sysctl_init(void);
void phonet_sysctl_exit(void);
diff --git a/net/phonet/af_phonet.c b/net/phonet/af_phonet.c
index fd95beb..1072b2c 100644
--- a/net/phonet/af_phonet.c
+++ b/net/phonet/af_phonet.c
@@ -37,7 +37,7 @@
/* Transport protocol registration */
static struct phonet_protocol *proto_tab[PHONET_NPROTO] __read_mostly;
-static struct phonet_protocol *phonet_proto_get(int protocol)
+static struct phonet_protocol *phonet_proto_get(unsigned int protocol)
{
struct phonet_protocol *pp;
@@ -458,7 +458,7 @@ static struct packet_type phonet_packet_type __read_mostly = {
static DEFINE_MUTEX(proto_tab_lock);
-int __init_or_module phonet_proto_register(int protocol,
+int __init_or_module phonet_proto_register(unsigned int protocol,
struct phonet_protocol *pp)
{
int err = 0;
@@ -481,7 +481,7 @@ int __init_or_module phonet_proto_register(int protocol,
}
EXPORT_SYMBOL(phonet_proto_register);
-void phonet_proto_unregister(int protocol, struct phonet_protocol *pp)
+void phonet_proto_unregister(unsigned int protocol, struct phonet_protocol *pp)
{
mutex_lock(&proto_tab_lock);
BUG_ON(proto_tab[protocol] != pp);
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v2 1/2] can: add driver for Softing card
From: Wolfgang Grandegger @ 2011-01-10 14:07 UTC (permalink / raw)
To: Kurt Van Dijck
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D2B1245.9060303-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On 01/10/2011 03:05 PM, Wolfgang Grandegger wrote:
> On 01/10/2011 02:31 PM, Kurt Van Dijck wrote:
>> Wolfgang,
>>
>> A few thoughts ...
>>
>> On Wed, Jan 05, 2011 at 09:57:16PM +0100, Wolfgang Grandegger wrote:
>>>>
>>>> obj-y += usb/
>>>> +obj-y += softing/
>>>
>>> Please use "obj-$(CONFIG_CAN_SOFTING)" here.
>> As I explained, softing does not depend on softing_cs or vice versa,
>> which makes "obj-$(CONFIG_CAN_SOFTING)" not right.
>
> OK, another good reason to make softing_cs depend on CONFIG_CAN_SOFTING.
> Does it make sense to compile softing_cs without CONFIG_CAN_SOFTING for
> the *real* user?
>
> ...
>
>>>> + priv->can.ctrlmode_supported =
>>>> + CAN_CTRLMODE_3_SAMPLES;/* | CAN_CTRLMODE_BERR_REPORTING */;
>>>
>>> Hm, any chance to support CAN_CTRLMODE_BERR_REPORTING? If not, please
>>> remove the comment.
>>
>> I think I better try to write it properly without, and add error reporting
>> later, after serious testing of the error reporting on a softing card.
>
> OK, then just cleanup properly.
>
>> The primary goal now is get this driver in mainline kernel since PCMCIA
>> has been changing recently, and I found it hard to keep up. So, first things
>> first ...
>
> Fine for me. You can then add my:
>
> Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Is there a mailing list for the PCMCIA interface? If yes, please add it
to the CC as well.
Wolfgang.
^ permalink raw reply
* Re: [PATCH 0/3] net: add device groups
From: Johannes Berg @ 2011-01-10 14:08 UTC (permalink / raw)
To: hadi; +Cc: Vlad Dogaru, Octavian Purdila, netdev
In-Reply-To: <1294668021.6063.315.camel@mojatatu>
On Mon, 2011-01-10 at 09:00 -0500, jamal wrote:
> On Mon, 2011-01-10 at 14:41 +0100, Johannes Berg wrote:
>
> > Can you explain the purpose of this? I'm wondering if it would make
> > sense to automatically group all virtual interfaces belonging to a
> > single 802.11 device, for instance.
>
> It depends what you want to do with that grouping.
> In a nutshell, this greatly reduces the amount of kernel-user netlink
> traffic in presence of multi interfaces.
> you can do things like:
>
> ip link set dev ppp0 group 1
> ...
> ...
> ip link set dev pppN group 1
>
> ip link ls group 1
> ip link set down group 1
> ip link set mtu 512 group 1
> etc
Right, but where would you want to use it -- what's the use case right
now? Your ppp example here makes me think the use case is some PPP
endpoint server that has lots of these interfaces. It also means the
grouping is entirely user-space controlled. In this case, the idea of
automatically grouping based on the device structure seems pointless.
johannes
^ permalink raw reply
* Re: [patch] phonet: some signedness bugs
From: Rémi Denis-Courmont @ 2011-01-10 14:08 UTC (permalink / raw)
To: ext Dan Carpenter
Cc: David S. Miller, netdev, kernel-janitors, dan.j.rosenberg
In-Reply-To: <20110110140141.GA2721@bicker>
On Monday 10 January 2011 16:01:41 ext Dan Carpenter, you wrote:
> I would like to keep the change to phonet_proto_register() because the
> check in there isn't right and it's similar to phonet_proto_get(). We
> may as well keep phonet_proto_unregister() as well so it's symmetric.
> Let me know if you disagree and I'll redo it.
Sounds sensible to me.
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
^ permalink raw reply
* Re: [patch v2] phonet: some signedness bugs
From: Rémi Denis-Courmont @ 2011-01-10 14:12 UTC (permalink / raw)
To: ext Dan Carpenter; +Cc: netdev, kernel-janitors, dan.j.rosenberg
In-Reply-To: <20110110140658.GB2721@bicker>
On Monday 10 January 2011 16:06:58 ext Dan Carpenter, you wrote:
> Dan Rosenberg pointed out that there were some signed comparison bugs
> in the phonet protocol.
>
> http://marc.info/?l=full-disclosure&m=129424528425330&w=2
>
> The problem is that we check for array overflows but "protocol" is
> signed and we don't check for array underflows. If you have already
> have CAP_SYS_ADMIN then you could use the bugs to get root, or someone
> could cause an oops by mistake.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
^ permalink raw reply
* Re: [PATCH 0/3] net: add device groups
From: jamal @ 2011-01-10 14:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: Vlad Dogaru, Octavian Purdila, netdev
In-Reply-To: <1294668505.3583.9.camel@jlt3.sipsolutions.net>
On Mon, 2011-01-10 at 15:08 +0100, Johannes Berg wrote:
>
> Right, but where would you want to use it -- what's the use case right
> now? Your ppp example here makes me think the use case is some PPP
> endpoint server that has lots of these interfaces.
That was just an example because someone mentioned PPP earlier.
Originally, this came from someone (Octavian?) trying to setup
a gazillion netdevs for testing purposes and then needing to
do "ip link ls dummy*" which causes a gazillion messages between
kernel and user space and all the filtering of what dummy* being
done in user space.
> It also means the
> grouping is entirely user-space controlled. In this case, the idea of
> automatically grouping based on the device structure seems pointless.
You still havent said what you want this grouping for. What is your
use case? ;->
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 0/3] net: add device groups
From: Johannes Berg @ 2011-01-10 14:38 UTC (permalink / raw)
To: hadi; +Cc: Vlad Dogaru, Octavian Purdila, netdev
In-Reply-To: <1294669450.6063.319.camel@mojatatu>
On Mon, 2011-01-10 at 09:24 -0500, jamal wrote:
> > It also means the
> > grouping is entirely user-space controlled. In this case, the idea of
> > automatically grouping based on the device structure seems pointless.
>
> You still havent said what you want this grouping for. What is your
> use case? ;->
I don't have a use case. I was just wondering if there's any benefit in
grouping virtual devices that belong to a single physical device, but I
suppose there isn't.
johannes
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 1/2] can: add driver for Softing card
From: Kurt Van Dijck @ 2011-01-10 14:40 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D2B1245.9060303-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Mon, Jan 10, 2011 at 03:05:57PM +0100, Wolfgang Grandegger wrote:
> On 01/10/2011 02:31 PM, Kurt Van Dijck wrote:
> > On Wed, Jan 05, 2011 at 09:57:16PM +0100, Wolfgang Grandegger wrote:
> OK, another good reason to make softing_cs depend on CONFIG_CAN_SOFTING.
> Does it make sense to compile softing_cs without CONFIG_CAN_SOFTING for
> the *real* user?
>
Good point.
I will add in Kconfig:
config CAN_SOFTING_CS
tristate "Softing CAN pcmcia cards"
depends on PCMCIA
+ select CAN_SOFTING
---help---
Thanks,
Kurt
^ 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