Re: [PATCH][IPSEC][5/7] inter address family ipsec tunnel
From: Kazunori MIYAZAWA <[EMAIL PROTECTED]> Date: Wed, 6 Dec 2006 20:35:40 +0900 > I fixed. As mentioned in another mail, I mixed up the changes > in my previous patch. This adds "IPv6 over IPv4 IPsec tunnel". > The fix of extra tab is included in another mail. > > Signed-off-by: Miika Komu <[EMAIL PROTECTED]> > Signed-off-by: Diego Beltrami <[EMAIL PROTECTED]> > Signed-off-by: Kazunori Miyazawa <[EMAIL PROTECTED]> I have queued this patch, we can look at it more carefully and integrate once the linkage issue in the other patch is resolved. Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][IPSEC][4/7] inter address family ipsec tunnel
From: David Miller <[EMAIL PROTECTED]> Date: Wed, 06 Dec 2006 23:37:49 -0800 (PST) > From: Kazunori MIYAZAWA <[EMAIL PROTECTED]> > Date: Wed, 6 Dec 2006 20:35:37 +0900 > > > BTW, I have a question about descrementing the reference count of > > rt->peer. The reference cound in normal "dst" structure is > > decremented by calling inet_putpeer from ipv4_dst_destroy. But > > xfrm4_dst_destroy does not call inet_putpeer. Where do we decrement > > the count? Should xfrm4_dst_destroy do that? > > Indeed, it is a real leak. And yes, I believe that xfrm4_dst_destroy() > should release it. I will make this fix, thank you. For reference, this is the fix I checked in. Thanks again for spotting this problem. I suppose your patch will need to add an address family check for this too. Actually... I think address family check is needed for 'idev' release in xfrm4_dst_destroy() too, if you agree please also add that fix to your patch. It is very complicated, using IPV6 route in xfrm4 code, because now all "X->u.rt" references need to be audited. commit 26db167702756d0022f8ea5f1f30cad3018cfe31 Author: David S. Miller <[EMAIL PROTECTED]> Date: Wed Dec 6 23:45:15 2006 -0800 [IPSEC]: Fix inetpeer leak in ipv4 xfrm dst entries. We grab a reference to the route's inetpeer entry but forget to release it in xfrm4_dst_destroy(). Bug discovered by Kazunori MIYAZAWA <[EMAIL PROTECTED]> Signed-off-by: David S. Miller <[EMAIL PROTECTED]> diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c index d4107bb..fb9f69c 100644 --- a/net/ipv4/xfrm4_policy.c +++ b/net/ipv4/xfrm4_policy.c @@ -274,6 +274,8 @@ static void xfrm4_dst_destroy(struct dst if (likely(xdst->u.rt.idev)) in_dev_put(xdst->u.rt.idev); + if (likely(xdst->u.rt.peer)) + inet_putpeer(xdst->u.rt.peer); xfrm_dst_destroy(xdst); } - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][IPSEC][4/7] inter address family ipsec tunnel
From: David Miller <[EMAIL PROTECTED]> Date: Wed, 06 Dec 2006 23:37:49 -0800 (PST) > From: Kazunori MIYAZAWA <[EMAIL PROTECTED]> > Date: Wed, 6 Dec 2006 20:35:37 +0900 > > > Sorry, I mixed up changes in the patches. I described that [4/7] will add > > "IPv6 over IPv4 IPsec tunnel". However I send a patch for "IPv4 over IPv6" > > as a reply because it includes the discussing item. > > So this patch adds IPv4 over IPv6 IPsec tunnel. It's complicated. > > > > I deleted subustituting NULL for rt->peer and moved atomic_inc stuff > > under the "if" section. > > I have applied this patch, thanks for fixing it up. Actually, I have to revert this change again, it still has a problem. Sorry :-/ I very much feared the following kind of obstacle with these changes. Specifically, references to modular IPV6 code from statically compiled IPV4 code. Which produces the following build error: net/built-in.o: In function `__xfrm4_bundle_create':xfrm4_policy.c:(.text+0x59a88): undefined reference to `xfrm6_output' :xfrm4_policy.c:(.text+0x59ac0): undefined reference to `xfrm6_output' Please test with IPV6 built modular in the future, thank you. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][IPSEC][4/7] inter address family ipsec tunnel
From: Kazunori MIYAZAWA <[EMAIL PROTECTED]> Date: Wed, 6 Dec 2006 20:35:37 +0900 > Sorry, I mixed up changes in the patches. I described that [4/7] will add > "IPv6 over IPv4 IPsec tunnel". However I send a patch for "IPv4 over IPv6" > as a reply because it includes the discussing item. > So this patch adds IPv4 over IPv6 IPsec tunnel. It's complicated. > > I deleted subustituting NULL for rt->peer and moved atomic_inc stuff > under the "if" section. I have applied this patch, thanks for fixing it up. > BTW, I have a question about descrementing the reference count of > rt->peer. The reference cound in normal "dst" structure is > decremented by calling inet_putpeer from ipv4_dst_destroy. But > xfrm4_dst_destroy does not call inet_putpeer. Where do we decrement > the count? Should xfrm4_dst_destroy do that? Indeed, it is a real leak. And yes, I believe that xfrm4_dst_destroy() should release it. I will make this fix, thank you. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
From: "Amit S. Kale" <[EMAIL PROTECTED]> Date: Thu, 7 Dec 2006 11:55:22 +0530 > We can let a driver handle dma mapping errors using these-> > > 1.Reduce the size of a receive ring. This will free some possibly remapped > memory, reducing pressure on iommu. We also need to printk a message so that > a user knows the reason why receive ring was shrunk. Growing it when iommu > pressure goes down will result in a ping-pong. > 2. Force processing of receive and transmit ring. This will ensure that the > buffers processed by hardware are freed, reducing iommu pressure. > > 3. If we need to do (1) and (2) a predefined number of times (say 20), stop > the queue. Stopping the queue in general will cause a ping-pong, so it should > be avoided as far as possible. This scheme assumes the networking card is the culprit. In many workloads it will not be and these efforts will be in vain and perhaps even make the situation worse. There's not reason to run the RX and TX queues, and even shrink them, when the FC controller has most of the IOMMU entires tied up. That's why users needs to queue up and get feedback when IOMMU space is made available. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/16] Spidernet DMA coalescing
It worries me when a patch series gets resent a few hours later. Did anything change? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7][TG3]: Identify Serdes devices more clearly.
[TG3]: Identify Serdes devices more clearly.
Change the message to more clearly identify Serdes devices.
Update version to 3.70.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 61e9533..a71707e 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -68,8 +68,8 @@
#define DRV_MODULE_NAME"tg3"
#define PFX DRV_MODULE_NAME": "
-#define DRV_MODULE_VERSION "3.69"
-#define DRV_MODULE_RELDATE "November 15, 2006"
+#define DRV_MODULE_VERSION "3.70"
+#define DRV_MODULE_RELDATE "December 1, 2006"
#define TG3_DEF_MAC_MODE 0
#define TG3_DEF_RX_MODE0
@@ -11932,13 +11932,15 @@ static int __devinit tg3_init_one(struct
pci_set_drvdata(pdev, dev);
- printk(KERN_INFO "%s: Tigon3 [partno(%s) rev %04x PHY(%s)] (%s) %sBaseT
Ethernet ",
+ printk(KERN_INFO "%s: Tigon3 [partno(%s) rev %04x PHY(%s)] (%s) %s
Ethernet ",
dev->name,
tp->board_part_number,
tp->pci_chip_rev_id,
tg3_phy_string(tp),
tg3_bus_string(tp, str),
- (tp->tg3_flags & TG3_FLAG_10_100_ONLY) ? "10/100" :
"10/100/1000");
+ ((tp->tg3_flags & TG3_FLAG_10_100_ONLY) ? "10/100Base-TX" :
+ ((tp->tg3_flags2 & TG3_FLG2_ANY_SERDES) ? "1000Base-SX" :
+"10/100/1000Base-T")));
for (i = 0; i < 6; i++)
printk("%2.2x%c", dev->dev_addr[i],
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7][TG3]: Use netif_msg_*.
[TG3]: Use netif_msg_*.
Use netif_msg_* to turn on or off some messages.
Based on Stephen Hemminger's initial patch.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 5dfeb64..99fb4e4 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1402,8 +1402,10 @@ static int tg3_set_power_state(struct tg
static void tg3_link_report(struct tg3 *tp)
{
if (!netif_carrier_ok(tp->dev)) {
- printk(KERN_INFO PFX "%s: Link is down.\n", tp->dev->name);
- } else {
+ if (netif_msg_link(tp))
+ printk(KERN_INFO PFX "%s: Link is down.\n",
+ tp->dev->name);
+ } else if (netif_msg_link(tp)) {
printk(KERN_INFO PFX "%s: Link is up at %d Mbps, %s duplex.\n",
tp->dev->name,
(tp->link_config.active_speed == SPEED_1000 ?
@@ -3710,8 +3712,9 @@ static void tg3_tx_timeout(struct net_de
{
struct tg3 *tp = netdev_priv(dev);
- printk(KERN_ERR PFX "%s: transmit timed out, resetting\n",
- dev->name);
+ if (netif_msg_tx_err(tp))
+ printk(KERN_ERR PFX "%s: transmit timed out, resetting\n",
+ dev->name);
schedule_work(&tp->reset_task);
}
@@ -8665,7 +8668,9 @@ static int tg3_test_registers(struct tg3
return 0;
out:
- printk(KERN_ERR PFX "Register test failed at offset %x\n", offset);
+ if (netif_msg_hw(tp))
+ printk(KERN_ERR PFX "Register test failed at offset %x\n",
+ offset);
tw32(offset, save_val);
return -EIO;
}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7][TG3]: Use msleep.
[TG3]: Use msleep.
Change some udelay() in some eeprom functions to msleep(). Eeprom
related functions are always called from sleepable context.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 99fb4e4..61e9533 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -9467,16 +9467,12 @@ static void __devinit tg3_get_5906_nvram
/* Chips other than 5700/5701 use the NVRAM for fetching info. */
static void __devinit tg3_nvram_init(struct tg3 *tp)
{
- int j;
-
tw32_f(GRC_EEPROM_ADDR,
(EEPROM_ADDR_FSM_RESET |
(EEPROM_DEFAULT_CLOCK_PERIOD <<
EEPROM_ADDR_CLKPERD_SHIFT)));
- /* XXX schedule_timeout() ... */
- for (j = 0; j < 100; j++)
- udelay(10);
+ msleep(1);
/* Enable seeprom accesses. */
tw32_f(GRC_LOCAL_CTRL,
@@ -9537,12 +9533,12 @@ static int tg3_nvram_read_using_eeprom(s
EEPROM_ADDR_ADDR_MASK) |
EEPROM_ADDR_READ | EEPROM_ADDR_START);
- for (i = 0; i < 1; i++) {
+ for (i = 0; i < 1000; i++) {
tmp = tr32(GRC_EEPROM_ADDR);
if (tmp & EEPROM_ADDR_COMPLETE)
break;
- udelay(100);
+ msleep(1);
}
if (!(tmp & EEPROM_ADDR_COMPLETE))
return -EBUSY;
@@ -9667,12 +9663,12 @@ static int tg3_nvram_write_block_using_e
EEPROM_ADDR_START |
EEPROM_ADDR_WRITE);
- for (j = 0; j < 1; j++) {
+ for (j = 0; j < 1000; j++) {
val = tr32(GRC_EEPROM_ADDR);
if (val & EEPROM_ADDR_COMPLETE)
break;
- udelay(100);
+ msleep(1);
}
if (!(val & EEPROM_ADDR_COMPLETE)) {
rc = -EBUSY;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7][TG3]: Allow partial speed advertisement.
[TG3]: Allow partial speed advertisement.
Honor the advertisement bitmask from ethtool. We used to always
advertise the full capability when autoneg was set to on.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 6a2f019..5dfeb64 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1558,12 +1558,6 @@ static void tg3_phy_copper_begin(struct
tg3_writephy(tp, MII_ADVERTISE, new_adv);
} else if (tp->link_config.speed == SPEED_INVALID) {
- tp->link_config.advertising =
- (ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
-ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full |
-ADVERTISED_1000baseT_Half | ADVERTISED_1000baseT_Full |
-ADVERTISED_Autoneg | ADVERTISED_MII);
-
if (tp->tg3_flags & TG3_FLAG_10_100_ONLY)
tp->link_config.advertising &=
~(ADVERTISED_1000baseT_Half |
@@ -1707,25 +1701,36 @@ static int tg3_init_5401phy_dsp(struct t
return err;
}
-static int tg3_copper_is_advertising_all(struct tg3 *tp)
+static int tg3_copper_is_advertising_all(struct tg3 *tp, u32 mask)
{
- u32 adv_reg, all_mask;
+ u32 adv_reg, all_mask = 0;
+
+ if (mask & ADVERTISED_10baseT_Half)
+ all_mask |= ADVERTISE_10HALF;
+ if (mask & ADVERTISED_10baseT_Full)
+ all_mask |= ADVERTISE_10FULL;
+ if (mask & ADVERTISED_100baseT_Half)
+ all_mask |= ADVERTISE_100HALF;
+ if (mask & ADVERTISED_100baseT_Full)
+ all_mask |= ADVERTISE_100FULL;
if (tg3_readphy(tp, MII_ADVERTISE, &adv_reg))
return 0;
- all_mask = (ADVERTISE_10HALF | ADVERTISE_10FULL |
- ADVERTISE_100HALF | ADVERTISE_100FULL);
if ((adv_reg & all_mask) != all_mask)
return 0;
if (!(tp->tg3_flags & TG3_FLAG_10_100_ONLY)) {
u32 tg3_ctrl;
+ all_mask = 0;
+ if (mask & ADVERTISED_1000baseT_Half)
+ all_mask |= ADVERTISE_1000HALF;
+ if (mask & ADVERTISED_1000baseT_Full)
+ all_mask |= ADVERTISE_1000FULL;
+
if (tg3_readphy(tp, MII_TG3_CTRL, &tg3_ctrl))
return 0;
- all_mask = (MII_TG3_CTRL_ADV_1000_HALF |
- MII_TG3_CTRL_ADV_1000_FULL);
if ((tg3_ctrl & all_mask) != all_mask)
return 0;
}
@@ -1885,7 +1890,8 @@ static int tg3_setup_copper_phy(struct t
/* Force autoneg restart if we are exiting
* low power mode.
*/
- if (!tg3_copper_is_advertising_all(tp))
+ if (!tg3_copper_is_advertising_all(tp,
+ tp->link_config.advertising))
current_link_up = 0;
} else {
current_link_up = 0;
@@ -10156,7 +10162,7 @@ static int __devinit tg3_phy_probe(struc
if (!(tp->tg3_flags2 & TG3_FLG2_ANY_SERDES) &&
!(tp->tg3_flags & TG3_FLAG_ENABLE_ASF)) {
- u32 bmsr, adv_reg, tg3_ctrl;
+ u32 bmsr, adv_reg, tg3_ctrl, mask;
tg3_readphy(tp, MII_BMSR, &bmsr);
if (!tg3_readphy(tp, MII_BMSR, &bmsr) &&
@@ -10180,7 +10186,10 @@ static int __devinit tg3_phy_probe(struc
MII_TG3_CTRL_ENABLE_AS_MASTER);
}
- if (!tg3_copper_is_advertising_all(tp)) {
+ mask = (ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
+ ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full |
+ ADVERTISED_1000baseT_Half | ADVERTISED_1000baseT_Full);
+ if (!tg3_copper_is_advertising_all(tp, mask)) {
tg3_writephy(tp, MII_ADVERTISE, adv_reg);
if (!(tp->tg3_flags & TG3_FLAG_10_100_ONLY))
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7][TG3]: Fix Phy loopback.
[TG3]: Fix Phy loopback.
Phy loopback on most 10/100 devices need to be run in 1Gbps mode in
GMII mode.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index c20bb99..819758e 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -8781,17 +8781,20 @@ static int tg3_run_loopback(struct tg3 *
tg3_writephy(tp, 0x10, phy & ~0x4000);
tg3_writephy(tp, MII_TG3_EPHY_TEST, phytest);
}
- }
- val = BMCR_LOOPBACK | BMCR_FULLDPLX;
- if (tp->tg3_flags & TG3_FLAG_10_100_ONLY)
- val |= BMCR_SPEED100;
- else
- val |= BMCR_SPEED1000;
+ val = BMCR_LOOPBACK | BMCR_FULLDPLX | BMCR_SPEED100;
+ } else
+ val = BMCR_LOOPBACK | BMCR_FULLDPLX | BMCR_SPEED1000;
tg3_writephy(tp, MII_BMCR, val);
udelay(40);
- if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906)
+
+ mac_mode = (tp->mac_mode & ~MAC_MODE_PORT_MODE_MASK) |
+ MAC_MODE_LINK_POLARITY;
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906) {
tg3_writephy(tp, MII_TG3_EPHY_PTEST, 0x1800);
+ mac_mode |= MAC_MODE_PORT_MODE_MII;
+ } else
+ mac_mode |= MAC_MODE_PORT_MODE_GMII;
/* reset to prevent losing 1st rx packet intermittently */
if (tp->tg3_flags2 & TG3_FLG2_MII_SERDES) {
@@ -8799,12 +8802,6 @@ static int tg3_run_loopback(struct tg3 *
udelay(10);
tw32_f(MAC_RX_MODE, tp->rx_mode);
}
- mac_mode = (tp->mac_mode & ~MAC_MODE_PORT_MODE_MASK) |
- MAC_MODE_LINK_POLARITY;
- if (tp->tg3_flags & TG3_FLAG_10_100_ONLY)
- mac_mode |= MAC_MODE_PORT_MODE_MII;
- else
- mac_mode |= MAC_MODE_PORT_MODE_GMII;
if ((tp->phy_id & PHY_ID_MASK) == PHY_ID_BCM5401) {
mac_mode &= ~MAC_MODE_LINK_POLARITY;
tg3_writephy(tp, MII_TG3_EXT_CTRL,
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7][TG3]: Add TG3_FLG2_IS_NIC flag.
[TG3]: Add TG3_FLG2_IS_NIC flag.
Add Tg3_FLG2_IS_NIC flag to unambiguously determine whether the
device is NIC or onboard. Previously, the EEPROM_WRITE_PROT flag was
overloaded to also mean onboard. With the separation, we can
support some devices that are onboard but do not use eeprom write
protect.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index bfa7e3e..6a2f019 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1062,7 +1062,7 @@ static void tg3_frob_aux_power(struct tg
{
struct tg3 *tp_peer = tp;
- if ((tp->tg3_flags & TG3_FLAG_EEPROM_WRITE_PROT) != 0)
+ if ((tp->tg3_flags2 & TG3_FLG2_IS_NIC) == 0)
return;
if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) ||
@@ -1213,8 +1213,8 @@ static int tg3_set_power_state(struct tg
power_control);
udelay(100);/* Delay after power state change */
- /* Switch out of Vaux if it is not a LOM */
- if (!(tp->tg3_flags & TG3_FLAG_EEPROM_WRITE_PROT))
+ /* Switch out of Vaux if it is a NIC */
+ if (tp->tg3_flags2 & TG3_FLG2_IS_NIC)
tw32_wait_f(GRC_LOCAL_CTRL, tp->grc_local_ctrl, 100);
return 0;
@@ -6397,16 +6397,17 @@ static int tg3_reset_hw(struct tg3 *tp,
udelay(40);
/* tp->grc_local_ctrl is partially set up during tg3_get_invariants().
-* If TG3_FLAG_EEPROM_WRITE_PROT is set, we should read the
+* If TG3_FLG2_IS_NIC is zero, we should read the
* register to preserve the GPIO settings for LOMs. The GPIOs,
* whether used as inputs or outputs, are set by boot code after
* reset.
*/
- if (tp->tg3_flags & TG3_FLAG_EEPROM_WRITE_PROT) {
+ if (!(tp->tg3_flags2 & TG3_FLG2_IS_NIC)) {
u32 gpio_mask;
- gpio_mask = GRC_LCLCTRL_GPIO_OE0 | GRC_LCLCTRL_GPIO_OE2 |
- GRC_LCLCTRL_GPIO_OUTPUT0 | GRC_LCLCTRL_GPIO_OUTPUT2;
+ gpio_mask = GRC_LCLCTRL_GPIO_OE0 | GRC_LCLCTRL_GPIO_OE1 |
+ GRC_LCLCTRL_GPIO_OE2 | GRC_LCLCTRL_GPIO_OUTPUT0 |
+ GRC_LCLCTRL_GPIO_OUTPUT1 | GRC_LCLCTRL_GPIO_OUTPUT2;
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)
gpio_mask |= GRC_LCLCTRL_GPIO_OE3 |
@@ -6418,8 +6419,9 @@ static int tg3_reset_hw(struct tg3 *tp,
tp->grc_local_ctrl |= tr32(GRC_LOCAL_CTRL) & gpio_mask;
/* GPIO1 must be driven high for eeprom write protect */
- tp->grc_local_ctrl |= (GRC_LCLCTRL_GPIO_OE1 |
- GRC_LCLCTRL_GPIO_OUTPUT1);
+ if (tp->tg3_flags & TG3_FLAG_EEPROM_WRITE_PROT)
+ tp->grc_local_ctrl |= (GRC_LCLCTRL_GPIO_OE1 |
+ GRC_LCLCTRL_GPIO_OUTPUT1);
}
tw32_f(GRC_LOCAL_CTRL, tp->grc_local_ctrl);
udelay(100);
@@ -9963,8 +9965,10 @@ static void __devinit tg3_get_eeprom_hw_
tp->tg3_flags |= TG3_FLAG_EEPROM_WRITE_PROT;
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906) {
- if (!(tr32(PCIE_TRANSACTION_CFG) & PCIE_TRANS_CFG_LOM))
+ if (!(tr32(PCIE_TRANSACTION_CFG) & PCIE_TRANS_CFG_LOM)) {
tp->tg3_flags &= ~TG3_FLAG_EEPROM_WRITE_PROT;
+ tp->tg3_flags2 |= TG3_FLG2_IS_NIC;
+ }
return;
}
@@ -10064,10 +10068,17 @@ static void __devinit tg3_get_eeprom_hw_
tp->pdev->subsystem_vendor == PCI_VENDOR_ID_DELL)
tp->led_ctrl = LED_CTRL_MODE_PHY_2;
- if (nic_cfg & NIC_SRAM_DATA_CFG_EEPROM_WP)
+ if (nic_cfg & NIC_SRAM_DATA_CFG_EEPROM_WP) {
tp->tg3_flags |= TG3_FLAG_EEPROM_WRITE_PROT;
- else
+ if ((tp->pdev->subsystem_vendor ==
+PCI_VENDOR_ID_ARIMA) &&
+ (tp->pdev->subsystem_device == 0x205a ||
+tp->pdev->subsystem_device == 0x2063))
+ tp->tg3_flags &= ~TG3_FLAG_EEPROM_WRITE_PROT;
+ } else {
tp->tg3_flags &= ~TG3_FLAG_EEPROM_WRITE_PROT;
+ tp->tg3_flags2 |= TG3_FLG2_IS_NIC;
+ }
if (nic_cfg & NIC_SRAM_DATA_CFG_ASF_ENABLE) {
tp->tg3_flags |= TG3_FLAG_ENABLE_ASF;
@@ -10693,7 +10704,7 @@ static int __devinit tg3_get_invariants(
tp->tg3_flags |= TG3_FLAG_SRAM_USE_CONFIG;
/* Get eeprom hw config before calling tg3_set_power_state().
-* In particular, the TG3_FLAG_EEPROM_WRITE_PROT flag must be
+* In particular, the TG3_FLG2_IS_NIC flag must be
* determined before calling tg3_s
[PATCH 2/7][TG3]: Add 5787F device ID.
[TG3]: Add 5787F device ID.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 819758e..bfa7e3e 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -192,6 +192,7 @@ static struct pci_device_id tg3_pci_tbl[
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5786)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5787)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5787M)},
+ {PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5787F)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5714)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5714S)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5715)},
@@ -10859,7 +10860,8 @@ static int __devinit tg3_get_invariants(
tp->pdev->device == PCI_DEVICE_ID_TIGON3_5705F)) ||
(tp->pdev->vendor == PCI_VENDOR_ID_BROADCOM &&
(tp->pdev->device == PCI_DEVICE_ID_TIGON3_5751F ||
- tp->pdev->device == PCI_DEVICE_ID_TIGON3_5753F)) ||
+ tp->pdev->device == PCI_DEVICE_ID_TIGON3_5753F ||
+ tp->pdev->device == PCI_DEVICE_ID_TIGON3_5787F)) ||
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906)
tp->tg3_flags |= TG3_FLAG_10_100_ONLY;
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6294559..55710b7 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1927,6 +1927,7 @@
#define PCI_DEVICE_ID_TIGON3_5750M 0x167c
#define PCI_DEVICE_ID_TIGON3_5751M 0x167d
#define PCI_DEVICE_ID_TIGON3_5751F 0x167e
+#define PCI_DEVICE_ID_TIGON3_5787F 0x167f
#define PCI_DEVICE_ID_TIGON3_5787M 0x1693
#define PCI_DEVICE_ID_TIGON3_5782 0x1696
#define PCI_DEVICE_ID_TIGON3_5786 0x169a
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
On Thursday 07 December 2006 12:16, Stephen Hemminger wrote: > Amit S. Kale wrote: > > We can let a driver handle dma mapping errors using these-> > > > > 1.Reduce the size of a receive ring. This will free some possibly > > remapped memory, reducing pressure on iommu. We also need to printk a > > message so that a user knows the reason why receive ring was shrunk. > > Growing it when iommu pressure goes down will result in a ping-pong. > > 2. Force processing of receive and transmit ring. This will ensure that > > the buffers processed by hardware are freed, reducing iommu pressure. > > > > 3. If we need to do (1) and (2) a predefined number of times (say 20), > > stop the queue. Stopping the queue in general will cause a ping-pong, so > > it should be avoided as far as possible. > > But what if it isn't the network device that is using all the IOMMU > resources. > Linux is already crap at handling out of memory, lets not add another > starvation > path. > > In this case, the device does have some idea about "worst case" i/o's in > flight, > couldn't we have some sort of reservation/management system to avoid > overcommitting? > Worst case map usage for a network device can be fairly high because of > the possiblity > of on transmit with a high number of pages when using TSO. Perhaps the > transmit > ring needs to be accounted for in maps used rather than packets pending. I am afraid I don't have a good answer for that. Any kind of reservation may result in underutilization and transparently shared resources may result in starvation. Designing heuristics for handling these cases may be the only possible wayout, though these heuristics need to be validated frequently to ensure that they aren't out of date. -Amit - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
Amit S. Kale wrote: We can let a driver handle dma mapping errors using these-> 1.Reduce the size of a receive ring. This will free some possibly remapped memory, reducing pressure on iommu. We also need to printk a message so that a user knows the reason why receive ring was shrunk. Growing it when iommu pressure goes down will result in a ping-pong. 2. Force processing of receive and transmit ring. This will ensure that the buffers processed by hardware are freed, reducing iommu pressure. 3. If we need to do (1) and (2) a predefined number of times (say 20), stop the queue. Stopping the queue in general will cause a ping-pong, so it should be avoided as far as possible. But what if it isn't the network device that is using all the IOMMU resources. Linux is already crap at handling out of memory, lets not add another starvation path. In this case, the device does have some idea about "worst case" i/o's in flight, couldn't we have some sort of reservation/management system to avoid overcommitting? Worst case map usage for a network device can be fairly high because of the possiblity of on transmit with a high number of pages when using TSO. Perhaps the transmit ring needs to be accounted for in maps used rather than packets pending. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bonding: change spinlocks and remove timers in favor of workqueues
Andy Gospodarek <[EMAIL PROTECTED]> wrote: >On 12/4/06, Jay Vosburgh <[EMAIL PROTECTED]> wrote: [...] >> Appended is my working development patch for rearranging a bunch >> of stuff in bonding. This is a work in progress, and is not likely to >> be very stable. This largely reimplements the entire link monitor >> scheme, along with associated locking changes. It's not split into >> functional pieces, and is just a big kitchen sink blob at the moment. >> It's still very experimental. [...] >Thanks for sending it. I've finally got some time to digest it. I >didn't get a chance to test it, but I did have a chance to take a look >at it in detail. I think the patch might have been over the size limit for netdev, as I never saw it appear on the list. For interested readers, the description Andy mentions in his next paragraph is: By way of description, in the patch, all monitors (link state and mode specific bits for ALB and 802.3ad) are all dispatched from a single workqueue (rather than each on a separate timer), and the updelay / downdelay parameters are done as special monitors. The monitors can be paused for purposes of conflict avoidance, although some mutexing with TX activity is still necessary. It also allows for the ARP and MII link monitors to run simultaneously (which isn't allowed in the current mainline driver). This also splits up the slave lists into an "all" and an "active" list, rearranges the release processing for bonding (consolidates duplicated code from bond_release and bond_release_all into a common function). I'm still dithering as to whether or not this is a good idea; it adds a little complexity to link state changes and add/remove of slaves, but simplifies most of the transmit processing. The locking still needs some adjustment; there's some tracking of whether or not RTNL is held, and right now most locking is of the _bh variety, which may be too strict. >I certainly agree with the design points you laid out in your >description. I like the fact that you've restructured a lot of the >code and moved the monitoring to a common place. It is also nice to >have it in one spot so you can report link status and bond membership. > I don't think the bh-locking is necessary since the workqueues >eliminate the possibility that you will be preempted by the bonding >driver -- I dropped them all from my patch. The only concern I had in that regard is whether it's possible to get into a bonding transmit function from someplace that requires _bh level locking to mutex against. I'm thinking in particular of packet receive processing somewhere turning around to do a transmit right away. >Overall this seems like a good way to go, but it [obviously] seems >like it would be good to work towards this functionality rather than >simply dumping this huge blob all at once. I absolutely agree that moving in steps to a final resolution is much better than dropping a big blob; the patch ended up this way since it's just a big diff from my experimental tree. [...] I would like to use a >smaller patch to switch to workqueues (my patch or a partial of yours >-- it makes no difference to me) as a start with the intent to let >that soak-in for a while and follow it with chunks that will >eventually get the entire driver closer to the functionality that your >big patch has. I don't see a problem in starting with your patch; the end state will be sufficiently different (e.g., the four workqueues would ultimately be consolidated into one) that it's still a good testbed to start with. The only other minor issue is that after this week, I will be off for the holidays (and far, far away from email) for the next month. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
We can let a driver handle dma mapping errors using these-> 1.Reduce the size of a receive ring. This will free some possibly remapped memory, reducing pressure on iommu. We also need to printk a message so that a user knows the reason why receive ring was shrunk. Growing it when iommu pressure goes down will result in a ping-pong. 2. Force processing of receive and transmit ring. This will ensure that the buffers processed by hardware are freed, reducing iommu pressure. 3. If we need to do (1) and (2) a predefined number of times (say 20), stop the queue. Stopping the queue in general will cause a ping-pong, so it should be avoided as far as possible. -Amit On Thursday 07 December 2006 06:28, Stephen Hemminger wrote: > The more robust way would be to stop the queue (like flow control) > and return busy. You would need a timer though to handle the case > where some disk i/o stole all the mappings and then network device flow > blocked. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
On Thursday 07 December 2006 01:03, Muli Ben-Yehuda wrote: > On Wed, Dec 06, 2006 at 10:16:44AM -0800, Stephen Hemminger wrote: > > I think it is really only an issue for drivers that turn on HIGH_DMA > > and have limited mask values. The majority of drivers either only > > handle 32 bit (!HIGH_DMA) or do full 64 bit mapping. I don't know > > the details of how we manage IOMMU, but doesn't mapping always work > > for those drivers. > > It's up to an IOMMU (DMA-API) implementation to define what > constitutes a mapping error, e.g., Calgary and GART on x86-64 will > return bad_dma_address from the mapping functions when they run out of > entries in the IO space, which can happen regardless of the mask. We've seen IOMMU space running out on ia64 systems. Would this be the case with other 10G driver requiring IOMMU remapping? We need frequent map-unmap at near 10G throughput. On the x86_64 boxes that don't feature iommu functionality (because the motherboard disables it or because Linux can't handle it) Linux bounce buffer framework automatically comes into picture. Could we have the same framework take over when IOMMU space is over? I don't think this is possible with present code, though. We probably can have fallback_dma_ops in addition to dma_ops. -Amit - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NAPI and shared interrupt control
> What Eugene does currently, which seems to me like it's actually the > only proper solution, is to create a separate net_device structure for > the DMA engine and thus have a single NAPI poll & weighting for all the > EMACs sharing a given MAL (MAL is the name of that DMA engine). This > means that Rx from any of the channels schedules the poll, and > interrupts can be properly masked/unmasked globally based on the > presence/absence of work on all the channels. Actually, another solution would be to have one of the instances do the NAPI poll for all of them instead of creating a separate net_device for the DMA engine... Ben. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
NAPI and shared interrupt control
Hi Dave ! I'd like your advice on something we need to deal with in the EMAC ethernet driver (an IBM part). The driver is maintainedby Eugene (CC'd), I'm mostly adding support for some new hardware at this point, which involves making it SMP safe among other things ;-) So the problem this driver has is with NAPI polling and its shared DMA engine. Basically, the DMA engine can be shared between several EMAC ethernet cells. It has separate "channels" (and thus separate rings) so in that area, all is fine... except the interrupt control. The is only one global interrupt enable/disable bit for packet interrupts, shared by all the EMACs using that DMA engine cell. That means complications for NAPI polling as we can't just disable/enable Rx interrupts as NAPI would normally expect on a per-device basis. What Eugene does currently, which seems to me like it's actually the only proper solution, is to create a separate net_device structure for the DMA engine and thus have a single NAPI poll & weighting for all the EMACs sharing a given MAL (MAL is the name of that DMA engine). This means that Rx from any of the channels schedules the poll, and interrupts can be properly masked/unmasked globally based on the presence/absence of work on all the channels. I'd still like to run it through you, make sure you are ok or see if you have a better idea as you are way more familiar with the network stack than I am :-) My main concern with the approach is purely due to how the additional net_device is initialized. It's currently allocated as part of some private data structure in the driver which then manually initializes some fields that are used by NAPI polling. While it certainly works, I find the approach a bit fragile (what if the NAPI code internals change and some initialisations have to be done differently ?) Thus I was wondering, if you think the approach is sane, wether it would make sense to provide a low level netif_init_device() thingy that makes sure a net_device data structure is fully initialized and suitable for use ? (make sure spinlocks are initialized etc...). Something similar to the code used to initialize the backlog "fake" device ? The driver currently does: set_bit(__LINK_STATE_START, &mal->poll_dev.state); mal->poll_dev.weight = CONFIG_IBM_EMAC_POLL_WEIGHT; mal->poll_dev.poll = mal_poll; mal->poll_dev.priv = mal; atomic_set(&mal->poll_dev.refcnt, 1); (None of the spinlocks are initialized, but then, the driver was only ever used on UP only embedded CPUs so far and it's possible that none of the NAPI code path for which this net_device structure is used are hitting any spinlock). Or do you think that net_device should be fully registered with register_netdev ? (that would involve a lot more than what is currently needed/used though). Cheers, Ben. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] irlan: fix header build warning
From: Randy Dunlap <[EMAIL PROTECTED]> Date: Wed, 6 Dec 2006 17:08:18 -0800 > On Wed, 06 Dec 2006 16:57:17 -0800 (PST) David Miller wrote: > > > How about we protect these function externs with CONFIG_PROC_FS ifdefs > > instead? > > Sure. > > --- > From: Randy Dunlap <[EMAIL PROTECTED]> > > Fix compile warning when CONFIG_PROC_FS=n: > > include/net/irda/irlan_filter.h:31: warning: 'struct seq_file' declared > inside parameter list > include/net/irda/irlan_filter.h:31: warning: its scope is only this > definition or declaration, which is probably not what you want > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> Looks great, applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [IrDA] Incorrect TTP header reservation
From: Samuel Ortiz <[EMAIL PROTECTED]> Date: Thu, 7 Dec 2006 02:51:17 +0200 > We must reserve SAR + MAX_HEADER bytes for IrLMP to fit in. > > Patch from Jeet Chaudhuri <[EMAIL PROTECTED]> > Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]> Also applied. Are you sending this patch to -stable? Please do. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [IrDA] PXA FIR code device model conversion
From: Samuel Ortiz <[EMAIL PROTECTED]> Date: Thu, 7 Dec 2006 02:50:53 +0200 > pxaficp_ir.c was not converted to the device model framework. > > Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]> Applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
From: Rick Jones <[EMAIL PROTECTED]> Date: Wed, 06 Dec 2006 18:18:52 -0800 > While tossing a TCP|UDP|SCTP|etc packet could be plusungood, especially > if the IOMMU fills frequently (for some suitable definiton of > frequently), is it really worth the effort to save say an ACK? ACKs are less important than data packets sure. But the drivers shouldn't be parsing packets at transmit time to decide what to do. And when this kind of thing fails, it's going to fail for all the packets currently queued up to the device for transmit. So it's likely not "just an ACK", but rather a set of several packets composed of ACKs and data packets. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
David Miller wrote: From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Wed, 6 Dec 2006 16:58:35 -0800 The more robust way would be to stop the queue (like flow control) and return busy. You would need a timer though to handle the case where some disk i/o stole all the mappings and then network device flow blocked. You need some kind of fairness, yes, that's why I suggested a callback. When your DMA allocation fails, you get into the rear of the FIFO, when a free occurs, we callback starting from the head of the FIFO. You don't get removed from the FIFO unless at least one of your DMA allocation retries succeed. While tossing a TCP|UDP|SCTP|etc packet could be plusungood, especially if the IOMMU fills frequently (for some suitable definiton of frequently), is it really worth the effort to save say an ACK? rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bonding: change spinlocks and remove timers in favor of workqueues
On 12/4/06, Jay Vosburgh <[EMAIL PROTECTED]> wrote: Andy Gospodarek <[EMAIL PROTECTED]> wrote: [...] >> Let me see if I can dust off the extensive patch that does >> change the locking model; I'll see if I can bring it up to the current >> git and post it. >> > >It would seem ideal if we could combine the two into one big patch. Appended is my working development patch for rearranging a bunch of stuff in bonding. This is a work in progress, and is not likely to be very stable. This largely reimplements the entire link monitor scheme, along with associated locking changes. It's not split into functional pieces, and is just a big kitchen sink blob at the moment. It's still very experimental. Jay, Thanks for sending it. I've finally got some time to digest it. I didn't get a chance to test it, but I did have a chance to take a look at it in detail. I certainly agree with the design points you laid out in your description. I like the fact that you've restructured a lot of the code and moved the monitoring to a common place. It is also nice to have it in one spot so you can report link status and bond membership. I don't think the bh-locking is necessary since the workqueues eliminate the possibility that you will be preempted by the bonding driver -- I dropped them all from my patch. Overall this seems like a good way to go, but it [obviously] seems like it would be good to work towards this functionality rather than simply dumping this huge blob all at once. I would like to use a smaller patch to switch to workqueues (my patch or a partial of yours -- it makes no difference to me) as a start with the intent to let that soak-in for a while and follow it with chunks that will eventually get the entire driver closer to the functionality that your big patch has. Thoughts? -andy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Wed, 6 Dec 2006 16:58:35 -0800 > The more robust way would be to stop the queue (like flow control) > and return busy. You would need a timer though to handle the case > where some disk i/o stole all the mappings and then network device flow > blocked. You need some kind of fairness, yes, that's why I suggested a callback. When your DMA allocation fails, you get into the rear of the FIFO, when a free occurs, we callback starting from the head of the FIFO. You don't get removed from the FIFO unless at least one of your DMA allocation retries succeed. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] irlan: fix header build warning
On Wed, 06 Dec 2006 16:57:17 -0800 (PST) David Miller wrote: > How about we protect these function externs with CONFIG_PROC_FS ifdefs > instead? Sure. --- From: Randy Dunlap <[EMAIL PROTECTED]> Fix compile warning when CONFIG_PROC_FS=n: include/net/irda/irlan_filter.h:31: warning: 'struct seq_file' declared inside parameter list include/net/irda/irlan_filter.h:31: warning: its scope is only this definition or declaration, which is probably not what you want Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- include/net/irda/irlan_filter.h |2 ++ 1 file changed, 2 insertions(+) --- linux-2.6.19-git7.orig/include/net/irda/irlan_filter.h +++ linux-2.6.19-git7/include/net/irda/irlan_filter.h @@ -28,6 +28,8 @@ void irlan_check_command_param(struct irlan_cb *self, char *param, char *value); void irlan_filter_request(struct irlan_cb *self, struct sk_buff *skb); +#ifdef CONFIG_PROC_FS void irlan_print_filter(struct seq_file *seq, int filter_type); +#endif #endif /* IRLAN_FILTER_H */ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
On Wed, 06 Dec 2006 16:54:18 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote: > From: Stephen Hemminger <[EMAIL PROTECTED]> > Date: Wed, 6 Dec 2006 10:16:44 -0800 > > > I think it is really only an issue for drivers that turn on HIGH_DMA > > and have limited mask values. The majority of drivers either only handle > > 32 bit (!HIGH_DMA) or do full 64 bit mapping. I don't know the details > > of how we manage IOMMU, but doesn't mapping always work for those drivers. > > > > That just leaves devices with odd size mask values that need to be > > handle mapping errors. > > Not true. > > On platforms such as sparc64 the IOMMU is used for all DMA mappings, > no matter what, because only IOMMU based mappings can do prefetching > and write-combining in the PCI controller. > > The problem with just silently dropping packets that can't get DMA > mapped is that you're going to drop a very large sequence of these > while the IOMMU is out of space, and that to me looks like a bad > quality of implementation decision. > > The IOMMU layer really needs a way to callback the driver to tell it > when space is available, or something similar. > > FWIW, Solaris handles this by blocking when the IOMMU is out of space > since under Solaris even interrupt contexts can block (via interrupt > threads). > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html The more robust way would be to stop the queue (like flow control) and return busy. You would need a timer though to handle the case where some disk i/o stole all the mappings and then network device flow blocked. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] irlan: fix header build warning
From: Randy Dunlap <[EMAIL PROTECTED]> Date: Wed, 6 Dec 2006 11:44:07 -0800 > From: Randy Dunlap <[EMAIL PROTECTED]> > > Fix compile warning when CONFIG_PROC_FS=n: > > include/net/irda/irlan_filter.h:31: warning: 'struct seq_file' declared > inside parameter list > include/net/irda/irlan_filter.h:31: warning: its scope is only this > definition or declaration, which is probably not what you want > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> How about we protect these function externs with CONFIG_PROC_FS ifdefs instead? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel header changes break glibc build
From: Stefan Rompf <[EMAIL PROTECTED]> Date: Wed, 6 Dec 2006 20:32:40 +0100 (MET) > Am Montag, 4. Dezember 2006 10:13 schrieb Thomas Graf: > > > I do not agree with the change to include if_addr.h in rtnetlink.h. > > The point is to move bits apart and have multiple small pieces > > of header files defining a specific rtnetlink family which are a > > lot easier to maintain for both kernel and userspace than one giant > > rtnetlink.h for everything. > > According to a user's report, your change also broke compilation of my > dhcpclient because it neeeds if_addr.h since 2.6.19. Any suggestion how to > make one source code build on 2.6.19 and older headers? I hope you don't want > me to check on UTS_RELEASE in a userspace program? That's enough for me. Thomas we need to restore things to how they were before. If that means including if_addr.h from rtnetlink.h so be it. We can't break shit like this, there are no excuses, especially now that we properly frob the headers for userspace consumption in the kernel tree. Before you hit the reply button, read me again, there are no excuses for this breakage we've caused. We must fix it now. Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Wed, 6 Dec 2006 10:16:44 -0800 > I think it is really only an issue for drivers that turn on HIGH_DMA > and have limited mask values. The majority of drivers either only handle > 32 bit (!HIGH_DMA) or do full 64 bit mapping. I don't know the details > of how we manage IOMMU, but doesn't mapping always work for those drivers. > > That just leaves devices with odd size mask values that need to be > handle mapping errors. Not true. On platforms such as sparc64 the IOMMU is used for all DMA mappings, no matter what, because only IOMMU based mappings can do prefetching and write-combining in the PCI controller. The problem with just silently dropping packets that can't get DMA mapped is that you're going to drop a very large sequence of these while the IOMMU is out of space, and that to me looks like a bad quality of implementation decision. The IOMMU layer really needs a way to callback the driver to tell it when space is available, or something similar. FWIW, Solaris handles this by blocking when the IOMMU is out of space since under Solaris even interrupt contexts can block (via interrupt threads). - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [IrDA] PXA FIR code device model conversion
Hi Dave,
pxaficp_ir.c was not converted to the device model framework.
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
---
drivers/net/irda/pxaficp_ir.c | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/irda/pxaficp_ir.c b/drivers/net/irda/pxaficp_ir.c
index f9a1c88..9137e23 100644
--- a/drivers/net/irda/pxaficp_ir.c
+++ b/drivers/net/irda/pxaficp_ir.c
@@ -704,9 +704,9 @@ static int pxa_irda_stop(struct net_devi
return 0;
}
-static int pxa_irda_suspend(struct device *_dev, pm_message_t state)
+static int pxa_irda_suspend(struct platform_device *_dev, pm_message_t state)
{
- struct net_device *dev = dev_get_drvdata(_dev);
+ struct net_device *dev = platform_get_drvdata(_dev);
struct pxa_irda *si;
if (dev && netif_running(dev)) {
@@ -718,9 +718,9 @@ static int pxa_irda_suspend(struct devic
return 0;
}
-static int pxa_irda_resume(struct device *_dev)
+static int pxa_irda_resume(struct platform_device *_dev)
{
- struct net_device *dev = dev_get_drvdata(_dev);
+ struct net_device *dev = platform_get_drvdata(_dev);
struct pxa_irda *si;
if (dev && netif_running(dev)) {
@@ -746,9 +746,8 @@ static int pxa_irda_init_iobuf(iobuff_t
return io->head ? 0 : -ENOMEM;
}
-static int pxa_irda_probe(struct device *_dev)
+static int pxa_irda_probe(struct platform_device *pdev)
{
- struct platform_device *pdev = to_platform_device(_dev);
struct net_device *dev;
struct pxa_irda *si;
unsigned int baudrate_mask;
@@ -822,9 +821,9 @@ err_mem_1:
return err;
}
-static int pxa_irda_remove(struct device *_dev)
+static int pxa_irda_remove(struct platform_device *_dev)
{
- struct net_device *dev = dev_get_drvdata(_dev);
+ struct net_device *dev = platform_get_drvdata(_dev);
if (dev) {
struct pxa_irda *si = netdev_priv(dev);
@@ -840,9 +839,10 @@ static int pxa_irda_remove(struct device
return 0;
}
-static struct device_driver pxa_ir_driver = {
- .name = "pxa2xx-ir",
- .bus= &platform_bus_type,
+static struct platform_driver pxa_ir_driver = {
+ .driver = {
+ .name = "pxa2xx-ir",
+ },
.probe = pxa_irda_probe,
.remove = pxa_irda_remove,
.suspend= pxa_irda_suspend,
@@ -851,12 +851,12 @@ static struct device_driver pxa_ir_drive
static int __init pxa_irda_init(void)
{
- return driver_register(&pxa_ir_driver);
+ return platform_driver_register(&pxa_ir_driver);
}
static void __exit pxa_irda_exit(void)
{
- driver_unregister(&pxa_ir_driver);
+ platform_driver_unregister(&pxa_ir_driver);
}
module_init(pxa_irda_init);
--
1.4.2.3
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [IrDA] Incorrect TTP header reservation
We must reserve SAR + MAX_HEADER bytes for IrLMP to fit in.
Patch from Jeet Chaudhuri <[EMAIL PROTECTED]>
Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
---
net/irda/irttp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/irda/irttp.c b/net/irda/irttp.c
index 252f110..03504f3 100644
--- a/net/irda/irttp.c
+++ b/net/irda/irttp.c
@@ -1100,7 +1100,7 @@ int irttp_connect_request(struct tsap_cb
return -ENOMEM;
/* Reserve space for MUX_CONTROL and LAP header */
- skb_reserve(tx_skb, TTP_MAX_HEADER);
+ skb_reserve(tx_skb, TTP_MAX_HEADER + TTP_SAR_HEADER);
} else {
tx_skb = userdata;
/*
@@ -1349,7 +1349,7 @@ int irttp_connect_response(struct tsap_c
return -ENOMEM;
/* Reserve space for MUX_CONTROL and LAP header */
- skb_reserve(tx_skb, TTP_MAX_HEADER);
+ skb_reserve(tx_skb, TTP_MAX_HEADER + TTP_SAR_HEADER);
} else {
tx_skb = userdata;
/*
--
1.4.2.3
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 6/7] d80211: fix invalid check for sub interface type AP
We should be checking the type member, not the raw pointer.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -1996,7 +1996,7 @@ static int ieee80211_ioctl_siwscan(struc
sdata->type == IEEE80211_IF_TYPE_IBSS) {
ssid = sdata->u.sta.ssid;
ssid_len = sdata->u.sta.ssid_len;
- } else if (sdata == IEEE80211_IF_TYPE_AP) {
+ } else if (sdata->type == IEEE80211_IF_TYPE_AP) {
ssid = sdata->u.ap.ssid;
ssid_len = sdata->u.ap.ssid_len;
} else
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/7] d80211: set default_wep_only dynamically
Without this change d80211 relies on userspace to let it know when it can
configure default wep keys. It is always safe to set default_wep_only if there
is a single station interface. This allows for hardware accelleration for
the case of a single station interface.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/ieee80211_i.h
===
--- wireless-dev.orig/net/d80211/ieee80211_i.h
+++ wireless-dev/net/d80211/ieee80211_i.h
@@ -607,6 +607,7 @@ extern const struct iw_handler_def ieee8
int ieee80211_set_hw_encryption(struct net_device *dev,
struct sta_info *sta, u8 addr[ETH_ALEN],
struct ieee80211_key *key);
+void ieee80211_update_default_wep_only(struct ieee80211_local *local);
/* ieee80211_scan.c */
void ieee80211_init_scan(struct ieee80211_local *local);
Index: wireless-dev/net/d80211/ieee80211_iface.c
===
--- wireless-dev.orig/net/d80211/ieee80211_iface.c
+++ wireless-dev/net/d80211/ieee80211_iface.c
@@ -97,6 +97,7 @@ int ieee80211_if_add(struct net_device *
}
list_add(&sdata->list, &local->sub_if_list);
+ ieee80211_update_default_wep_only(local);
return 0;
@@ -164,6 +165,7 @@ void ieee80211_if_del_mgmt(struct ieee80
void ieee80211_if_set_type(struct net_device *dev, int type)
{
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ struct ieee80211_local *local = dev->ieee80211_ptr;
sdata->type = type;
switch (type) {
@@ -205,6 +207,7 @@ void ieee80211_if_set_type(struct net_de
dev->name, __FUNCTION__, type);
}
ieee80211_sysfs_change_if_type(dev);
+ ieee80211_update_default_wep_only(local);
}
/* Must be called with rtnl lock held. */
@@ -329,6 +332,7 @@ int ieee80211_if_remove(struct net_devic
strcmp(name, sdata->dev->name) == 0 &&
sdata->dev != local->mdev) {
__ieee80211_if_del(local, sdata);
+ ieee80211_update_default_wep_only(local);
return 0;
}
}
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -2357,6 +2357,36 @@ static int ieee80211_ioctl_default_wep_o
}
+void ieee80211_update_default_wep_only(struct ieee80211_local *local)
+{
+ int i = 0;
+ struct ieee80211_sub_if_data *sdata;
+
+ spin_lock_bh(&local->sub_if_lock);
+ list_for_each_entry(sdata, &local->sub_if_list, list) {
+
+ if (sdata->dev == local->mdev)
+ continue;
+
+ /* If there is an AP interface then depend on userspace to
+ set default_wep_only correctly. */
+ if (sdata->type == IEEE80211_IF_TYPE_AP) {
+ spin_unlock_bh(&local->sub_if_lock);
+ return;
+ }
+
+ i++;
+ }
+
+ if (i <= 1)
+ ieee80211_ioctl_default_wep_only(local, 1);
+ else
+ ieee80211_ioctl_default_wep_only(local, 0);
+
+ spin_unlock_bh(&local->sub_if_lock);
+}
+
+
static int ieee80211_ioctl_prism2_param(struct net_device *dev,
struct iw_request_info *info,
void *wrqu, char *extra)
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 3/7] d80211: fix potential interface name overflow
dev->name and ndev->name are both IFNAMSIZ in length, the ".%d" is
not guarenteed to fit in ndev->name.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/ieee80211_iface.c
===
--- wireless-dev.orig/net/d80211/ieee80211_iface.c
+++ wireless-dev/net/d80211/ieee80211_iface.c
@@ -56,7 +56,8 @@ int ieee80211_if_add(struct net_device *
if (strlen(name) == 0) {
i = 0;
do {
- sprintf(ndev->name, "%s.%d", dev->name, i++);
+ snprintf(ndev->name, sizeof(ndev->name), "%s.%d",
+dev->name, i++);
tmp_dev = dev_get_by_name(ndev->name);
if (!tmp_dev)
break;
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 4/7] d80211: fix potential invalid array index returning key information
sdata->keys[] has NUM_DEFAULT_KEYS elements, don't access past that.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -803,7 +803,7 @@ static int ieee80211_ioctl_get_encryptio
param->sta_addr[2] == 0xff && param->sta_addr[3] == 0xff &&
param->sta_addr[4] == 0xff && param->sta_addr[5] == 0xff) {
sta = NULL;
- if (param->u.crypt.idx > NUM_DEFAULT_KEYS) {
+ if (param->u.crypt.idx >= NUM_DEFAULT_KEYS) {
param->u.crypt.idx = sdata->default_key ?
sdata->default_key->keyidx : 0;
return 0;
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 7/7] d80211: do not pass an invalid key index to set_key()
If a hardware key has not been configured then there is no point
to calling DISABLE_KEY.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -612,7 +612,7 @@ static int ieee80211_set_encryption(stru
if (alg == ALG_NONE) {
keyconf = NULL;
- if (try_hwaccel && key && local->ops->set_key &&
+ if (try_hwaccel && key && key->hw_key_idx != -1 &&
local->ops->set_key &&
(keyconf = ieee80211_key_data2conf(local, key)) != NULL &&
local->ops->set_key(local_to_hw(local), DISABLE_KEY,
sta_addr, keyconf, sta ? sta->aid : 0)) {
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] memory barrier cleanups
From: Ralf Baechle <[EMAIL PROTECTED]> Date: Wed, 6 Dec 2006 21:49:46 + > I believe all the below memory barriers only matter on SMP so therefore > the smp_* variant of the barrier should be used. > > I'm wondering if the barrier in net/ipv4/inet_timewait_sock.c should be > dropped entirely. schedule_work's implementation currently implies a > memory barrier and I think sane semantics of schedule_work() should imply > a memory barrier, as needed so the caller shouldn't have to worry. > It's not quite obvious why the barrier in net/packet/af_packet.c is > needed; maybe it should be implied through flush_dcache_page? > I'll check out that timewait sock case later, but AF_PACKET mmap() is totally broken on D-cache aliasing architectures. Many years ago I tried to fix this up with Alexey but those talks went nowhere :) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 5/7] d80211: remove unused references to sub interface data
In these three cases the pointer returned by IEEE80211_DEV_TO_SUB_IF()
is never used.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wireless-dev/net/d80211/ieee80211.c
@@ -1362,11 +1362,9 @@ static int ieee80211_master_start_xmit(s
struct ieee80211_tx_control control;
struct ieee80211_tx_packet_data *pkt_data;
struct net_device *odev = NULL;
- struct ieee80211_sub_if_data *sdata, *osdata;
+ struct ieee80211_sub_if_data *osdata;
int ret;
- sdata = IEEE80211_DEV_TO_SUB_IF(dev);
-
/*
* copy control out of the skb so other people can use skb->cb
*/
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -407,10 +407,8 @@ static int ieee80211_ioctl_get_info_sta(
if (param->sta_addr[0] == 0xff && param->sta_addr[1] == 0xff &&
param->sta_addr[2] == 0xff && param->sta_addr[3] == 0xff &&
param->sta_addr[4] == 0xff && param->sta_addr[5] == 0xff) {
- struct ieee80211_sub_if_data *sdata;
struct net_device_stats *stats;
- sdata = IEEE80211_DEV_TO_SUB_IF(dev);
stats = ieee80211_dev_stats(local->mdev);
param->u.get_info_sta.rx_bytes = stats->rx_bytes;
param->u.get_info_sta.tx_bytes = stats->tx_bytes;
Index: wireless-dev/net/d80211/ieee80211_iface.c
===
--- wireless-dev.orig/net/d80211/ieee80211_iface.c
+++ wireless-dev/net/d80211/ieee80211_iface.c
@@ -42,7 +42,7 @@ int ieee80211_if_add(struct net_device *
{
struct net_device *ndev, *tmp_dev;
struct ieee80211_local *local = dev->ieee80211_ptr;
- struct ieee80211_sub_if_data *sdata = NULL, *sdata_parent;
+ struct ieee80211_sub_if_data *sdata = NULL;
int ret;
int i;
@@ -83,7 +83,6 @@ int ieee80211_if_add(struct net_device *
sdata->type = IEEE80211_IF_TYPE_AP;
sdata->dev = ndev;
sdata->local = local;
- sdata_parent = IEEE80211_DEV_TO_SUB_IF(dev);
ieee80211_if_sdata_init(sdata);
ret = register_netdevice(ndev);
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/7] d80211: allow for hardware crypto of default keys
Remove incorrect prohibition of hardware crypto support. This was
originally present to prevent hardware crypto when more than one
station interface was created for a single hardware device, the code
in question is no longer correct and should be removed.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -537,9 +537,7 @@ static int ieee80211_set_encryption(stru
}
key = sdata->keys[idx];
- /* Disable hwaccel for default keys when the interface is not
-* the default one.
-* TODO: consider adding hwaccel support for these; at least
+ /* TODO: consider adding hwaccel support for these; at least
* Atheros key cache should be able to handle this since AP is
* only transmitting frames with default keys. */
/* FIX: hw key cache can be used when only one virtual
@@ -548,11 +546,6 @@ static int ieee80211_set_encryption(stru
* must be used. This should be done automatically
* based on configured station devices. For the time
* being, this can be only set at compile time. */
- /* FIXME: There is no more anything like "default
-* interface". We should try hwaccel if there is just one
-* interface - for now, hwaccel is unconditionaly
-* disabled. */
- try_hwaccel = 0;
} else {
set_tx_key = 0;
if (idx != 0) {
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] softmac: Fixed handling of deassociation from AP
Michael Buesch wrote: On Wednesday 06 December 2006 22:51, Ulrich Kunitz wrote: On 06-12-06 21:52 Michael Buesch wrote: On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote: On 06-12-06 18:52 Michael Buesch wrote: All data in mac->associnfo is protected by mac->associnfo->mutex and _not_ mac->lock. Are you sure? Yes I am. One can find for instance the following function in ieee80211softmac_assoc.c: This is not the first time we notice that locking is completely broken in softmac. ;) So the right thing would be to add another work function (*_start_reassoc_work) which sets the associating variable and calls then *_assoc_work? Ah, well. I think the right thing doesn't exist. Even if you replace the lock by the mutex, it's still racy. The whole lock design of softmac is broken and racy and we can't simply fix that with a oneliner. I'd say, John, apply the original patch as-is, as it does more good than harm. Basically, I just wanted to point out that this is not race-free. But I think we can live with it. In struct ieee80211softmac_device, there are the following entries: ... spinlock_t lock; u8 running; /* SoftMAC started? */ u8 scanning; struct ieee80211softmac_scaninfo *scaninfo; struct ieee80211softmac_assoc_info associnfo; struct ieee80211softmac_bss_info bssinfo; ... In struct ieee80211softmac_assoc_info, we have the following entries: struct mutex mutex; struct ieee80211softmac_essid associate_essid; char bssid[ETH_ALEN]; u8 static_essid; u8 short_preamble_available; u8 associating; u8 associated; u8 assoc_wait; u8 bssvalid; u8 bssfixed; Although it has been amply demonstrated in this forum that I know nothing about locking, it seems to me that the mutex protects only the association data; whereas the spinlock protects more data, but does include the association data. If this is correct, then the original posted code is not wrong, only protecting data unnecessarily. Please point out the error in my logic. I'm trying to learn. Larry - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/16] Spidernet Rework RX linked list
Make the hardware perceive the RX descriptor ring as a
null-terminated linked list, instead of a circular ring.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:03:20.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:05:48.0
-0600
@@ -389,9 +389,13 @@ spider_net_prepare_rx_descr(struct spide
card->spider_stats.rx_iommu_map_error++;
descr->dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
} else {
+ descr->next_descr_addr = 0;
wmb();
descr->dmac_cmd_status = SPIDER_NET_DESCR_CARDOWNED |
SPIDER_NET_DMAC_NOINTR_COMPLETE;
+
+ wmb();
+ descr->prev->next_descr_addr = descr->bus_addr;
}
return 0;
@@ -1676,12 +1680,6 @@ spider_net_open(struct net_device *netde
+ card->num_tx_desc * sizeof(struct
spider_net_descr),
card->num_rx_desc);
- descr = card->rx_chain.head;
- do {
- descr->next_descr_addr = descr->next->bus_addr;
- descr = descr->next;
- } while (descr != card->rx_chain.head);
-
/* allocate rx skbs */
if (spider_net_alloc_rx_skbs(card))
goto alloc_skbs_failed;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/16] Spidernet RX Debugging printout
Add some debugging and error printing.
The show_rx_chain() prints out the status of the rx chain,
which shows that the status of the descriptors gets
messed up after the second & subsequent RX ramfulls.
Print out contents of bad packets if error occurs.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 47 +++
1 file changed, 47 insertions(+)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:03:18.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:20.0
-0600
@@ -936,6 +936,34 @@ spider_net_pass_skb_up(struct spider_net
card->netdev_stats.rx_bytes += skb->len;
}
+#ifdef DEBUG
+static void show_rx_chain(struct spider_net_card *card)
+{
+ struct spider_net_descr_chain *chain = &card->rx_chain;
+ struct spider_net_descr *start= chain->tail;
+ struct spider_net_descr *descr= start;
+ int status;
+
+ int cnt = 0;
+ int cstat = spider_net_get_descr_status(descr);
+ printk(KERN_INFO "RX chain tail at descr=%ld\n",
+(start - card->descr) - card->num_tx_desc);
+ status = cstat;
+ do
+ {
+ status = spider_net_get_descr_status(descr);
+ if (cstat != status) {
+ printk(KERN_INFO "Have %d descrs with stat=x%08x\n",
cnt, cstat);
+ cstat = status;
+ cnt = 0;
+ }
+ cnt ++;
+ descr = descr->next;
+ } while (descr != start);
+ printk(KERN_INFO "Last %d descrs with stat=x%08x\n", cnt, cstat);
+}
+#endif
+
/**
* spider_net_decode_one_descr - Processes an RX descriptor
* @card: card structure
@@ -1006,6 +1034,25 @@ spider_net_decode_one_descr(struct spide
goto bad_desc;
}
+ if (descr->dmac_cmd_status & 0xfefe) {
+ pr_err("%s: bad status, cmd_status=x%08x\n",
+ card->netdev->name,
+ descr->dmac_cmd_status);
+ pr_err("buf_addr=x%08x\n", descr->buf_addr);
+ pr_err("buf_size=x%08x\n", descr->buf_size);
+ pr_err("next_descr_addr=x%08x\n", descr->next_descr_addr);
+ pr_err("result_size=x%08x\n", descr->result_size);
+ pr_err("valid_size=x%08x\n", descr->valid_size);
+ pr_err("data_status=x%08x\n", descr->data_status);
+ pr_err("data_error=x%08x\n", descr->data_error);
+ pr_err("bus_addr=x%08x\n", descr->bus_addr);
+ pr_err("which=%ld\n",
+ (descr - card->descr) - card->num_tx_desc);
+
+ card->spider_stats.rx_desc_error++;
+ goto bad_desc;
+ }
+
/* Ok, we've got a packet in descr */
spider_net_pass_skb_up(descr, card, napi);
descr->dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/16] Spidernet Avoid possible RX chain corruption
Delete possible source of chain corruption; the hardware already knows the location of the tail, and writing it again is likely to mess it up. Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> Cc: James K Lewis <[EMAIL PROTECTED]> Cc: Arnd Bergmann <[EMAIL PROTECTED]> drivers/net/spider_net.c |1 - 1 file changed, 1 deletion(-) Index: linux-2.6.19-git7/drivers/net/spider_net.c === --- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06 16:03:16.0 -0600 +++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:18.0 -0600 @@ -1195,7 +1195,6 @@ spider_net_handle_rxram_full(struct spid while (spider_net_decode_one_descr(card, 0)); spider_net_refill_rx_chain(card); - spider_net_enable_rxchtails(card); spider_net_enable_rxdmac(card); netif_rx_schedule(card->netdev); spider_net_rx_irq_on(card); - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/16] Spidernet Turn RX irq back on
Re-enable irq's after emptying the RX ring; these had been previously turned off on reception of the rxram_full interrupt. More punctuation cleanup. Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> Cc: James K Lewis <[EMAIL PROTECTED]> Cc: Arnd Bergmann <[EMAIL PROTECTED]> drivers/net/spider_net.c |8 1 file changed, 4 insertions(+), 4 deletions(-) Index: linux-2.6.19-git7/drivers/net/spider_net.c === --- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06 16:03:13.0 -0600 +++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:15.0 -0600 @@ -1182,12 +1182,11 @@ spider_net_set_mac(struct net_device *ne } /** - * spider_net_handle_rxram_full - cleans up RX ring upon RX RAM full interrupt + * spider_net_handle_rxram_full - Clean RX ring on RX RAM full interrupt * @card: card structure * - * spider_net_handle_rxram_full empties the RX ring so that spider can put - * more packets in it and empty its RX RAM. This is called in bottom half - * context + * Empty the RX ring so that the hardware can put more packets + * in it and empty its RX RAM. This is called in bottom half context. */ static void spider_net_handle_rxram_full(struct spider_net_card *card) @@ -1198,6 +1197,7 @@ spider_net_handle_rxram_full(struct spid spider_net_enable_rxchtails(card); spider_net_enable_rxdmac(card); netif_rx_schedule(card->netdev); + spider_net_rx_irq_on(card); } /** - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/16] Spidernet Memory barrier
Add memory barrier to make sure that the rest of the
RX descriptor state is flushed to memory before we tell
the hardware that its ready to go.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:03:15.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:16.0
-0600
@@ -389,6 +389,7 @@ spider_net_prepare_rx_descr(struct spide
card->spider_stats.rx_iommu_map_error++;
descr->dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
} else {
+ wmb();
descr->dmac_cmd_status = SPIDER_NET_DESCR_CARDOWNED |
SPIDER_NET_DMAC_NOINTR_COMPLETE;
}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/16] Spidernet RX Chain tail
Tell the hardware the location of the rx ring tail. More punctuation cleanup. Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> Cc: James K Lewis <[EMAIL PROTECTED]> Cc: Arnd Bergmann <[EMAIL PROTECTED]> drivers/net/spider_net.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) Index: linux-2.6.19-git7/drivers/net/spider_net.c === --- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06 16:03:11.0 -0600 +++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:13.0 -0600 @@ -457,10 +457,10 @@ spider_net_refill_rx_chain(struct spider } /** - * spider_net_alloc_rx_skbs - allocates rx skbs in rx descriptor chains + * spider_net_alloc_rx_skbs - Allocates rx skbs in rx descriptor chains * @card: card structure * - * returns 0 on success, <0 on failure + * Returns 0 on success, <0 on failure. */ static int spider_net_alloc_rx_skbs(struct spider_net_card *card) @@ -471,17 +471,18 @@ spider_net_alloc_rx_skbs(struct spider_n result = -ENOMEM; chain = &card->rx_chain; - /* put at least one buffer into the chain. if this fails, -* we've got a problem. if not, spider_net_refill_rx_chain -* will do the rest at the end of this function */ + /* Put at least one buffer into the chain. if this fails, +* we've got a problem. If not, spider_net_refill_rx_chain +* will do the rest at the end of this function. */ if (spider_net_prepare_rx_descr(card, chain->head)) goto error; else chain->head = chain->head->next; - /* this will allocate the rest of the rx buffers; if not, it's -* business as usual later on */ + /* This will allocate the rest of the rx buffers; +* if not, it's business as usual later on. */ spider_net_refill_rx_chain(card); + spider_net_enable_rxchtails(card); spider_net_enable_rxdmac(card); return 0; - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/16] Spidernet Remove unused variable
Remove unused variable; this makes code easier to read.
Tweak commentary.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:03:09.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:11.0
-0600
@@ -341,17 +341,16 @@ spider_net_free_rx_chain_contents(struct
* @card: card structure
* @descr: descriptor to re-init
*
- * return 0 on succes, <0 on failure
+ * Return 0 on succes, <0 on failure.
*
- * allocates a new rx skb, iommu-maps it and attaches it to the descriptor.
- * Activate the descriptor state-wise
+ * Allocates a new rx skb, iommu-maps it and attaches it to the
+ * descriptor. Mark the descriptor as activated, ready-to-use.
*/
static int
spider_net_prepare_rx_descr(struct spider_net_card *card,
struct spider_net_descr *descr)
{
dma_addr_t buf;
- int error = 0;
int offset;
int bufsize;
@@ -379,7 +378,7 @@ spider_net_prepare_rx_descr(struct spide
(SPIDER_NET_RXBUF_ALIGN - 1);
if (offset)
skb_reserve(descr->skb, SPIDER_NET_RXBUF_ALIGN - offset);
- /* io-mmu-map the skb */
+ /* iommu-map the skb */
buf = pci_map_single(card->pdev, descr->skb->data,
SPIDER_NET_MAX_FRAME, PCI_DMA_FROMDEVICE);
descr->buf_addr = buf;
@@ -394,7 +393,7 @@ spider_net_prepare_rx_descr(struct spide
SPIDER_NET_DMAC_NOINTR_COMPLETE;
}
- return error;
+ return 0;
}
/**
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/16] Spidernet RX Refill
The invocation of the rx ring refill routine is haphazard;
centralize and make its usage consistent.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:03:06.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:08.0
-0600
@@ -968,8 +968,6 @@ spider_net_decode_one_descr(struct spide
if (status == SPIDER_NET_DESCR_NOT_IN_USE) {
/* not initialized yet, the ring must be empty */
spin_unlock_irqrestore(&chain->lock, flags);
- spider_net_refill_rx_chain(card);
- spider_net_enable_rxdmac(card);
return 0;
}
@@ -1058,6 +1056,7 @@ spider_net_poll(struct net_device *netde
netdev->quota -= packets_done;
*budget -= packets_done;
spider_net_refill_rx_chain(card);
+ spider_net_enable_rxdmac(card);
/* if all packets are in the stack, enable interrupts and return 0 */
/* if not, return 1 */
@@ -1197,11 +1196,9 @@ spider_net_set_mac(struct net_device *ne
static void
spider_net_handle_rxram_full(struct spider_net_card *card)
{
- int rc = 1;
- while (rc) {
- rc = spider_net_decode_one_descr(card, 0);
- spider_net_refill_rx_chain(card);
- }
+ while (spider_net_decode_one_descr(card, 0));
+
+ spider_net_refill_rx_chain(card);
spider_net_enable_rxchtails(card);
spider_net_enable_rxdmac(card);
netif_rx_schedule(card->netdev);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 9/16] Spidernet Merge error branches
Two distinct if() statements have the ame body. Merge the clauses.
Also clean up punctuation, capitalization, etc.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:03:08.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:09.0
-0600
@@ -936,15 +936,16 @@ spider_net_pass_skb_up(struct spider_net
}
/**
- * spider_net_decode_one_descr - processes an rx descriptor
+ * spider_net_decode_one_descr - Processes an RX descriptor
* @card: card structure
* @napi: whether caller is in NAPI context
*
- * returns 1 if a packet has been sent to the stack, otherwise 0
+ * Returns 1 if a packet has been sent to the stack, otherwise 0.
*
- * processes an rx descriptor by iommu-unmapping the data buffer and passing
- * the packet up to the stack. This function is called in softirq
- * context, e.g. either bottom half from interrupt or NAPI polling context
+ * Processes an RX descriptor by iommu-unmapping the data buffer
+ * and passing the packet up to the stack. This function is called
+ * in a softirq context, e.g. either bottom half from interrupt or
+ * NAPI polling context.
*/
static int
spider_net_decode_one_descr(struct spider_net_card *card, int napi)
@@ -959,23 +960,18 @@ spider_net_decode_one_descr(struct spide
status = spider_net_get_descr_status(descr);
- if (status == SPIDER_NET_DESCR_CARDOWNED) {
- /* nothing in the descriptor yet */
+ /* Nothing in the descriptor yet, or ring is empty */
+ if ( (status == SPIDER_NET_DESCR_CARDOWNED) ||
+(status == SPIDER_NET_DESCR_NOT_IN_USE) ) {
spin_unlock_irqrestore(&chain->lock, flags);
return 0;
}
- if (status == SPIDER_NET_DESCR_NOT_IN_USE) {
- /* not initialized yet, the ring must be empty */
- spin_unlock_irqrestore(&chain->lock, flags);
- return 0;
- }
-
- /* descriptor definitively used -- move on tail */
+ /* Descriptor definitively used -- move on tail. */
chain->tail = descr->next;
spin_unlock_irqrestore(&chain->lock, flags);
- /* unmap descriptor */
+ /* Unmap descriptor. */
pci_unmap_single(card->pdev, descr->buf_addr,
SPIDER_NET_MAX_FRAME, PCI_DMA_FROMDEVICE);
@@ -998,7 +994,7 @@ spider_net_decode_one_descr(struct spide
goto bad_desc;
}
- /* The cases we'll throw away the packet immediately */
+ /* The cases we'll throw away the packet immediately. */
if (descr->data_error & SPIDER_NET_DESTROY_RX_FLAGS) {
if (netif_msg_rx_err(card))
pr_err("%s: error in received descriptor found, "
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/16] Spidernet Cleanup return codes
Simplify the somewhat convoluted use of return codes
in the rx buffre handling.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:03:04.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:06.0
-0600
@@ -882,12 +882,10 @@ spider_net_do_ioctl(struct net_device *n
* @card: card structure
* @napi: whether caller is in NAPI context
*
- * returns 1 on success, 0 if no packet was passed to the stack
- *
* Fills out skb structure and passes the data to the stack.
* The descriptor state is not changed.
*/
-static int
+static void
spider_net_pass_skb_up(struct spider_net_descr *descr,
struct spider_net_card *card, int napi)
{
@@ -935,8 +933,6 @@ spider_net_pass_skb_up(struct spider_net
/* update netdevice statistics */
card->netdev_stats.rx_packets++;
card->netdev_stats.rx_bytes += skb->len;
-
- return 1;
}
/**
@@ -956,7 +952,6 @@ spider_net_decode_one_descr(struct spide
struct spider_net_descr_chain *chain = &card->rx_chain;
struct spider_net_descr *descr;
int status;
- int result;
unsigned long flags;
spin_lock_irqsave(&chain->lock, flags);
@@ -982,8 +977,6 @@ spider_net_decode_one_descr(struct spide
chain->tail = descr->next;
spin_unlock_irqrestore(&chain->lock, flags);
- result = 0;
-
/* unmap descriptor */
pci_unmap_single(card->pdev, descr->buf_addr,
SPIDER_NET_MAX_FRAME, PCI_DMA_FROMDEVICE);
@@ -995,8 +988,7 @@ spider_net_decode_one_descr(struct spide
pr_err("%s: dropping RX descriptor with state %d\n",
card->netdev->name, status);
card->netdev_stats.rx_dropped++;
- dev_kfree_skb_irq(descr->skb);
- goto refill;
+ goto bad_desc;
}
if ( (status != SPIDER_NET_DESCR_COMPLETE) &&
@@ -1005,8 +997,7 @@ spider_net_decode_one_descr(struct spide
pr_err("%s: RX descriptor with unkown state %d\n",
card->netdev->name, status);
card->spider_stats.rx_desc_unk_state++;
- dev_kfree_skb_irq(descr->skb);
- goto refill;
+ goto bad_desc;
}
/* The cases we'll throw away the packet immediately */
@@ -1017,16 +1008,18 @@ spider_net_decode_one_descr(struct spide
card->netdev->name,
descr->data_status, descr->data_error);
card->spider_stats.rx_desc_error++;
- dev_kfree_skb_irq(descr->skb);
- goto refill;
+ goto bad_desc;
}
- /* ok, we've got a packet in descr */
- result = spider_net_pass_skb_up(descr, card, napi);
-refill:
- /* change the descriptor state: */
+ /* Ok, we've got a packet in descr */
+ spider_net_pass_skb_up(descr, card, napi);
descr->dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
- return result;
+ return 1;
+
+bad_desc:
+ dev_kfree_skb_irq(descr->skb);
+ descr->dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
+ return 0;
}
/**
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/16] Spidernet another skb mem leak
Another skb leak in an error branch. Fix this by adding
call to dev_kfree_skb_irq() after moving to a more
appropriate spot.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:03:00.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:04.0
-0600
@@ -897,19 +897,8 @@ spider_net_pass_skb_up(struct spider_net
data_status = descr->data_status;
data_error = descr->data_error;
-
netdev = card->netdev;
- /* the cases we'll throw away the packet immediately */
- if (data_error & SPIDER_NET_DESTROY_RX_FLAGS) {
- if (netif_msg_rx_err(card))
- pr_err("error in received descriptor found, "
- "data_status=x%08x, data_error=x%08x\n",
- data_status, data_error);
- card->spider_stats.rx_desc_error++;
- return 0;
- }
-
skb = descr->skb;
skb->dev = netdev;
skb_put(skb, descr->valid_size);
@@ -1020,6 +1009,18 @@ spider_net_decode_one_descr(struct spide
goto refill;
}
+ /* The cases we'll throw away the packet immediately */
+ if (descr->data_error & SPIDER_NET_DESTROY_RX_FLAGS) {
+ if (netif_msg_rx_err(card))
+ pr_err("%s: error in received descriptor found, "
+ "data_status=x%08x, data_error=x%08x\n",
+ card->netdev->name,
+ descr->data_status, descr->data_error);
+ card->spider_stats.rx_desc_error++;
+ dev_kfree_skb_irq(descr->skb);
+ goto refill;
+ }
+
/* ok, we've got a packet in descr */
result = spider_net_pass_skb_up(descr, card, napi);
refill:
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/16] Spidernet RX skb mem leak
One of the unlikely error branches has an skb memory leak.
Fix this by handling the error conditions consistently.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:02:58.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:00.0
-0600
@@ -884,8 +884,8 @@ spider_net_do_ioctl(struct net_device *n
*
* returns 1 on success, 0 if no packet was passed to the stack
*
- * iommu-unmaps the skb, fills out skb structure and passes the data to the
- * stack. The descriptor state is not changed.
+ * Fills out skb structure and passes the data to the stack.
+ * The descriptor state is not changed.
*/
static int
spider_net_pass_skb_up(struct spider_net_descr *descr,
@@ -900,10 +900,6 @@ spider_net_pass_skb_up(struct spider_net
netdev = card->netdev;
- /* unmap descriptor */
- pci_unmap_single(card->pdev, descr->buf_addr, SPIDER_NET_MAX_FRAME,
- PCI_DMA_FROMDEVICE);
-
/* the cases we'll throw away the packet immediately */
if (data_error & SPIDER_NET_DESTROY_RX_FLAGS) {
if (netif_msg_rx_err(card))
@@ -998,6 +994,11 @@ spider_net_decode_one_descr(struct spide
spin_unlock_irqrestore(&chain->lock, flags);
result = 0;
+
+ /* unmap descriptor */
+ pci_unmap_single(card->pdev, descr->buf_addr,
+ SPIDER_NET_MAX_FRAME, PCI_DMA_FROMDEVICE);
+
if ( (status == SPIDER_NET_DESCR_RESPONSE_ERROR) ||
(status == SPIDER_NET_DESCR_PROTECTION_ERROR) ||
(status == SPIDER_NET_DESCR_FORCE_END) ) {
@@ -1005,8 +1006,6 @@ spider_net_decode_one_descr(struct spide
pr_err("%s: dropping RX descriptor with state %d\n",
card->netdev->name, status);
card->netdev_stats.rx_dropped++;
- pci_unmap_single(card->pdev, descr->buf_addr,
- SPIDER_NET_MAX_FRAME, PCI_DMA_FROMDEVICE);
dev_kfree_skb_irq(descr->skb);
goto refill;
}
@@ -1014,9 +1013,10 @@ spider_net_decode_one_descr(struct spide
if ( (status != SPIDER_NET_DESCR_COMPLETE) &&
(status != SPIDER_NET_DESCR_FRAME_END) ) {
if (netif_msg_rx_err(card))
- pr_err("%s: RX descriptor with state %d\n",
+ pr_err("%s: RX descriptor with unkown state %d\n",
card->netdev->name, status);
card->spider_stats.rx_desc_unk_state++;
+ dev_kfree_skb_irq(descr->skb);
goto refill;
}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/16] Spidernet Refactor RX refill
Refactor how spider_net_refill_rx_chain() is called.
No functional change; this just simplifies the code
by moving the subroutine call to a more appropriate spot.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:01:49.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:02:58.0
-0600
@@ -1023,10 +1023,8 @@ spider_net_decode_one_descr(struct spide
/* ok, we've got a packet in descr */
result = spider_net_pass_skb_up(descr, card, napi);
refill:
- descr->dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
/* change the descriptor state: */
- if (!napi)
- spider_net_refill_rx_chain(card);
+ descr->dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
return result;
}
@@ -1205,8 +1203,11 @@ spider_net_set_mac(struct net_device *ne
static void
spider_net_handle_rxram_full(struct spider_net_card *card)
{
- while (spider_net_decode_one_descr(card, 0))
- ;
+ int rc = 1;
+ while (rc) {
+ rc = spider_net_decode_one_descr(card, 0);
+ spider_net_refill_rx_chain(card);
+ }
spider_net_enable_rxchtails(card);
spider_net_enable_rxdmac(card);
netif_rx_schedule(card->netdev);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/16] Spidernet RX Locking
The RX packet handling can be called from several
places, yet does not protect the rx ring structure.
This patch places the ring buffer pointers under a lock.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
15:58:27.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:01:49.0
-0600
@@ -969,28 +969,33 @@ static int
spider_net_decode_one_descr(struct spider_net_card *card, int napi)
{
struct spider_net_descr_chain *chain = &card->rx_chain;
- struct spider_net_descr *descr = chain->tail;
+ struct spider_net_descr *descr;
int status;
int result;
+ unsigned long flags;
+
+ spin_lock_irqsave(&chain->lock, flags);
+ descr = chain->tail;
status = spider_net_get_descr_status(descr);
if (status == SPIDER_NET_DESCR_CARDOWNED) {
/* nothing in the descriptor yet */
- result=0;
- goto out;
+ spin_unlock_irqrestore(&chain->lock, flags);
+ return 0;
}
if (status == SPIDER_NET_DESCR_NOT_IN_USE) {
/* not initialized yet, the ring must be empty */
+ spin_unlock_irqrestore(&chain->lock, flags);
spider_net_refill_rx_chain(card);
spider_net_enable_rxdmac(card);
- result=0;
- goto out;
+ return 0;
}
/* descriptor definitively used -- move on tail */
chain->tail = descr->next;
+ spin_unlock_irqrestore(&chain->lock, flags);
result = 0;
if ( (status == SPIDER_NET_DESCR_RESPONSE_ERROR) ||
@@ -1022,7 +1027,6 @@ refill:
/* change the descriptor state: */
if (!napi)
spider_net_refill_rx_chain(card);
-out:
return result;
}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/16] Spidernet add net_ratelimit to suppress long output
This patch adds net_ratelimit to many of the printks
in order to limit extraneous warning messages
This patch supercedes all previous ratelimit patches.
This has been tested, please apply.
From: James K Lewis <[EMAIL PROTECTED]>
Signed-off-by: James K Lewis <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 11 +--
drivers/net/spider_net.h |2 +-
2 files changed, 6 insertions(+), 7 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
15:56:20.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 15:58:27.0
-0600
@@ -1008,11 +1008,10 @@ spider_net_decode_one_descr(struct spide
if ( (status != SPIDER_NET_DESCR_COMPLETE) &&
(status != SPIDER_NET_DESCR_FRAME_END) ) {
- if (netif_msg_rx_err(card)) {
+ if (netif_msg_rx_err(card))
pr_err("%s: RX descriptor with state %d\n",
card->netdev->name, status);
- card->spider_stats.rx_desc_unk_state++;
- }
+ card->spider_stats.rx_desc_unk_state++;
goto refill;
}
@@ -1331,7 +1330,7 @@ spider_net_handle_error_irq(struct spide
case SPIDER_NET_GRFAFLLINT: /* fallthrough */
case SPIDER_NET_GRMFLLINT:
if (netif_msg_intr(card) && net_ratelimit())
- pr_debug("Spider RX RAM full, incoming packets "
+ pr_err("Spider RX RAM full, incoming packets "
"might be discarded!\n");
spider_net_rx_irq_off(card);
tasklet_schedule(&card->rxram_full_tl);
@@ -1349,7 +1348,7 @@ spider_net_handle_error_irq(struct spide
case SPIDER_NET_GDCDCEINT: /* fallthrough */
case SPIDER_NET_GDBDCEINT: /* fallthrough */
case SPIDER_NET_GDADCEINT:
- if (netif_msg_intr(card))
+ if (netif_msg_intr(card) && net_ratelimit())
pr_err("got descriptor chain end interrupt, "
"restarting DMAC %c.\n",
'D'-(i-SPIDER_NET_GDDDCEINT)/3);
@@ -1420,7 +1419,7 @@ spider_net_handle_error_irq(struct spide
break;
}
- if ((show_error) && (netif_msg_intr(card)))
+ if ((show_error) && (netif_msg_intr(card)) && net_ratelimit())
pr_err("Got error interrupt on %s, GHIINT0STS = 0x%08x, "
"GHIINT1STS = 0x%08x, GHIINT2STS = 0x%08x\n",
card->netdev->name,
Index: linux-2.6.19-git7/drivers/net/spider_net.h
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.h 2006-12-06
15:56:20.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.h 2006-12-06 15:57:28.0
-0600
@@ -24,7 +24,7 @@
#ifndef _SPIDER_NET_H
#define _SPIDER_NET_H
-#define VERSION "1.6 A"
+#define VERSION "1.6 B"
#include "sungem_phy.h"
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/16] Spidernet DMA coalescing
The current driver code performs 512 DMA mappings of a bunch of
32-byte structures. This is silly, as they are all in contiguous
memory. Ths patch changes the code to DMA map the entie area
with just one call.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Acked-by: Joel Schopp <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 107 +++
drivers/net/spider_net.h | 16 ++-
2 files changed, 59 insertions(+), 64 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
15:53:23.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 15:56:20.0
-0600
@@ -269,25 +269,6 @@ spider_net_get_descr_status(struct spide
}
/**
- * spider_net_free_chain - free descriptor chain
- * @card: card structure
- * @chain: address of chain
- *
- */
-static void
-spider_net_free_chain(struct spider_net_card *card,
- struct spider_net_descr_chain *chain)
-{
- struct spider_net_descr *descr;
-
- for (descr = chain->tail; !descr->bus_addr; descr = descr->next) {
- pci_unmap_single(card->pdev, descr->bus_addr,
-SPIDER_NET_DESCR_SIZE, PCI_DMA_BIDIRECTIONAL);
- descr->bus_addr = 0;
- }
-}
-
-/**
* spider_net_init_chain - links descriptor chain
* @card: card structure
* @chain: address of chain
@@ -299,15 +280,15 @@ spider_net_free_chain(struct spider_net_
*
* returns 0 on success, <0 on failure
*/
-static int
+static void
spider_net_init_chain(struct spider_net_card *card,
struct spider_net_descr_chain *chain,
struct spider_net_descr *start_descr,
+ dma_addr_t buf,
int no)
{
int i;
struct spider_net_descr *descr;
- dma_addr_t buf;
descr = start_descr;
memset(descr, 0, sizeof(*descr) * no);
@@ -316,17 +297,12 @@ spider_net_init_chain(struct spider_net_
for (i=0; idmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
- buf = pci_map_single(card->pdev, descr,
-SPIDER_NET_DESCR_SIZE,
-PCI_DMA_BIDIRECTIONAL);
-
- if (pci_dma_mapping_error(buf))
- goto iommu_error;
-
descr->bus_addr = buf;
+ descr->next_descr_addr = 0;
descr->next = descr + 1;
descr->prev = descr - 1;
+ buf += sizeof(struct spider_net_descr);
}
/* do actual circular list */
(descr-1)->next = start_descr;
@@ -335,17 +311,6 @@ spider_net_init_chain(struct spider_net_
spin_lock_init(&chain->lock);
chain->head = start_descr;
chain->tail = start_descr;
-
- return 0;
-
-iommu_error:
- descr = start_descr;
- for (i=0; i < no; i++, descr++)
- if (descr->bus_addr)
- pci_unmap_single(card->pdev, descr->bus_addr,
-SPIDER_NET_DESCR_SIZE,
-PCI_DMA_BIDIRECTIONAL);
- return -ENOMEM;
}
/**
@@ -1652,24 +1617,32 @@ spider_net_open(struct net_device *netde
{
struct spider_net_card *card = netdev_priv(netdev);
struct spider_net_descr *descr;
- int i, result;
+ int result = -ENOMEM;
- result = -ENOMEM;
- if (spider_net_init_chain(card, &card->tx_chain, card->descr,
- card->num_tx_desc))
- goto alloc_tx_failed;
+ card->descr_dma_addr = pci_map_single(card->pdev, card->descr,
+ (card->num_tx_desc+card->num_rx_desc)*sizeof(struct
spider_net_descr),
+PCI_DMA_BIDIRECTIONAL);
+ if (pci_dma_mapping_error(card->descr_dma_addr))
+ return -ENOMEM;
+
+ spider_net_init_chain(card, &card->tx_chain, card->descr,
+ card->descr_dma_addr,
+ card->num_tx_desc);
card->low_watermark = NULL;
/* rx_chain is after tx_chain, so offset is descr + tx_count */
- if (spider_net_init_chain(card, &card->rx_chain,
+ spider_net_init_chain(card, &card->rx_chain,
card->descr + card->num_tx_desc,
- card->num_rx_desc))
- goto alloc_rx_failed;
+ card->descr_dma_addr
+ + card->num_tx_desc * sizeof(struct
spider_net_descr),
+ card->num_rx_desc);
descr = card->rx_chain.head;
- for (i=0; i < card->num_rx_desc; i++, descr++)
+ do {
Re: [IPROUTE2 PATCH][DOC] clarify "ok" and "pass"
On Wed, 06 Dec 2006 12:44:26 -0500 jamal <[EMAIL PROTECTED]> wrote: > > a small one. > I have a few more but just run out of cycles for now; > if you dont mind holding before releasing for a short while so i can > get them out I will appreciate it. > > cheers, > jamal > applied all 4 thanks -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] irlan: fix header build warning
Hi Randy, Thanks for the patch. Looks fine to me. On Wed, Dec 06, 2006 at 11:44:07AM -0800, Randy Dunlap wrote: > From: Randy Dunlap <[EMAIL PROTECTED]> > > Fix compile warning when CONFIG_PROC_FS=n: > > include/net/irda/irlan_filter.h:31: warning: 'struct seq_file' declared > inside parameter list > include/net/irda/irlan_filter.h:31: warning: its scope is only this > definition or declaration, which is probably not what you want > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]> Cheers, Samuel. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] softmac: Fixed handling of deassociation from AP
On Wednesday 06 December 2006 22:51, Ulrich Kunitz wrote: > On 06-12-06 21:52 Michael Buesch wrote: > > > On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote: > > > On 06-12-06 18:52 Michael Buesch wrote: > > > > > > > All data in mac->associnfo is protected by mac->associnfo->mutex > > > > and _not_ mac->lock. > > > > > > Are you sure? > > > > Yes I am. > > > > > One can find for instance the following function in > > > ieee80211softmac_assoc.c: > > > > This is not the first time we notice that locking > > is completely broken in softmac. ;) > > So the right thing would be to add another work function > (*_start_reassoc_work) which sets the associating variable and > calls then *_assoc_work? Ah, well. I think the right thing doesn't exist. Even if you replace the lock by the mutex, it's still racy. The whole lock design of softmac is broken and racy and we can't simply fix that with a oneliner. I'd say, John, apply the original patch as-is, as it does more good than harm. Basically, I just wanted to point out that this is not race-free. But I think we can live with it. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/16] Spidernet RX Misc cleanups and fixes
Andrew, Please apply and forward upstream. This series of 16 small patches consist of mostly of various cleanups, a few fixes, and a clarification of the flow of the RX side of the spidernet ethernet driver. The first patch, though, is a resubmit of an old patch. --linas - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
On 12/6/06, Jiri Benc <[EMAIL PROTECTED]> wrote: On Wed, 6 Dec 2006 15:18:12 -0500, Dmitry Torokhov wrote: > On 12/6/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote: > > Ok, so input device opening should not block the rfkill signal and the rfkill handler > > should still go through with its work unless a different config option indicates that > > userspace wants to handle the event. > > I don't think a config option is a good idea unless by config option > you mean a sysfs attribute. What about using EVIOCGRAB ioctl for this? Will not work when the button is on your USB keyboard ;) -- Dmitry - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Wed, 6 Dec 2006 15:18:12 -0500, Dmitry Torokhov wrote: > On 12/6/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote: > > Ok, so input device opening should not block the rfkill signal and the > > rfkill handler > > should still go through with its work unless a different config option > > indicates that > > userspace wants to handle the event. > > I don't think a config option is a good idea unless by config option > you mean a sysfs attribute. What about using EVIOCGRAB ioctl for this? Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
On 12/6/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote: > > 2 - Hardware key that does not control the hardware radio and does not report anything to userspace > > Kind of uninteresting button ;) And this is the button that rfkill was originally designed for. Laptops with integrated WiFi cards from Ralink have a hardware button that don't send anything to userspace (unless the ACPI event is read) and does not directly control the radio itself. So what does such a button do? I am confused here... ... And this event should be reported by a generic approach right? So it should be similar as with your point 2 below. But this would mean that the driver should create the input device. Or can a driver send the KEY_WIFI event over a main layer without the need of a personal input device? I am not that familiar with the input device layer in the kernel, and this is my first attempt on creating something for it, so I might have missed something. ;) Yes, I think the driver should just create an input device. You may provide a generic implementation for a polled button and have driver instantiate it but I do not think that a single RFkill button device is needed - you won't have too many of them in a single system anyway (I think you will normally have 1, 2 at the most). ... > 3. A device without transmitter but with a button - just register with > input core. Userspace will have to manage state of other devices with > transmitters in response to button presses. This is clear too. Rfkill is only intended for drivers that control a device with a transmitter (WiFi, Bluetooth, IRDA) that have a button that is intended to do something with the radio/transmitter. > Does this make sense? Yes, this was what I intended to do with rfkill, so at that point we have the same goal. I think it is almost the same. I also want support RF devices that can control radio state but lack a button. This is covered by mixing 2) and 3) in kernel and for userspace looks exactly like 2) with a button. ... > > I don't think a config option is a good idea unless by config option > you mean a sysfs attribute. I indeed meant a sysfs attribute. I should have been more clear on this. :) OK :) -- Dmitry - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] softmac: Fixed handling of deassociation from AP
On 06-12-06 21:52 Michael Buesch wrote: > On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote: > > On 06-12-06 18:52 Michael Buesch wrote: > > > > > All data in mac->associnfo is protected by mac->associnfo->mutex > > > and _not_ mac->lock. > > > > Are you sure? > > Yes I am. > > > One can find for instance the following function in > > ieee80211softmac_assoc.c: > > This is not the first time we notice that locking > is completely broken in softmac. ;) So the right thing would be to add another work function (*_start_reassoc_work) which sets the associating variable and calls then *_assoc_work? Uli -- Uli Kunitz - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] memory barrier cleanups
I believe all the below memory barriers only matter on SMP so therefore
the smp_* variant of the barrier should be used.
I'm wondering if the barrier in net/ipv4/inet_timewait_sock.c should be
dropped entirely. schedule_work's implementation currently implies a
memory barrier and I think sane semantics of schedule_work() should imply
a memory barrier, as needed so the caller shouldn't have to worry.
It's not quite obvious why the barrier in net/packet/af_packet.c is
needed; maybe it should be implied through flush_dcache_page?
Ralf
Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
diff --git a/net/core/wireless.c b/net/core/wireless.c
index cb1b872..f69ab7b 100644
--- a/net/core/wireless.c
+++ b/net/core/wireless.c
@@ -2130,7 +2130,7 @@ int iw_handler_set_spy(struct net_device
* The rtnl_lock() make sure we don't race with the other iw_handlers.
* This make sure wireless_spy_update() "see" that the spy list
* is temporarily disabled. */
- wmb();
+ smp_wmb();
/* Are there are addresses to copy? */
if(wrqu->data.length > 0) {
@@ -2159,7 +2159,7 @@ #endif/* WE_SPY_DEBUG */
}
/* Make sure above is updated before re-enabling */
- wmb();
+ smp_wmb();
/* Enable addresses */
spydata->spy_number = wrqu->data.length;
diff --git a/net/ipv4/inet_timewait_sock.c b/net/ipv4/inet_timewait_sock.c
index cdd8053..1a852c2 100644
--- a/net/ipv4/inet_timewait_sock.c
+++ b/net/ipv4/inet_timewait_sock.c
@@ -178,7 +178,7 @@ void inet_twdr_hangman(unsigned long dat
need_timer = 0;
if (inet_twdr_do_twkill_work(twdr, twdr->slot)) {
twdr->thread_slots |= (1 << twdr->slot);
- mb();
+ smp_mb();
schedule_work(&twdr->twkill_work);
need_timer = 1;
} else {
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 9304034..c701f6a 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4235,7 +4235,7 @@ static int tcp_rcv_synsent_state_process
* Change state from SYN-SENT only after copied_seq
* is initialized. */
tp->copied_seq = tp->rcv_nxt;
- mb();
+ smp_mb();
tcp_set_state(sk, TCP_ESTABLISHED);
security_inet_conn_established(sk, skb);
@@ -4483,7 +4483,7 @@ int tcp_rcv_state_process(struct sock *s
case TCP_SYN_RECV:
if (acceptable) {
tp->copied_seq = tp->rcv_nxt;
- mb();
+ smp_mb();
tcp_set_state(sk, TCP_ESTABLISHED);
sk->sk_state_change(sk);
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 08e68b6..da73e8a 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -660,7 +660,7 @@ static int tpacket_rcv(struct sk_buff *s
sll->sll_ifindex = dev->ifindex;
h->tp_status = status;
- mb();
+ smp_mb();
{
struct page *p_start, *p_end;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
Hi, > > > That is my point. Given the fact that there are keys that are not > > > directly connected with the radio switch userspace will have to handle > > > them (wait for events then turn off radios somehow). You are > > > advocating that userspace should also implement 2nd method for buttons > > > that belong to rfkill interface. I do not understand the need for 2nd > > > interface. If you separate radio switch from button code then > > > userspace only need to implement 1st interface and be done with it. > > > You will have set of cards that provide interface to enable/disable > > > their transmitters and set of buttons that signal userspace desired > > > state change. If both switch and button is implemented by the same > > > driver then the driver can implement automatic button handling. > > > Otherwise userspace help is necessary. > > > > Well there are 3 possible hardware key approaches: > > > > 1 - Hardware key that controls the hardware radio, and does not report > > anything to userspace > > Can't do anything here so just ignore it. Ok. > > 2 - Hardware key that does not control the hardware radio and does not > > report anything to userspace > > Kind of uninteresting button ;) And this is the button that rfkill was originally designed for. Laptops with integrated WiFi cards from Ralink have a hardware button that don't send anything to userspace (unless the ACPI event is read) and does not directly control the radio itself. > > 3 - Hardware key that does not control the hardware radio and reports the > > key to userspace > > > > So rfkill should not be used in the case of (1) and (3), but we still need > > something to support (2) > > or should the keys not be handled by userspace and always by the driver? > > This is making rfkill moving slowly away from the generic approach for all > > rfkill keys as the initial > > intention was. > > > > I my "vision" rfkill would represent userspace namageable radio > switch. We have the followng possible configurations: > > 1. A device that does not allow controlling its transmitter from > userspace. The driver should not use/register with rfkill subsystem as > userspace can't do anyhting with it. If device has a button killing > the transmitter the driver can still signal userspace appropriate > event (KEY_WIFI, KEY_BLUETOOTH, etc) if it can detect that button was > presssed so userspace can monitor state of the transmitter and > probably shut down other transmitters to keep everything in sync. And this event should be reported by a generic approach right? So it should be similar as with your point 2 below. But this would mean that the driver should create the input device. Or can a driver send the KEY_WIFI event over a main layer without the need of a personal input device? I am not that familiar with the input device layer in the kernel, and this is my first attempt on creating something for it, so I might have missed something. ;) Because it could still register with rfkill, only not give the callback functions for changing the radio or polling. Then the driver can use the send_event function to inform rfkill of the event and process it further. The sysfs attributes could even be reduced to only add the change_status attribute when the radio_enable and radio_disable callback functions are implemented. > 2. A device that does allow controlling its transmitter. The driver > may (should) register with rfkill subsystem. Additionally, if there is > a button, the driver should register it with input subsystem. Driver > should manage transmitter state in response to button presses unless > userspace takes over the process. This is indeed the main goal of rfkill. :) > 3. A device without transmitter but with a button - just register with > input core. Userspace will have to manage state of other devices with > transmitters in response to button presses. This is clear too. Rfkill is only intended for drivers that control a device with a transmitter (WiFi, Bluetooth, IRDA) that have a button that is intended to do something with the radio/transmitter. > Does this make sense? Yes, this was what I intended to do with rfkill, so at that point we have the same goal. > > > > > attribute should be a tri-state on/off/auto, "auto" meaning the driver > > > > > itself manages radio state. This would avoid another tacky IMHO point > > > > > that in your implementation mere opening of an input device takes over > > > > > RF driver. Explicit control allow applications "snoop" RF state > > > > > without disturbing it. > > > > > > > > Currently userspace can always check the state of the button whenever > > > > they like by checking the sysfs entry. > > > > > > > > > > Unless the key is not directly connected to the driver (so there is no > > > sysfs entry). Again you force 2 different interfaces. > > > > Ok, so input device opening should not block the rfkill signal and the > > rfkill handler > > should still go through with its work unless a
Re: Kernel header changes break glibc build
* Al Viro <[EMAIL PROTECTED]> 2006-12-06 20:34 > On Wed, Dec 06, 2006 at 09:26:39PM +0100, Thomas Graf wrote: > > * Al Viro <[EMAIL PROTECTED]> 2006-12-06 17:13 > > > On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote: > > > > > > > At the time they were added they were meant to be exported but netlink > > > > has evolved and we now have a type safe API. > > > > > > Where? AFAICS, netlink might be considered type-safe only within an > > > address family... > > > > The new interface can be found in net/netlink.h, it obsoletes the > > old interface which is spread over linux/netlink.h and linux/rtnetlink.h > > ... and for different address families you have conflicting policies. > You can't tell if ATTR_... means __le16, __be32, 16byte-array or something > else - the answer depends on the code interpreting the damn thing. > Moreover, you get zero warnings if you use wrong accessor to decode. That's right, some attribute cary address specific content such as addresses. By type safe I meant the API which no longer consists of macros prone to errors. I didn't mean to say netlink attributes are now type safe. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] softmac: Fixed handling of deassociation from AP
On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote:
> On 06-12-06 18:52 Michael Buesch wrote:
>
> > All data in mac->associnfo is protected by mac->associnfo->mutex
> > and _not_ mac->lock.
>
> Are you sure?
Yes I am.
> One can find for instance the following function in
> ieee80211softmac_assoc.c:
This is not the first time we notice that locking
is completely broken in softmac. ;)
> void
> ieee80211softmac_disassoc(struct ieee80211softmac_device *mac)
> {
> unsigned long flags;
>
> spin_lock_irqsave(&mac->lock, flags);
> if (mac->associnfo.associating)
> cancel_delayed_work(&mac->associnfo.timeout);
>
> netif_carrier_off(mac->dev);
>
> mac->associnfo.associated = 0;
> mac->associnfo.bssvalid = 0;
> mac->associnfo.associating = 0;
> ieee80211softmac_init_bss(mac);
> ieee80211softmac_call_events_locked(mac,
> IEEE80211SOFTMAC_EVENT_DISASSOCIATED, NULL);
> spin_unlock_irqrestore(&mac->lock, flags);
> }
>
> Cheers,
>
> Uli
>
--
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel header changes break glibc build
On Wed, Dec 06, 2006 at 09:26:39PM +0100, Thomas Graf wrote: > * Al Viro <[EMAIL PROTECTED]> 2006-12-06 17:13 > > On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote: > > > > > At the time they were added they were meant to be exported but netlink > > > has evolved and we now have a type safe API. > > > > Where? AFAICS, netlink might be considered type-safe only within an > > address family... > > The new interface can be found in net/netlink.h, it obsoletes the > old interface which is spread over linux/netlink.h and linux/rtnetlink.h ... and for different address families you have conflicting policies. You can't tell if ATTR_... means __le16, __be32, 16byte-array or something else - the answer depends on the code interpreting the damn thing. Moreover, you get zero warnings if you use wrong accessor to decode. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] softmac: Fixed handling of deassociation from AP
On 06-12-06 18:52 Michael Buesch wrote:
> All data in mac->associnfo is protected by mac->associnfo->mutex
> and _not_ mac->lock.
Are you sure? One can find for instance the following function in
ieee80211softmac_assoc.c:
void
ieee80211softmac_disassoc(struct ieee80211softmac_device *mac)
{
unsigned long flags;
spin_lock_irqsave(&mac->lock, flags);
if (mac->associnfo.associating)
cancel_delayed_work(&mac->associnfo.timeout);
netif_carrier_off(mac->dev);
mac->associnfo.associated = 0;
mac->associnfo.bssvalid = 0;
mac->associnfo.associating = 0;
ieee80211softmac_init_bss(mac);
ieee80211softmac_call_events_locked(mac,
IEEE80211SOFTMAC_EVENT_DISASSOCIATED, NULL);
spin_unlock_irqrestore(&mac->lock, flags);
}
Cheers,
Uli
--
Uli Kunitz
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel header changes break glibc build
* Stefan Rompf <[EMAIL PROTECTED]> 2006-12-06 20:32 > According to a user's report, your change also broke compilation of my > dhcpclient because it neeeds if_addr.h since 2.6.19. Any suggestion how to > make one source code build on 2.6.19 and older headers? I hope you don't want > me to check on UTS_RELEASE in a userspace program? #ifndef IFA_MAX #include #endif - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
On 12/6/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote: On Wednesday 06 December 2006 15:37, Dmitry Torokhov wrote: > On 12/4/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote: > > > I am still not sure that tight coupling of input device with rfkill > > > structure is such a good idea. Quite often the button is separated > > > from the device itself and radio control is done via BIOS SMM (see > > > wistron driver) or there is no special button at all and users might > > > want to assign one of their standard keyboard buttons to be an RF > > > switch. > > > > Making sure rfkill supports keys that are not handled by the driver > > is a bit hard. Just as drivers that can only check if the button is > > toggled and not what the current state is. > > The problem is that it is hard to make a clean split between the > > 2 different button controls. Not all drivers allow the radio to be > > enabled while the button status are indicating the radio should > > be off. > > If they do not allow controlling the state of the radio > programmatically then it should not be part of rfkill I am afraid. It > is like the power switch - if you hold it for so long it kills the > power to the box and there is nothing you can do about it. Ok, this will give rfkill more possibilities as I could in that case also allow the user to toggle the radio to the state that is different than indicated by the key. Currently this was not possible since I had to keep in mind that there were keys that would directly control the radio. > > The buttons that are already integrated into the keyboard, > > by example by using a Fn key combo don't control the device > > directly. So the driver cannot offer anything to the rfkill driver. > > Such buttons should be mapped in userspace without the help of rfkill, > > since the kernel cannot detect if that key belonged to a radio > > control key or not. > > > > That is my point. Given the fact that there are keys that are not > directly connected with the radio switch userspace will have to handle > them (wait for events then turn off radios somehow). You are > advocating that userspace should also implement 2nd method for buttons > that belong to rfkill interface. I do not understand the need for 2nd > interface. If you separate radio switch from button code then > userspace only need to implement 1st interface and be done with it. > You will have set of cards that provide interface to enable/disable > their transmitters and set of buttons that signal userspace desired > state change. If both switch and button is implemented by the same > driver then the driver can implement automatic button handling. > Otherwise userspace help is necessary. Well there are 3 possible hardware key approaches: 1 - Hardware key that controls the hardware radio, and does not report anything to userspace Can't do anything here so just ignore it. 2 - Hardware key that does not control the hardware radio and does not report anything to userspace Kind of uninteresting button ;) 3 - Hardware key that does not control the hardware radio and reports the key to userspace So rfkill should not be used in the case of (1) and (3), but we still need something to support (2) or should the keys not be handled by userspace and always by the driver? This is making rfkill moving slowly away from the generic approach for all rfkill keys as the initial intention was. I my "vision" rfkill would represent userspace namageable radio switch. We have the followng possible configurations: 1. A device that does not allow controlling its transmitter from userspace. The driver should not use/register with rfkill subsystem as userspace can't do anyhting with it. If device has a button killing the transmitter the driver can still signal userspace appropriate event (KEY_WIFI, KEY_BLUETOOTH, etc) if it can detect that button was presssed so userspace can monitor state of the transmitter and probably shut down other transmitters to keep everything in sync. 2. A device that does allow controlling its transmitter. The driver may (should) register with rfkill subsystem. Additionally, if there is a button, the driver should register it with input subsystem. Driver should manage transmitter state in response to button presses unless userspace takes over the process. 3. A device without transmitter but with a button - just register with input core. Userspace will have to manage state of other devices with transmitters in response to button presses. Does this make sense? > > > attribute should be a tri-state on/off/auto, "auto" meaning the driver > > > itself manages radio state. This would avoid another tacky IMHO point > > > that in your implementation mere opening of an input device takes over > > > RF driver. Explicit control allow applications "snoop" RF state > > > without disturbing it. > > > > Currently userspace can always check the state of the button whenever > > they like by checking the sysfs entry. > > > > Unless the key is not
Re: Kernel header changes break glibc build
* Al Viro <[EMAIL PROTECTED]> 2006-12-06 17:13 > On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote: > > > At the time they were added they were meant to be exported but netlink > > has evolved and we now have a type safe API. > > Where? AFAICS, netlink might be considered type-safe only within an > address family... The new interface can be found in net/netlink.h, it obsoletes the old interface which is spread over linux/netlink.h and linux/rtnetlink.h I'm removing the old bits as soon as I've finished converting all its users. An almost identical interface is provided to userspace by libnl. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] irlan: fix header build warning
From: Randy Dunlap <[EMAIL PROTECTED]> Fix compile warning when CONFIG_PROC_FS=n: include/net/irda/irlan_filter.h:31: warning: 'struct seq_file' declared inside parameter list include/net/irda/irlan_filter.h:31: warning: its scope is only this definition or declaration, which is probably not what you want Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- include/net/irda/irlan_filter.h |1 + 1 file changed, 1 insertion(+) --- linux-2.6.19-git7.orig/include/net/irda/irlan_filter.h +++ linux-2.6.19-git7/include/net/irda/irlan_filter.h @@ -28,6 +28,7 @@ void irlan_check_command_param(struct irlan_cb *self, char *param, char *value); void irlan_filter_request(struct irlan_cb *self, struct sk_buff *skb); +struct seq_file; void irlan_print_filter(struct seq_file *seq, int filter_type); #endif /* IRLAN_FILTER_H */ --- - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Wednesday 06 December 2006 15:37, Dmitry Torokhov wrote: > On 12/4/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote: > > > I am still not sure that tight coupling of input device with rfkill > > > structure is such a good idea. Quite often the button is separated > > > from the device itself and radio control is done via BIOS SMM (see > > > wistron driver) or there is no special button at all and users might > > > want to assign one of their standard keyboard buttons to be an RF > > > switch. > > > > Making sure rfkill supports keys that are not handled by the driver > > is a bit hard. Just as drivers that can only check if the button is > > toggled and not what the current state is. > > The problem is that it is hard to make a clean split between the > > 2 different button controls. Not all drivers allow the radio to be > > enabled while the button status are indicating the radio should > > be off. > > If they do not allow controlling the state of the radio > programmatically then it should not be part of rfkill I am afraid. It > is like the power switch - if you hold it for so long it kills the > power to the box and there is nothing you can do about it. Ok, this will give rfkill more possibilities as I could in that case also allow the user to toggle the radio to the state that is different than indicated by the key. Currently this was not possible since I had to keep in mind that there were keys that would directly control the radio. > > The buttons that are already integrated into the keyboard, > > by example by using a Fn key combo don't control the device > > directly. So the driver cannot offer anything to the rfkill driver. > > Such buttons should be mapped in userspace without the help of rfkill, > > since the kernel cannot detect if that key belonged to a radio > > control key or not. > > > > That is my point. Given the fact that there are keys that are not > directly connected with the radio switch userspace will have to handle > them (wait for events then turn off radios somehow). You are > advocating that userspace should also implement 2nd method for buttons > that belong to rfkill interface. I do not understand the need for 2nd > interface. If you separate radio switch from button code then > userspace only need to implement 1st interface and be done with it. > You will have set of cards that provide interface to enable/disable > their transmitters and set of buttons that signal userspace desired > state change. If both switch and button is implemented by the same > driver then the driver can implement automatic button handling. > Otherwise userspace help is necessary. Well there are 3 possible hardware key approaches: 1 - Hardware key that controls the hardware radio, and does not report anything to userspace 2 - Hardware key that does not control the hardware radio and does not report anything to userspace 3 - Hardware key that does not control the hardware radio and reports the key to userspace So rfkill should not be used in the case of (1) and (3), but we still need something to support (2) or should the keys not be handled by userspace and always by the driver? This is making rfkill moving slowly away from the generic approach for all rfkill keys as the initial intention was. > > > attribute should be a tri-state on/off/auto, "auto" meaning the driver > > > itself manages radio state. This would avoid another tacky IMHO point > > > that in your implementation mere opening of an input device takes over > > > RF driver. Explicit control allow applications "snoop" RF state > > > without disturbing it. > > > > Currently userspace can always check the state of the button whenever > > they like by checking the sysfs entry. > > > > Unless the key is not directly connected to the driver (so there is no > sysfs entry). Again you force 2 different interfaces. Ok, so input device opening should not block the rfkill signal and the rfkill handler should still go through with its work unless a different config option indicates that userspace wants to handle the event. Ivo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel header changes break glibc build
Am Montag, 4. Dezember 2006 10:13 schrieb Thomas Graf: > I do not agree with the change to include if_addr.h in rtnetlink.h. > The point is to move bits apart and have multiple small pieces > of header files defining a specific rtnetlink family which are a > lot easier to maintain for both kernel and userspace than one giant > rtnetlink.h for everything. According to a user's report, your change also broke compilation of my dhcpclient because it neeeds if_addr.h since 2.6.19. Any suggestion how to make one source code build on 2.6.19 and older headers? I hope you don't want me to check on UTS_RELEASE in a userspace program? Stefan - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
On Wed, Dec 06, 2006 at 10:16:44AM -0800, Stephen Hemminger wrote: > I think it is really only an issue for drivers that turn on HIGH_DMA > and have limited mask values. The majority of drivers either only > handle 32 bit (!HIGH_DMA) or do full 64 bit mapping. I don't know > the details of how we manage IOMMU, but doesn't mapping always work > for those drivers. It's up to an IOMMU (DMA-API) implementation to define what constitutes a mapping error, e.g., Calgary and GART on x86-64 will return bad_dma_address from the mapping functions when they run out of entries in the IO space, which can happen regardless of the mask. Cheers, Muli - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
On Tue, 5 Dec 2006 09:00:45 +0200 Muli Ben-Yehuda <[EMAIL PROTECTED]> wrote: > On Mon, Dec 04, 2006 at 10:39:49AM -0800, Stephen Hemminger wrote: > > > I notice that no current network driver handles dma mapping errors. > > Might that be part of the problem. On i386, this never happens, and > > it would be rare on most others. > > IOMMUs are already available on x86-64 and are going to get widespread > with the the introduction of IOMMUs from Intel and AMD. Might as well > fix it now... > > How about CONFIG_DEBUG_DMA_API that does book-keeping and yells if a > driver is mis-using the DMA API? > > Cheers, > Muli I think it is really only an issue for drivers that turn on HIGH_DMA and have limited mask values. The majority of drivers either only handle 32 bit (!HIGH_DMA) or do full 64 bit mapping. I don't know the details of how we manage IOMMU, but doesn't mapping always work for those drivers. That just leaves devices with odd size mask values that need to be handle mapping errors. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: Network virtualization/isolation
On Wed, Dec 06, 2006 at 02:54:16PM +0300, Kirill Korotaev wrote: > >>>If there is a better and less intrusive while still being obvious > >>>method I am all for it. I do not like the OpenVZ thing of doing the > >>>lookup once and then stashing the value in current and the special > >>>casing the exceptions. > >> > >>Why? > > > > > > I like it when things are obvious and not implied. > > > > The implementations seems to favor fewer lines of code touched over > > maintainability of the code. Which if you are maintaining out of > > tree code is fine. At leas that was my impression last time > > I looked at the code. > FYI, when we started doing networking virtualization many years ago > we tried both approaches. > Over time, context notion looked much more natural and easier for us. > Even Alexey Kuznetsov tells that he prefers exec_env as the logic > becomes very clear and little mess is introduced. > > > I know there are a lot of silly things in the existing implementations > > because they were initially written without the expectation of being > > able to merge the code into the main kernel. This resulted in some > > non-general interfaces, and a preference for patches that touch > > as few lines of code as possible. > Sure, but OpenVZ code is being constantly cleaned from such code > and we are open for discussion. No one pretends that code is perferct > from the beginning. > > > Anyway this has bit has been discussed before and we can discuss it > > seriously in the context of patch review. > Let me explain when explicit context like exec_env IMHO is cleaner: > - context is a natural notion of linux kernel. e.g. current. > why not pass 'current' to all the functions as an argument > starting from entry.S? > in_atomic(), in_interrupt() etc. all these functions deal with > current context. IMHO when one needs to pass an argument too many > times like 'current' > it is better to use a notion of the context. > - e.g. NFS should set networking context of the mount point or socket. how would that work for a 'shared' NFS partition? (shared between different context) > But, ok, it is not the real point to argue so much imho and waste our > time instead of doing things. well, IMHO better talk (and think) first, then implement something ... not the other way round, and then start fixing up the mess ... best, Herbert > Thanks, > Kirill > > ___ > Containers mailing list > [EMAIL PROTECTED] > https://lists.osdl.org/mailman/listinfo/containers - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Strange problem with tcpdump.
Hi, guys. I've got a problem. I can see all the incoming packets on an ethernet interface, but no outgoing packets, although they are sent to the network, and successfully recieved by the other side. The platform is ixp420, with severely nodifyed ethernet driver, the kernel is 2.6.16.20. May I ask, how is this possible at all? As I understand, the outgoing packets get captured before they reach the driver, so it can't be the cause. On the other hand, I get all the packets sent over an other, non-ethernet interface, so I can't blame tcpdump. Any suggestions, where to start the investigation? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] softmac: Fixed handling of deassociation from AP
On Wednesday 06 December 2006 15:45, Larry Finger wrote:
> From: Ulrich Kunitz <[EMAIL PROTECTED]>
>
> A deauthentication from the AP doesn't start a reassociation by
> SoftMAC. To fix this mac->associnfo.associating must be set and the
> ieee80211softmac_assoc_work function must be scheduled.
>
> Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
>
> net/ieee80211/softmac/ieee80211softmac_assoc.c | 14 --
> net/ieee80211/softmac/ieee80211softmac_auth.c |2 ++
> net/ieee80211/softmac/ieee80211softmac_priv.h |2 ++
> 3 files changed, 16 insertions(+), 2 deletions(-)
>
> Index: wireless-2.6/net/ieee80211/softmac/ieee80211softmac_assoc.c
> ===
> --- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_assoc.c
> +++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_assoc.c
> @@ -427,6 +427,17 @@ ieee80211softmac_handle_assoc_response(s
> return 0;
> }
>
> +void
> +ieee80211softmac_try_reassoc(struct ieee80211softmac_device *mac)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&mac->lock, flags);
> + mac->associnfo.associating = 1;
> + schedule_work(&mac->associnfo.work);
> + spin_unlock_irqrestore(&mac->lock, flags);
> +}
All data in mac->associnfo is protected by mac->associnfo->mutex
and _not_ mac->lock.
--
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[IPROUTE2 PATCH][DOC] clarify "ok" and "pass"
a small one.
I have a few more but just run out of cycles for now;
if you dont mind holding before releasing for a short while so i can
get them out I will appreciate it.
cheers,
jamal
[DOC]: clarify "ok" and "pass"
A small fixup to elucidate the mysteries of accepting ..
---
commit d3f9d336f524d2aa36442212d72f39de15b1e585
tree cba1f16ca21fd70ad2d2b59b460166929157ba59
parent 241e28d5d5d326d33b2d71752d574e2ae118f671
author Marco Berizzi <[EMAIL PROTECTED]> Wed, 06 Dec 2006 12:39:19 -0500
committer Jamal Hadi Salim <[EMAIL PROTECTED]> Wed, 06 Dec 2006 12:39:19 -0500
doc/actions/actions-general |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/doc/actions/actions-general b/doc/actions/actions-general
index bb2295d..6561eda 100644
--- a/doc/actions/actions-general
+++ b/doc/actions/actions-general
@@ -65,7 +65,7 @@ action police mtu 4000 rate 1500kbit burst 90k
{ drop, pass, reclassify, continue}
(If you have others, no listed here give me a reason and we will add them)
+drop says to drop the packet
-+pass says to accept it
++pass and ok (are equivalent) says to accept it
+reclassify requests for reclassification of the packet
+continue requests for next lookup to match
[IPROUTE2 PATCH][GENETLINK] Add controller support for new features exposed
Ok, heres hopefully the last one in this series for generic netlink ..
cheers,
jamal
[GENL]: Add controller support for new features exposed
Update the controller to spit out the new features being exposed
from the kernel
Signed-off-by: J Hadi Salim <[EMAIL PROTECTED]>
---
commit 241e28d5d5d326d33b2d71752d574e2ae118f671
tree ccda0d9dd9b85180fdd803f79ad11d305f2ffc53
parent 515370c958be14b417e20611258eecbe9fda2382
author Jamal Hadi Salim <[EMAIL PROTECTED]> Wed, 06 Dec 2006 12:30:36 -0500
committer Jamal Hadi Salim <[EMAIL PROTECTED]> Wed, 06 Dec 2006 12:30:36 -0500
genl/ctrl.c | 84 ++-
1 files changed, 82 insertions(+), 2 deletions(-)
diff --git a/genl/ctrl.c b/genl/ctrl.c
index 0d4750d..fe010f3 100644
--- a/genl/ctrl.c
+++ b/genl/ctrl.c
@@ -22,6 +22,7 @@
#include "utils.h"
#include "genl_utils.h"
+#define GENL_MAX_FAM_OPS 256
static int usage(void)
{
fprintf(stderr,"Usage: ctrl \n" \
@@ -108,6 +109,51 @@ errout:
return ret;
}
+void print_ctrl_cmd_flags(FILE *fp, __u32 fl)
+{
+ fprintf(fp, "\n\t\tCapabilities (0x%x):\n ", fl);
+ if (!fl) {
+ fprintf(fp, "\n");
+ return;
+ }
+ fprintf(fp, "\t\t ");
+
+ if (fl & GENL_ADMIN_PERM)
+ fprintf(fp, " requires admin permission;");
+ if (fl & GENL_CMD_CAP_DO)
+ fprintf(fp, " can doit;");
+ if (fl & GENL_CMD_CAP_DUMP)
+ fprintf(fp, " can dumpit;");
+ if (fl & GENL_CMD_CAP_HASPOL)
+ fprintf(fp, " has policy");
+
+ fprintf(fp, "\n");
+}
+
+static int print_ctrl_cmds(FILE *fp, struct rtattr *arg, __u32 ctrl_ver)
+{
+ struct rtattr *tb[CTRL_ATTR_OP_MAX + 1];
+
+ if (arg == NULL)
+ return -1;
+
+ parse_rtattr_nested(tb, CTRL_ATTR_OP_MAX, arg);
+ if (tb[CTRL_ATTR_OP_ID]) {
+ __u32 *id = RTA_DATA(tb[CTRL_ATTR_OP_ID]);
+ fprintf(fp, " ID-0x%x ",*id);
+ }
+ /* we are only gonna do this for newer version of the controller */
+ if (tb[CTRL_ATTR_OP_FLAGS] && ctrl_ver >= 0x2) {
+ __u32 *fl = RTA_DATA(tb[CTRL_ATTR_OP_FLAGS]);
+ print_ctrl_cmd_flags(fp, *fl);
+ }
+ return 0;
+
+}
+
+/*
+ * The controller sends one nlmsg per family
+*/
static int print_ctrl(const struct sockaddr_nl *who, struct nlmsghdr *n,
void *arg)
{
@@ -116,6 +162,7 @@ static int print_ctrl(const struct sockaddr_nl *who, struct
nlmsghdr *n,
int len = n->nlmsg_len;
struct rtattr *attrs;
FILE *fp = (FILE *) arg;
+ __u32 ctrl_v = 0x1;
if (n->nlmsg_type != GENL_ID_CTRL) {
fprintf(stderr, "Not a controller message, nlmsg_len=%d "
@@ -142,13 +189,46 @@ static int print_ctrl(const struct sockaddr_nl *who,
struct nlmsghdr *n,
if (tb[CTRL_ATTR_FAMILY_NAME]) {
char *name = RTA_DATA(tb[CTRL_ATTR_FAMILY_NAME]);
- fprintf(fp, "Name: %s\n",name);
+ fprintf(fp, "\nName: %s\n",name);
}
if (tb[CTRL_ATTR_FAMILY_ID]) {
__u16 *id = RTA_DATA(tb[CTRL_ATTR_FAMILY_ID]);
- fprintf(fp, "ID: 0x%x\n",*id);
+ fprintf(fp, "\tID: 0x%x ",*id);
+ }
+ if (tb[CTRL_ATTR_VERSION]) {
+ __u32 *v = RTA_DATA(tb[CTRL_ATTR_VERSION]);
+ fprintf(fp, " Version: 0x%x ",*v);
+ ctrl_v = *v;
}
+ if (tb[CTRL_ATTR_HDRSIZE]) {
+ __u32 *h = RTA_DATA(tb[CTRL_ATTR_HDRSIZE]);
+ fprintf(fp, " header size: %d ",*h);
+ }
+ if (tb[CTRL_ATTR_MAXATTR]) {
+ __u32 *ma = RTA_DATA(tb[CTRL_ATTR_MAXATTR]);
+ fprintf(fp, " max attribs: %d ",*ma);
+ }
+ /* end of family definitions .. */
+ fprintf(fp,"\n");
+ if (tb[CTRL_ATTR_OPS]) {
+ struct rtattr *tb2[GENL_MAX_FAM_OPS];
+ int i=0;
+ parse_rtattr_nested(tb2, GENL_MAX_FAM_OPS, tb[CTRL_ATTR_OPS]);
+ fprintf(fp, "\tcommands supported: \n");
+ for (i = 0; i < GENL_MAX_FAM_OPS; i++) {
+ if (tb2[i]) {
+ fprintf(fp, "\t\t#%d: ", i);
+ if (0 > print_ctrl_cmds(fp, tb2[i], ctrl_v)) {
+ fprintf(fp, "Error printing command\n");
+ }
+ /* for next command */
+ fprintf(fp,"\n");
+ }
+ }
+ /* end of family::cmds definitions .. */
+ fprintf(fp,"\n");
+ }
fflush(fp);
return 0;
}
Re: [PATCH][GENETLINK] fix misplaced command flags
From: jamal <[EMAIL PROTECTED]> Date: Wed, 06 Dec 2006 12:02:23 -0500 > fixes something i broke in previous patch. Against net-2.6.20. > BTW, is it just me having problems syncing net-2.6.20? You should be using the net-2.6.git tree now, I blow away the net-2.6.X.git tree when 2.6.X integration starts happening and just do everything from net-2.6.git - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel header changes break glibc build
On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote: > At the time they were added they were meant to be exported but netlink > has evolved and we now have a type safe API. Where? AFAICS, netlink might be considered type-safe only within an address family... - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[IPROUTE2 PATCH][GENETLINK] Multicast computation off by one
A small typo fixup
BTW, how do you like the subject to look like?
cheers,
jamal
[GENL] Multicast computation off by one
When using the first 32 groups, the multicast group to bit mapping
was off by one.
Signed-off-by: Jamal Hadi Salim
---
commit b883bf2396abc0434b3a63d228593cec80808dbb
tree dba2b9664d88d7a4641d11c6284b984a33d2b47a
parent 288384f22ffafd2d7d888ee45d8dfcf26d3f2b1c
author Jamal Hadi Salim <[EMAIL PROTECTED]> Tue, 05 Dec 2006 14:13:46 -0500
committer Jamal Hadi Salim <[EMAIL PROTECTED]> Tue, 05 Dec 2006 14:13:46 -0500
genl/genl_utils.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/genl/genl_utils.h b/genl/genl_utils.h
index 2f2314b..22e9210 100644
--- a/genl/genl_utils.h
+++ b/genl/genl_utils.h
@@ -16,7 +16,7 @@ extern int genl_ctrl_resolve_family(const char *family);
/* seems to have dissapeared from netlink.h */
static inline __u32 nl_mgrp(__u32 group)
{
- return group ? 1 << group : 0;
+ return group ? (1 << (group -1)) : 0;
}
#endif
[IPROUTE2 PATCH][GENETLINK] Update generic netlink header
Stepehen,
Didnt hear back from you, please apply this one; needed for the next
patches.
cheers,
jamal
[GENL] Update generic netlink header
The header file needs to be uptodate with recent changes to allow
for forward compatibility
Signed-off-by: J Hadi Salim <[EMAIL PROTECTED]>
---
commit 515370c958be14b417e20611258eecbe9fda2382
tree 5d81c1d7a50592a18c50948a65faf3b85cefd9a7
parent ae665a522bd46bea44c5ea84c89c8b1731954170
author Jamal Hadi Salim <[EMAIL PROTECTED]> Wed, 06 Dec 2006 11:32:37 -0500
committer Jamal Hadi Salim <[EMAIL PROTECTED]> Wed, 06 Dec 2006 11:32:37 -0500
include/linux/genetlink.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/genetlink.h b/include/linux/genetlink.h
index 9049dc6..f7a9377 100644
--- a/include/linux/genetlink.h
+++ b/include/linux/genetlink.h
@@ -17,6 +17,9 @@ struct genlmsghdr {
#define GENL_HDRLENNLMSG_ALIGN(sizeof(struct genlmsghdr))
#define GENL_ADMIN_PERM0x01
+#define GENL_CMD_CAP_DO0x02
+#define GENL_CMD_CAP_DUMP 0x04
+#define GENL_CMD_CAP_HASPOL0x08
/*
* List of reserved static generic netlink identifiers:
@@ -58,9 +61,6 @@ enum {
CTRL_ATTR_OP_UNSPEC,
CTRL_ATTR_OP_ID,
CTRL_ATTR_OP_FLAGS,
- CTRL_ATTR_OP_POLICY,
- CTRL_ATTR_OP_DOIT,
- CTRL_ATTR_OP_DUMPIT,
__CTRL_ATTR_OP_MAX,
};
Re: [NET_SCHED]: cls_fw: fix NULL pointer dereference
Jarek Poplawski wrote: > On 04-12-2006 16:34, Patrick McHardy wrote: > >>Thomas, Jamal, do you have an idea what this "old method" stuff >>is used for? It seems it is only used during the below mentioned >>race. > > > Sorry for eavesdropping, but have a look at htb_classify > starting comment. It is also used by unofficial but quite > popular IPMARK target. Yes I know, I just didn't see how it could be configured to really use that code. But while trying to explain the flow that would always lead to tp->root != NULL in this mail, I noticed I missed something :) At the top of fw_change: if (!opt) return handle ? -EINVAL : 0; which happens when adding a fw classifier without specifying any arguments. My previous fix is still enough, but we can't remove this of course. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][GENETLINK] fix misplaced command flags
fixes something i broke in previous patch. Against net-2.6.20. BTW, is it just me having problems syncing net-2.6.20? cheers, jamal [GENETLINK] fix misplaced command flags The command flags for dump and do were swapped.. Signed-off-by: Jamal Hadi Salim<[EMAIL PROTECTED]> --- commit 03b09fc1e8f71a14c661af496941b6de963fddf1 tree 3b3c62e1b5f1db0e75ab383a2ec43173cb0f0efa parent 49ba7537cec41f0db2500054b5fde3c193c37a97 author Jamal Hadi Salim <[EMAIL PROTECTED]> Wed, 06 Dec 2006 11:58:34 -0500 committer Jamal Hadi Salim <[EMAIL PROTECTED]> Wed, 06 Dec 2006 11:58:34 -0500 net/netlink/genetlink.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c index 3e37ea5..a59b7bb 100644 --- a/net/netlink/genetlink.c +++ b/net/netlink/genetlink.c @@ -144,9 +144,9 @@ int genl_register_ops(struct genl_family *family, struct genl_ops *ops) } if (ops->dumpit) - ops->flags |= GENL_CMD_CAP_DO; - if (ops->doit) ops->flags |= GENL_CMD_CAP_DUMP; + if (ops->doit) + ops->flags |= GENL_CMD_CAP_DO; if (ops->policy) ops->flags |= GENL_CMD_CAP_HASPOL;
Re: [PATCH] netxen: sparse warning and ioctl bug fixes
On Wed, 6 Dec 2006 21:40:34 +0530 "Amit S. Kale" <[EMAIL PROTECTED]> wrote: > Hi Stephen, > > This patch looks good. > > ioctls: NetXen chip is far more generic and will eventually show a > significant > amount of functionality in different products. We need ioctl analysis for > user level tools that can tell states of registers etc. Removing ioctls all > together will make any analysis from userland extremely difficult. Use (and extend) existing ethtool interface to get registers and statistics. > > Does anyone have ideas on improving this ioctl interface? > > Thanks. > -Amit > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH]: Fix netpoll arp_reply for multiple routers
All,
Attached is a patch to fix arp_reply when you have multiple possible
routers doing ARP requests to you. Currently arp_reply always replies to the
MAC address that it was given when it starts. However, if you have multiple
routers that can ARP request you, you might respond to the wrong router; in
which case the other router will eventually drop you from it's ARP cache and
stop delivering packets to you. The fix is to always reply to the router that
asked you, not the one you have hard-coded.
I do not have the setup to test this; the customer that does have the
setup has tested the patch and reports that it fixes the problems they were
having.
Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]>
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 3c58846..5833b21 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -331,6 +331,7 @@ static void arp_reply(struct sk_buff *sk
unsigned char *arp_ptr;
int size, type = ARPOP_REPLY, ptype = ETH_P_ARP;
__be32 sip, tip;
+ unsigned char *sha;
struct sk_buff *send_skb;
struct netpoll *np = NULL;
@@ -357,9 +358,14 @@ static void arp_reply(struct sk_buff *sk
arp->ar_op != htons(ARPOP_REQUEST))
return;
- arp_ptr = (unsigned char *)(arp+1) + skb->dev->addr_len;
+ arp_ptr = (unsigned char *)(arp+1);
+ /* save the location of the src hw addr */
+ sha = arp_ptr;
+ arp_ptr += skb->dev->addr_len;
memcpy(&sip, arp_ptr, 4);
- arp_ptr += 4 + skb->dev->addr_len;
+ arp_ptr += 4;
+ /* if we actually cared about dst hw addr, it would get copied here */
+ arp_ptr += skb->dev->addr_len;
memcpy(&tip, arp_ptr, 4);
/* Should we ignore arp? */
@@ -382,7 +388,7 @@ static void arp_reply(struct sk_buff *sk
if (np->dev->hard_header &&
np->dev->hard_header(send_skb, skb->dev, ptype,
- np->remote_mac, np->local_mac,
+ sha, np->local_mac,
send_skb->len) < 0) {
kfree_skb(send_skb);
return;
@@ -406,7 +412,7 @@ static void arp_reply(struct sk_buff *sk
arp_ptr += np->dev->addr_len;
memcpy(arp_ptr, &tip, 4);
arp_ptr += 4;
- memcpy(arp_ptr, np->remote_mac, np->dev->addr_len);
+ memcpy(arp_ptr, sha, np->dev->addr_len);
arp_ptr += np->dev->addr_len;
memcpy(arp_ptr, &sip, 4);
Re: [PATCH] netxen: sparse warning and ioctl bug fixes
Hi Stephen,
This patch looks good.
ioctls: NetXen chip is far more generic and will eventually show a significant
amount of functionality in different products. We need ioctl analysis for
user level tools that can tell states of registers etc. Removing ioctls all
together will make any analysis from userland extremely difficult.
Does anyone have ideas on improving this ioctl interface?
Thanks.
-Amit
On Wednesday 06 December 2006 01:37, Stephen Hemminger wrote:
> Fix sparse warnings and get rid of casts that hide misuse
> of __user pointers. There were two real bugs here:
> * ioctl was copying uninitialized stack om NETXEN_NIC_NAME
> * ioctl was dereferencing a user pointer
> in nettxen_nic_cmd_clear_stats.
>
> IMHO the ioctl usage in this driver is going to be more maintenance
> burden than useful. and should be removed.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
> ---
> drivers/net/netxen/netxen_nic.h |5 +
> drivers/net/netxen/netxen_nic_hdr.h | 128
> + drivers/net/netxen/netxen_nic_init.c |
> 38 +-
> drivers/net/netxen/netxen_nic_ioctl.h |2 -
> drivers/net/netxen/netxen_nic_main.c | 34 +++--
> 5 files changed, 99 insertions(+), 108 deletions(-)
>
> diff --git a/drivers/net/netxen/netxen_nic.h
> b/drivers/net/netxen/netxen_nic.h index d925053..f66ebe3 100644
> --- a/drivers/net/netxen/netxen_nic.h
> +++ b/drivers/net/netxen/netxen_nic.h
> @@ -916,9 +916,8 @@ void netxen_tso_check(struct netxen_adap
> struct cmd_desc_type0 *desc, struct sk_buff *skb);
> int netxen_nic_hw_resources(struct netxen_adapter *adapter);
> void netxen_nic_clear_stats(struct netxen_adapter *adapter);
> -int
> -netxen_nic_do_ioctl(struct netxen_adapter *adapter, void *u_data,
> - struct netxen_port *port);
> +int netxen_nic_do_ioctl(struct netxen_adapter *adapter, void __user
> *u_data, +struct netxen_port *port);
> int netxen_nic_rx_has_work(struct netxen_adapter *adapter);
> int netxen_nic_tx_has_work(struct netxen_adapter *adapter);
> void netxen_watchdog_task(unsigned long v);
> diff --git a/drivers/net/netxen/netxen_nic_hdr.h
> b/drivers/net/netxen/netxen_nic_hdr.h index 72c6ec4..2461afc 100644
> --- a/drivers/net/netxen/netxen_nic_hdr.h
> +++ b/drivers/net/netxen/netxen_nic_hdr.h
> @@ -228,139 +228,139 @@ enum {
> /* This field defines CRB adr [31:20] of the agents */
>
> #define NETXEN_HW_CRB_HUB_AGT_ADR_MN \
> - ((NETXEN_HW_H0_CH_HUB_ADR << 7) | NETXEN_HW_MN_CRB_AGT_ADR)
> + (((u32)NETXEN_HW_H0_CH_HUB_ADR << 7) | NETXEN_HW_MN_CRB_AGT_ADR)
> #define NETXEN_HW_CRB_HUB_AGT_ADR_PH \
> - ((NETXEN_HW_H0_CH_HUB_ADR << 7) | NETXEN_HW_PH_CRB_AGT_ADR)
> + (((u32)NETXEN_HW_H0_CH_HUB_ADR << 7) | NETXEN_HW_PH_CRB_AGT_ADR)
> #define NETXEN_HW_CRB_HUB_AGT_ADR_MS \
> - ((NETXEN_HW_H0_CH_HUB_ADR << 7) | NETXEN_HW_MS_CRB_AGT_ADR)
> + (((u32)NETXEN_HW_H0_CH_HUB_ADR << 7) | NETXEN_HW_MS_CRB_AGT_ADR)
>
> #define NETXEN_HW_CRB_HUB_AGT_ADR_PS \
> - ((NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_PS_CRB_AGT_ADR)
> + (((u32)NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_PS_CRB_AGT_ADR)
> #define NETXEN_HW_CRB_HUB_AGT_ADR_SS \
> - ((NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_SS_CRB_AGT_ADR)
> + (((u32)NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_SS_CRB_AGT_ADR)
> #define NETXEN_HW_CRB_HUB_AGT_ADR_RPMX3 \
> - ((NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_RPMX3_CRB_AGT_ADR)
> + (((u32)NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_RPMX3_CRB_AGT_ADR)
> #define NETXEN_HW_CRB_HUB_AGT_ADR_QMS\
> - ((NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_QMS_CRB_AGT_ADR)
> + (((u32)NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_QMS_CRB_AGT_ADR)
> #define NETXEN_HW_CRB_HUB_AGT_ADR_SQS0 \
> - ((NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_SQGS0_CRB_AGT_ADR)
> + (((u32)NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_SQGS0_CRB_AGT_ADR)
> #define NETXEN_HW_CRB_HUB_AGT_ADR_SQS1 \
> - ((NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_SQGS1_CRB_AGT_ADR)
> + (((u32)NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_SQGS1_CRB_AGT_ADR)
> #define NETXEN_HW_CRB_HUB_AGT_ADR_SQS2 \
> - ((NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_SQGS2_CRB_AGT_ADR)
> + (((u32)NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_SQGS2_CRB_AGT_ADR)
> #define NETXEN_HW_CRB_HUB_AGT_ADR_SQS3 \
> - ((NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_SQGS3_CRB_AGT_ADR)
> + (((u32)NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_SQGS3_CRB_AGT_ADR)
> #define NETXEN_HW_CRB_HUB_AGT_ADR_C2C0 \
> - ((NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_C2C0_CRB_AGT_ADR)
> + (((u32)NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_C2C0_CRB_AGT_ADR)
> #define NETXEN_HW_CRB_HUB_AGT_ADR_C2C1 \
> - ((NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_C2C1_CRB_AGT_ADR)
> + (((u32)NETXEN_HW_H1_CH_HUB_ADR << 7) | NETXEN_HW_C2C1_CRB_AGT_ADR)
> #define NETXEN_HW_CRB_HUB_AGT_ADR_RPMX2 \
> -
Re: [RFC] rfkill - Add support for input key to control wireless radio
On 12/6/06, Dan Williams <[EMAIL PROTECTED]> wrote: On Wed, 2006-12-06 at 09:37 -0500, Dmitry Torokhov wrote: > > Fans of the 3rd method, speak up ;) I think I brought up the 3rd method initially in this thread. I'm not necessarily advocating it, but I wanted to be sure people realized that this was a case, so that a clear decision would be made to support it or not to support it. (2) makes the most sense to me. I don't think we need to care about edge-cases like "But I only wanted to rfkill _one_ of my bluetooth dongles!!!", that's just insane. But using (2) also begs the question, can we _always_ identify what interface the rfkill belongs to? In Bastien's laptop, the rfkill switch _automatically_ disconnects the internal USB Bluetooth device from the USB bus, and uses the normal ipw2200 rfkill mechanism, whatever that is. In this case, you simply do not get an event that the bluetooth device is disabled from a button somewhere; it's just gone, and you'd have to do some magic to disable other bluetooth devices as well. Is this the same physical button? If so then for this particular box we'd just have to send 2 events - KEY_WIFI and KEY_BLUETOOTH at the same time. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Wed, 2006-12-06 at 09:37 -0500, Dmitry Torokhov wrote: > On 12/4/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote: > > > I am still not sure that tight coupling of input device with rfkill > > > structure is such a good idea. Quite often the button is separated > > > from the device itself and radio control is done via BIOS SMM (see > > > wistron driver) or there is no special button at all and users might > > > want to assign one of their standard keyboard buttons to be an RF > > > switch. > > > > Making sure rfkill supports keys that are not handled by the driver > > is a bit hard. Just as drivers that can only check if the button is > > toggled and not what the current state is. > > The problem is that it is hard to make a clean split between the > > 2 different button controls. Not all drivers allow the radio to be > > enabled while the button status are indicating the radio should > > be off. > > If they do not allow controlling the state of the radio > programmatically then it should not be part of rfkill I am afraid. It > is like the power switch - if you hold it for so long it kills the > power to the box and there is nothing you can do about it. > > > The buttons that are already integrated into the keyboard, > > by example by using a Fn key combo don't control the device > > directly. So the driver cannot offer anything to the rfkill driver. > > Such buttons should be mapped in userspace without the help of rfkill, > > since the kernel cannot detect if that key belonged to a radio > > control key or not. > > > > That is my point. Given the fact that there are keys that are not > directly connected with the radio switch userspace will have to handle > them (wait for events then turn off radios somehow). You are > advocating that userspace should also implement 2nd method for buttons > that belong to rfkill interface. I do not understand the need for 2nd > interface. If you separate radio switch from button code then > userspace only need to implement 1st interface and be done with it. > You will have set of cards that provide interface to enable/disable > their transmitters and set of buttons that signal userspace desired > state change. If both switch and button is implemented by the same > driver then the driver can implement automatic button handling. > Otherwise userspace help is necessary. > > > > I think it would be better if there was an rfkill class listing all > > > controlled devices (preferrably grouped by their type - WiFi, BT, > > > IRDA, etc) and if every group would provide an attribute allowing to > > > control state of the whole group (do we realistically need to kill > > > just one interface? Wouldn't ifconfig be suitable for that?). The > > > > There have been mixed feelings on the netdev list about what should > > exactly happen when the button is pressed. The possible options are: > > > > 1 - rfkill will kill all interfaces > > 2 - rfkill will kill all interfaces of the same type (wifi, bt, irda) > > 3 - rfkill will kill the interface it belongs to > > > > Personally I would favour the second option, but used the third after > > hearing > > objections to the second method. So since there are also fans of > > the third option I think there should be a decision made about what the > > correct option is, so rfkill can follow that method. > > Fans of the 3rd method, speak up ;) I think I brought up the 3rd method initially in this thread. I'm not necessarily advocating it, but I wanted to be sure people realized that this was a case, so that a clear decision would be made to support it or not to support it. (2) makes the most sense to me. I don't think we need to care about edge-cases like "But I only wanted to rfkill _one_ of my bluetooth dongles!!!", that's just insane. But using (2) also begs the question, can we _always_ identify what interface the rfkill belongs to? In Bastien's laptop, the rfkill switch _automatically_ disconnects the internal USB Bluetooth device from the USB bus, and uses the normal ipw2200 rfkill mechanism, whatever that is. In this case, you simply do not get an event that the bluetooth device is disabled from a button somewhere; it's just gone, and you'd have to do some magic to disable other bluetooth devices as well. Dan > > > > > attribute should be a tri-state on/off/auto, "auto" meaning the driver > > > itself manages radio state. This would avoid another tacky IMHO point > > > that in your implementation mere opening of an input device takes over > > > RF driver. Explicit control allow applications "snoop" RF state > > > without disturbing it. > > > > Currently userspace can always check the state of the button whenever > > they like by checking the sysfs entry. > > > > Unless the key is not directly connected to the driver (so there is no > sysfs entry). Again you force 2 different interfaces. > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at
Re: [RFC] rfkill - Add support for input key to control wireless radio
On 12/4/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote: > I am still not sure that tight coupling of input device with rfkill > structure is such a good idea. Quite often the button is separated > from the device itself and radio control is done via BIOS SMM (see > wistron driver) or there is no special button at all and users might > want to assign one of their standard keyboard buttons to be an RF > switch. Making sure rfkill supports keys that are not handled by the driver is a bit hard. Just as drivers that can only check if the button is toggled and not what the current state is. The problem is that it is hard to make a clean split between the 2 different button controls. Not all drivers allow the radio to be enabled while the button status are indicating the radio should be off. If they do not allow controlling the state of the radio programmatically then it should not be part of rfkill I am afraid. It is like the power switch - if you hold it for so long it kills the power to the box and there is nothing you can do about it. The buttons that are already integrated into the keyboard, by example by using a Fn key combo don't control the device directly. So the driver cannot offer anything to the rfkill driver. Such buttons should be mapped in userspace without the help of rfkill, since the kernel cannot detect if that key belonged to a radio control key or not. That is my point. Given the fact that there are keys that are not directly connected with the radio switch userspace will have to handle them (wait for events then turn off radios somehow). You are advocating that userspace should also implement 2nd method for buttons that belong to rfkill interface. I do not understand the need for 2nd interface. If you separate radio switch from button code then userspace only need to implement 1st interface and be done with it. You will have set of cards that provide interface to enable/disable their transmitters and set of buttons that signal userspace desired state change. If both switch and button is implemented by the same driver then the driver can implement automatic button handling. Otherwise userspace help is necessary. > I think it would be better if there was an rfkill class listing all > controlled devices (preferrably grouped by their type - WiFi, BT, > IRDA, etc) and if every group would provide an attribute allowing to > control state of the whole group (do we realistically need to kill > just one interface? Wouldn't ifconfig be suitable for that?). The There have been mixed feelings on the netdev list about what should exactly happen when the button is pressed. The possible options are: 1 - rfkill will kill all interfaces 2 - rfkill will kill all interfaces of the same type (wifi, bt, irda) 3 - rfkill will kill the interface it belongs to Personally I would favour the second option, but used the third after hearing objections to the second method. So since there are also fans of the third option I think there should be a decision made about what the correct option is, so rfkill can follow that method. Fans of the 3rd method, speak up ;) > attribute should be a tri-state on/off/auto, "auto" meaning the driver > itself manages radio state. This would avoid another tacky IMHO point > that in your implementation mere opening of an input device takes over > RF driver. Explicit control allow applications "snoop" RF state > without disturbing it. Currently userspace can always check the state of the button whenever they like by checking the sysfs entry. Unless the key is not directly connected to the driver (so there is no sysfs entry). Again you force 2 different interfaces. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] softmac: Fixed handling of deassociation from AP
From: Ulrich Kunitz <[EMAIL PROTECTED]>
A deauthentication from the AP doesn't start a reassociation by
SoftMAC. To fix this mac->associnfo.associating must be set and the
ieee80211softmac_assoc_work function must be scheduled.
Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
net/ieee80211/softmac/ieee80211softmac_assoc.c | 14 --
net/ieee80211/softmac/ieee80211softmac_auth.c |2 ++
net/ieee80211/softmac/ieee80211softmac_priv.h |2 ++
3 files changed, 16 insertions(+), 2 deletions(-)
Index: wireless-2.6/net/ieee80211/softmac/ieee80211softmac_assoc.c
===
--- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -427,6 +427,17 @@ ieee80211softmac_handle_assoc_response(s
return 0;
}
+void
+ieee80211softmac_try_reassoc(struct ieee80211softmac_device *mac)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&mac->lock, flags);
+ mac->associnfo.associating = 1;
+ schedule_work(&mac->associnfo.work);
+ spin_unlock_irqrestore(&mac->lock, flags);
+}
+
int
ieee80211softmac_handle_disassoc(struct net_device * dev,
struct ieee80211_disassoc *disassoc)
@@ -445,8 +456,7 @@ ieee80211softmac_handle_disassoc(struct
dprintk(KERN_INFO PFX "got disassoc frame\n");
ieee80211softmac_disassoc(mac);
- /* try to reassociate */
- schedule_work(&mac->associnfo.work);
+ ieee80211softmac_try_reassoc(mac);
return 0;
}
Index: wireless-2.6/net/ieee80211/softmac/ieee80211softmac_auth.c
===
--- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_auth.c
+++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_auth.c
@@ -334,6 +334,8 @@ ieee80211softmac_deauth_from_net(struct
/* can't transmit data right now... */
netif_carrier_off(mac->dev);
spin_unlock_irqrestore(&mac->lock, flags);
+
+ ieee80211softmac_try_reassoc(mac);
}
/*
Index: wireless-2.6/net/ieee80211/softmac/ieee80211softmac_priv.h
===
--- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_priv.h
+++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_priv.h
@@ -238,4 +238,6 @@ void ieee80211softmac_call_events_locked
int ieee80211softmac_notify_internal(struct ieee80211softmac_device *mac,
int event, void *event_context, notify_function_ptr fun, void *context,
gfp_t gfp_mask);
+void ieee80211softmac_try_reassoc(struct ieee80211softmac_device *mac);
+
#endif /* IEEE80211SOFTMAC_PRIV_H_ */
---
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel header changes break glibc build
* Jakub Jelinek <[EMAIL PROTECTED]> 2006-12-06 15:18 > There are the kernel's own headers and kernel ABI headers for userland use. > Until recently the latter has been maintained by various distributions > and manually occassionally updated to sync a little bit with kernel ABI > additions (new syscalls, etc.)., but now, thanks to David, these are > generated from kernel's own headers. If the macros were part of > such ABI Macros can't possibly be part of an ABI :-) You probably mean API. > (I don't think these macros were meant to be #ifdef __KERNEL__ > and just by omission exported to userland), then if you change > the kernel headers (which of course you can do, that's kernel private > headers), then you IMNSHO should also add magic to make headers_install > to keep the kernel ABI headers for userland headers stable. At the time they were added they were meant to be exported but netlink has evolved and we now have a type safe API. Guess what, I'm going to remove more bits of the old interface because they are no longer needed. > Which in this case would mean if you decide rtnetlink.h shouldn't include > the newly added if_addr.h that you add rules for generating the userland > rtnetlink.h such that it will include linux/if_addr.h and define the > macros you intentionally omitted. Sure, moving these bits to some compat header which gets automatically included by make install_headers instead of removing them sounds like a good compromise, it just has to be clear that they are deprecated and not supposed to be used by new code. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
