* linux-next: net tree build warnings
@ 2008-12-17 7:22 Stephen Rothwell
2008-12-17 7:53 ` David Miller
0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2008-12-17 7:22 UTC (permalink / raw)
To: David S. Miller
Cc: linux-next, Steve Glendinning, Yaniv Rosner, Eilong Greenstein
[-- Attachment #1: Type: text/plain, Size: 814 bytes --]
Hi Dave,
Today's linux-next build (x86_64 allmodconfig) produced these warnings:
In file included from drivers/net/bnx2x_main.c:58:
drivers/net/bnx2x_link.h:30:1: warning: "FLOW_CTRL_TX" redefined
In file included from drivers/net/bnx2x_main.c:40:
include/linux/mii.h:139:1: warning: this is the location of the previous definition
In file included from drivers/net/bnx2x_main.c:58:
drivers/net/bnx2x_link.h:31:1: warning: "FLOW_CTRL_RX" redefined
In file included from drivers/net/bnx2x_main.c:40:
include/linux/mii.h:140:1: warning: this is the location of the previous definition
Caused by commit e18ce3465477502108187c6c08b6423fb784a313 ("net: Move flow control definitions to mii.h").
--
Cheers,
Stephen Rothwell sfr@canb•auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: net tree build warnings
2008-12-17 7:22 Stephen Rothwell
@ 2008-12-17 7:53 ` David Miller
2008-12-17 8:04 ` Eilon Greenstein
0 siblings, 1 reply; 27+ messages in thread
From: David Miller @ 2008-12-17 7:53 UTC (permalink / raw)
To: sfr; +Cc: linux-next, steve.glendinning, yanivr, eilong
From: Stephen Rothwell <sfr@canb•auug.org.au>
Date: Wed, 17 Dec 2008 18:22:24 +1100
> Today's linux-next build (x86_64 allmodconfig) produced these warnings:
>
> In file included from drivers/net/bnx2x_main.c:58:
> drivers/net/bnx2x_link.h:30:1: warning: "FLOW_CTRL_TX" redefined
> In file included from drivers/net/bnx2x_main.c:40:
> include/linux/mii.h:139:1: warning: this is the location of the previous definition
> In file included from drivers/net/bnx2x_main.c:58:
> drivers/net/bnx2x_link.h:31:1: warning: "FLOW_CTRL_RX" redefined
> In file included from drivers/net/bnx2x_main.c:40:
> include/linux/mii.h:140:1: warning: this is the location of the previous definition
>
> Caused by commit e18ce3465477502108187c6c08b6423fb784a313 ("net: Move flow control definitions to mii.h").
> --
Thanks, I'll fix this up with the following two commits:
--------------------
bnx2: Don't redefine FLOW_CTRL_{RX,TX}.
They are provided generically by linux/mii.h now.
Signed-off-by: David S. Miller <davem@davemloft•net>
---
drivers/net/bnx2.h | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bnx2.h b/drivers/net/bnx2.h
index 88f962b..900641a 100644
--- a/drivers/net/bnx2.h
+++ b/drivers/net/bnx2.h
@@ -6848,9 +6848,6 @@ struct bnx2 {
u8 flow_ctrl; /* actual flow ctrl settings */
/* may be different from */
/* req_flow_ctrl if autoneg */
-#define FLOW_CTRL_TX 1
-#define FLOW_CTRL_RX 2
-
u32 advertising;
u8 req_flow_ctrl; /* flow ctrl advertisement */
--
1.5.6.5
--------------------
bnx2x: Fix namespace collision with FLOW_CTRL_{TX,RX}
These are now defined in linux/mii.h and the bnx2x driver
defines different values which are shared with hardware
data structures.
So add a "BNX2X_" prefix to these macro names.
Based upon a report from Stephen Rothwell.
Signed-off-by: David S. Miller <davem@davemloft•net>
---
drivers/net/bnx2x_link.c | 72 +++++++++++++++++++++++-----------------------
drivers/net/bnx2x_link.h | 10 +++---
drivers/net/bnx2x_main.c | 38 ++++++++++++------------
3 files changed, 60 insertions(+), 60 deletions(-)
diff --git a/drivers/net/bnx2x_link.c b/drivers/net/bnx2x_link.c
index 4ce7fe9..67de94f 100644
--- a/drivers/net/bnx2x_link.c
+++ b/drivers/net/bnx2x_link.c
@@ -289,7 +289,7 @@ static u8 bnx2x_emac_enable(struct link_params *params,
/* pause enable/disable */
bnx2x_bits_dis(bp, emac_base + EMAC_REG_EMAC_RX_MODE,
EMAC_RX_MODE_FLOW_EN);
- if (vars->flow_ctrl & FLOW_CTRL_RX)
+ if (vars->flow_ctrl & BNX2X_FLOW_CTRL_RX)
bnx2x_bits_en(bp, emac_base +
EMAC_REG_EMAC_RX_MODE,
EMAC_RX_MODE_FLOW_EN);
@@ -297,7 +297,7 @@ static u8 bnx2x_emac_enable(struct link_params *params,
bnx2x_bits_dis(bp, emac_base + EMAC_REG_EMAC_TX_MODE,
(EMAC_TX_MODE_EXT_PAUSE_EN |
EMAC_TX_MODE_FLOW_EN));
- if (vars->flow_ctrl & FLOW_CTRL_TX)
+ if (vars->flow_ctrl & BNX2X_FLOW_CTRL_TX)
bnx2x_bits_en(bp, emac_base +
EMAC_REG_EMAC_TX_MODE,
(EMAC_TX_MODE_EXT_PAUSE_EN |
@@ -333,7 +333,7 @@ static u8 bnx2x_emac_enable(struct link_params *params,
/* enable the NIG in/out to the emac */
REG_WR(bp, NIG_REG_EMAC0_IN_EN + port*4, 0x1);
val = 0;
- if (vars->flow_ctrl & FLOW_CTRL_TX)
+ if (vars->flow_ctrl & BNX2X_FLOW_CTRL_TX)
val = 1;
REG_WR(bp, NIG_REG_EMAC0_PAUSE_OUT_EN + port*4, val);
@@ -396,7 +396,7 @@ static u8 bnx2x_bmac_enable(struct link_params *params, struct link_vars *vars,
/* tx control */
val = 0xc0;
- if (vars->flow_ctrl & FLOW_CTRL_TX)
+ if (vars->flow_ctrl & BNX2X_FLOW_CTRL_TX)
val |= 0x800000;
wb_data[0] = val;
wb_data[1] = 0;
@@ -423,7 +423,7 @@ static u8 bnx2x_bmac_enable(struct link_params *params, struct link_vars *vars,
/* rx control set to don't strip crc */
val = 0x14;
- if (vars->flow_ctrl & FLOW_CTRL_RX)
+ if (vars->flow_ctrl & BNX2X_FLOW_CTRL_RX)
val |= 0x20;
wb_data[0] = val;
wb_data[1] = 0;
@@ -460,7 +460,7 @@ static u8 bnx2x_bmac_enable(struct link_params *params, struct link_vars *vars,
REG_WR(bp, NIG_REG_XGXS_LANE_SEL_P0 + port*4, 0x0);
REG_WR(bp, NIG_REG_EGRESS_EMAC0_PORT + port*4, 0x0);
val = 0;
- if (vars->flow_ctrl & FLOW_CTRL_TX)
+ if (vars->flow_ctrl & BNX2X_FLOW_CTRL_TX)
val = 1;
REG_WR(bp, NIG_REG_BMAC0_PAUSE_OUT_EN + port*4, val);
REG_WR(bp, NIG_REG_EGRESS_EMAC0_OUT_EN + port*4, 0x0);
@@ -580,14 +580,14 @@ void bnx2x_link_status_update(struct link_params *params,
}
if (vars->link_status & LINK_STATUS_TX_FLOW_CONTROL_ENABLED)
- vars->flow_ctrl |= FLOW_CTRL_TX;
+ vars->flow_ctrl |= BNX2X_FLOW_CTRL_TX;
else
- vars->flow_ctrl &= ~FLOW_CTRL_TX;
+ vars->flow_ctrl &= ~BNX2X_FLOW_CTRL_TX;
if (vars->link_status & LINK_STATUS_RX_FLOW_CONTROL_ENABLED)
- vars->flow_ctrl |= FLOW_CTRL_RX;
+ vars->flow_ctrl |= BNX2X_FLOW_CTRL_RX;
else
- vars->flow_ctrl &= ~FLOW_CTRL_RX;
+ vars->flow_ctrl &= ~BNX2X_FLOW_CTRL_RX;
if (vars->phy_flags & PHY_XGXS_FLAG) {
if (vars->line_speed &&
@@ -618,7 +618,7 @@ void bnx2x_link_status_update(struct link_params *params,
vars->line_speed = 0;
vars->duplex = DUPLEX_FULL;
- vars->flow_ctrl = FLOW_CTRL_NONE;
+ vars->flow_ctrl = BNX2X_FLOW_CTRL_NONE;
/* indicate no mac active */
vars->mac_type = MAC_TYPE_NONE;
@@ -691,7 +691,7 @@ static u8 bnx2x_pbf_update(struct link_params *params, u32 flow_ctrl,
return -EINVAL;
}
- if (flow_ctrl & FLOW_CTRL_RX ||
+ if (flow_ctrl & BNX2X_FLOW_CTRL_RX ||
line_speed == SPEED_10 ||
line_speed == SPEED_100 ||
line_speed == SPEED_1000 ||
@@ -1300,8 +1300,8 @@ static void bnx2x_calc_ieee_aneg_adv(struct link_params *params, u32 *ieee_fc)
* Please refer to Table 28B-3 of the 802.3ab-1999 spec */
switch (params->req_flow_ctrl) {
- case FLOW_CTRL_AUTO:
- if (params->req_fc_auto_adv == FLOW_CTRL_BOTH) {
+ case BNX2X_FLOW_CTRL_AUTO:
+ if (params->req_fc_auto_adv == BNX2X_FLOW_CTRL_BOTH) {
*ieee_fc |=
MDIO_COMBO_IEEE0_AUTO_NEG_ADV_PAUSE_BOTH;
} else {
@@ -1309,17 +1309,17 @@ static void bnx2x_calc_ieee_aneg_adv(struct link_params *params, u32 *ieee_fc)
MDIO_COMBO_IEEE0_AUTO_NEG_ADV_PAUSE_ASYMMETRIC;
}
break;
- case FLOW_CTRL_TX:
+ case BNX2X_FLOW_CTRL_TX:
*ieee_fc |=
MDIO_COMBO_IEEE0_AUTO_NEG_ADV_PAUSE_ASYMMETRIC;
break;
- case FLOW_CTRL_RX:
- case FLOW_CTRL_BOTH:
+ case BNX2X_FLOW_CTRL_RX:
+ case BNX2X_FLOW_CTRL_BOTH:
*ieee_fc |= MDIO_COMBO_IEEE0_AUTO_NEG_ADV_PAUSE_BOTH;
break;
- case FLOW_CTRL_NONE:
+ case BNX2X_FLOW_CTRL_NONE:
default:
*ieee_fc |= MDIO_COMBO_IEEE0_AUTO_NEG_ADV_PAUSE_NONE;
break;
@@ -1463,18 +1463,18 @@ static void bnx2x_pause_resolve(struct link_vars *vars, u32 pause_result)
{ /* LD LP */
switch (pause_result) { /* ASYM P ASYM P */
case 0xb: /* 1 0 1 1 */
- vars->flow_ctrl = FLOW_CTRL_TX;
+ vars->flow_ctrl = BNX2X_FLOW_CTRL_TX;
break;
case 0xe: /* 1 1 1 0 */
- vars->flow_ctrl = FLOW_CTRL_RX;
+ vars->flow_ctrl = BNX2X_FLOW_CTRL_RX;
break;
case 0x5: /* 0 1 0 1 */
case 0x7: /* 0 1 1 1 */
case 0xd: /* 1 1 0 1 */
case 0xf: /* 1 1 1 1 */
- vars->flow_ctrl = FLOW_CTRL_BOTH;
+ vars->flow_ctrl = BNX2X_FLOW_CTRL_BOTH;
break;
default:
@@ -1531,7 +1531,7 @@ static u8 bnx2x_ext_phy_resove_fc(struct link_params *params,
DP(NETIF_MSG_LINK, "Ext PHY pause result 0x%x \n",
pause_result);
bnx2x_pause_resolve(vars, pause_result);
- if (vars->flow_ctrl == FLOW_CTRL_NONE &&
+ if (vars->flow_ctrl == BNX2X_FLOW_CTRL_NONE &&
ext_phy_type == PORT_HW_CFG_XGXS_EXT_PHY_TYPE_BCM8073) {
bnx2x_cl45_read(bp, port,
ext_phy_type,
@@ -1567,10 +1567,10 @@ static void bnx2x_flow_ctrl_resolve(struct link_params *params,
u16 lp_pause; /* link partner */
u16 pause_result;
- vars->flow_ctrl = FLOW_CTRL_NONE;
+ vars->flow_ctrl = BNX2X_FLOW_CTRL_NONE;
/* resolve from gp_status in case of AN complete and not sgmii */
- if ((params->req_flow_ctrl == FLOW_CTRL_AUTO) &&
+ if ((params->req_flow_ctrl == BNX2X_FLOW_CTRL_AUTO) &&
(gp_status & MDIO_AN_CL73_OR_37_COMPLETE) &&
(!(vars->phy_flags & PHY_SGMII_FLAG)) &&
(XGXS_EXT_PHY_TYPE(params->ext_phy_config) ==
@@ -1591,11 +1591,11 @@ static void bnx2x_flow_ctrl_resolve(struct link_params *params,
MDIO_COMBO_IEEE0_AUTO_NEG_ADV_PAUSE_MASK)>>7;
DP(NETIF_MSG_LINK, "pause_result 0x%x\n", pause_result);
bnx2x_pause_resolve(vars, pause_result);
- } else if ((params->req_flow_ctrl == FLOW_CTRL_AUTO) &&
+ } else if ((params->req_flow_ctrl == BNX2X_FLOW_CTRL_AUTO) &&
(bnx2x_ext_phy_resove_fc(params, vars))) {
return;
} else {
- if (params->req_flow_ctrl == FLOW_CTRL_AUTO)
+ if (params->req_flow_ctrl == BNX2X_FLOW_CTRL_AUTO)
vars->flow_ctrl = params->req_fc_auto_adv;
else
vars->flow_ctrl = params->req_flow_ctrl;
@@ -1728,11 +1728,11 @@ static u8 bnx2x_link_settings_status(struct link_params *params,
LINK_STATUS_PARALLEL_DETECTION_USED;
}
- if (vars->flow_ctrl & FLOW_CTRL_TX)
+ if (vars->flow_ctrl & BNX2X_FLOW_CTRL_TX)
vars->link_status |=
LINK_STATUS_TX_FLOW_CONTROL_ENABLED;
- if (vars->flow_ctrl & FLOW_CTRL_RX)
+ if (vars->flow_ctrl & BNX2X_FLOW_CTRL_RX)
vars->link_status |=
LINK_STATUS_RX_FLOW_CONTROL_ENABLED;
@@ -1742,7 +1742,7 @@ static u8 bnx2x_link_settings_status(struct link_params *params,
vars->phy_link_up = 0;
vars->duplex = DUPLEX_FULL;
- vars->flow_ctrl = FLOW_CTRL_NONE;
+ vars->flow_ctrl = BNX2X_FLOW_CTRL_NONE;
vars->autoneg = AUTO_NEG_DISABLED;
vars->mac_type = MAC_TYPE_NONE;
}
@@ -3924,7 +3924,7 @@ u8 bnx2x_phy_init(struct link_params *params, struct link_vars *vars)
vars->link_up = 0;
vars->line_speed = 0;
vars->duplex = DUPLEX_FULL;
- vars->flow_ctrl = FLOW_CTRL_NONE;
+ vars->flow_ctrl = BNX2X_FLOW_CTRL_NONE;
vars->mac_type = MAC_TYPE_NONE;
if (params->switch_cfg == SWITCH_CFG_1G)
@@ -3946,12 +3946,12 @@ u8 bnx2x_phy_init(struct link_params *params, struct link_vars *vars)
vars->link_up = 1;
vars->line_speed = SPEED_10000;
vars->duplex = DUPLEX_FULL;
- vars->flow_ctrl = FLOW_CTRL_NONE;
+ vars->flow_ctrl = BNX2X_FLOW_CTRL_NONE;
vars->link_status = (LINK_STATUS_LINK_UP | LINK_10GTFD);
/* enable on E1.5 FPGA */
if (CHIP_IS_E1H(bp)) {
vars->flow_ctrl |=
- (FLOW_CTRL_TX | FLOW_CTRL_RX);
+ (BNX2X_FLOW_CTRL_TX | BNX2X_FLOW_CTRL_RX);
vars->link_status |=
(LINK_STATUS_TX_FLOW_CONTROL_ENABLED |
LINK_STATUS_RX_FLOW_CONTROL_ENABLED);
@@ -3974,7 +3974,7 @@ u8 bnx2x_phy_init(struct link_params *params, struct link_vars *vars)
vars->link_up = 1;
vars->line_speed = SPEED_10000;
vars->duplex = DUPLEX_FULL;
- vars->flow_ctrl = FLOW_CTRL_NONE;
+ vars->flow_ctrl = BNX2X_FLOW_CTRL_NONE;
vars->link_status = (LINK_STATUS_LINK_UP | LINK_10GTFD);
bnx2x_bmac_enable(params, vars, 0);
@@ -3994,7 +3994,7 @@ u8 bnx2x_phy_init(struct link_params *params, struct link_vars *vars)
vars->link_up = 1;
vars->line_speed = SPEED_10000;
vars->duplex = DUPLEX_FULL;
- vars->flow_ctrl = FLOW_CTRL_NONE;
+ vars->flow_ctrl = BNX2X_FLOW_CTRL_NONE;
vars->mac_type = MAC_TYPE_BMAC;
vars->phy_flags = PHY_XGXS_FLAG;
@@ -4009,7 +4009,7 @@ u8 bnx2x_phy_init(struct link_params *params, struct link_vars *vars)
vars->link_up = 1;
vars->line_speed = SPEED_1000;
vars->duplex = DUPLEX_FULL;
- vars->flow_ctrl = FLOW_CTRL_NONE;
+ vars->flow_ctrl = BNX2X_FLOW_CTRL_NONE;
vars->mac_type = MAC_TYPE_EMAC;
vars->phy_flags = PHY_XGXS_FLAG;
@@ -4026,7 +4026,7 @@ u8 bnx2x_phy_init(struct link_params *params, struct link_vars *vars)
vars->link_up = 1;
vars->line_speed = SPEED_10000;
vars->duplex = DUPLEX_FULL;
- vars->flow_ctrl = FLOW_CTRL_NONE;
+ vars->flow_ctrl = BNX2X_FLOW_CTRL_NONE;
vars->phy_flags = PHY_XGXS_FLAG;
diff --git a/drivers/net/bnx2x_link.h b/drivers/net/bnx2x_link.h
index 86d54a1..47cb585 100644
--- a/drivers/net/bnx2x_link.h
+++ b/drivers/net/bnx2x_link.h
@@ -26,11 +26,11 @@
-#define FLOW_CTRL_AUTO PORT_FEATURE_FLOW_CONTROL_AUTO
-#define FLOW_CTRL_TX PORT_FEATURE_FLOW_CONTROL_TX
-#define FLOW_CTRL_RX PORT_FEATURE_FLOW_CONTROL_RX
-#define FLOW_CTRL_BOTH PORT_FEATURE_FLOW_CONTROL_BOTH
-#define FLOW_CTRL_NONE PORT_FEATURE_FLOW_CONTROL_NONE
+#define BNX2X_FLOW_CTRL_AUTO PORT_FEATURE_FLOW_CONTROL_AUTO
+#define BNX2X_FLOW_CTRL_TX PORT_FEATURE_FLOW_CONTROL_TX
+#define BNX2X_FLOW_CTRL_RX PORT_FEATURE_FLOW_CONTROL_RX
+#define BNX2X_FLOW_CTRL_BOTH PORT_FEATURE_FLOW_CONTROL_BOTH
+#define BNX2X_FLOW_CTRL_NONE PORT_FEATURE_FLOW_CONTROL_NONE
#define SPEED_AUTO_NEG 0
#define SPEED_12000 12000
diff --git a/drivers/net/bnx2x_main.c b/drivers/net/bnx2x_main.c
index a9c4de0..24d2ae8 100644
--- a/drivers/net/bnx2x_main.c
+++ b/drivers/net/bnx2x_main.c
@@ -1921,10 +1921,10 @@ static void bnx2x_link_report(struct bnx2x *bp)
else
printk("half duplex");
- if (bp->link_vars.flow_ctrl != FLOW_CTRL_NONE) {
- if (bp->link_vars.flow_ctrl & FLOW_CTRL_RX) {
+ if (bp->link_vars.flow_ctrl != BNX2X_FLOW_CTRL_NONE) {
+ if (bp->link_vars.flow_ctrl & BNX2X_FLOW_CTRL_RX) {
printk(", receive ");
- if (bp->link_vars.flow_ctrl & FLOW_CTRL_TX)
+ if (bp->link_vars.flow_ctrl & BNX2X_FLOW_CTRL_TX)
printk("& transmit ");
} else {
printk(", transmit ");
@@ -1948,11 +1948,11 @@ static u8 bnx2x_initial_phy_init(struct bnx2x *bp)
/* It is recommended to turn off RX FC for jumbo frames
for better performance */
if (IS_E1HMF(bp))
- bp->link_params.req_fc_auto_adv = FLOW_CTRL_BOTH;
+ bp->link_params.req_fc_auto_adv = BNX2X_FLOW_CTRL_BOTH;
else if (bp->dev->mtu > 5000)
- bp->link_params.req_fc_auto_adv = FLOW_CTRL_TX;
+ bp->link_params.req_fc_auto_adv = BNX2X_FLOW_CTRL_TX;
else
- bp->link_params.req_fc_auto_adv = FLOW_CTRL_BOTH;
+ bp->link_params.req_fc_auto_adv = BNX2X_FLOW_CTRL_BOTH;
bnx2x_acquire_phy_lock(bp);
rc = bnx2x_phy_init(&bp->link_params, &bp->link_vars);
@@ -7362,9 +7362,9 @@ static void __devinit bnx2x_link_settings_requested(struct bnx2x *bp)
bp->link_params.req_flow_ctrl = (bp->port.link_config &
PORT_FEATURE_FLOW_CONTROL_MASK);
- if ((bp->link_params.req_flow_ctrl == FLOW_CTRL_AUTO) &&
+ if ((bp->link_params.req_flow_ctrl == BNX2X_FLOW_CTRL_AUTO) &&
!(bp->port.supported & SUPPORTED_Autoneg))
- bp->link_params.req_flow_ctrl = FLOW_CTRL_NONE;
+ bp->link_params.req_flow_ctrl = BNX2X_FLOW_CTRL_NONE;
BNX2X_DEV_INFO("req_line_speed %d req_duplex %d req_flow_ctrl 0x%x"
" advertising 0x%x\n",
@@ -8353,13 +8353,13 @@ static void bnx2x_get_pauseparam(struct net_device *dev,
{
struct bnx2x *bp = netdev_priv(dev);
- epause->autoneg = (bp->link_params.req_flow_ctrl == FLOW_CTRL_AUTO) &&
+ epause->autoneg = (bp->link_params.req_flow_ctrl == BNX2X_FLOW_CTRL_AUTO) &&
(bp->link_params.req_line_speed == SPEED_AUTO_NEG);
- epause->rx_pause = ((bp->link_vars.flow_ctrl & FLOW_CTRL_RX) ==
- FLOW_CTRL_RX);
- epause->tx_pause = ((bp->link_vars.flow_ctrl & FLOW_CTRL_TX) ==
- FLOW_CTRL_TX);
+ epause->rx_pause = ((bp->link_vars.flow_ctrl & BNX2X_FLOW_CTRL_RX) ==
+ BNX2X_FLOW_CTRL_RX);
+ epause->tx_pause = ((bp->link_vars.flow_ctrl & BNX2X_FLOW_CTRL_TX) ==
+ BNX2X_FLOW_CTRL_TX);
DP(NETIF_MSG_LINK, "ethtool_pauseparam: cmd %d\n"
DP_LEVEL " autoneg %d rx_pause %d tx_pause %d\n",
@@ -8378,16 +8378,16 @@ static int bnx2x_set_pauseparam(struct net_device *dev,
DP_LEVEL " autoneg %d rx_pause %d tx_pause %d\n",
epause->cmd, epause->autoneg, epause->rx_pause, epause->tx_pause);
- bp->link_params.req_flow_ctrl = FLOW_CTRL_AUTO;
+ bp->link_params.req_flow_ctrl = BNX2X_FLOW_CTRL_AUTO;
if (epause->rx_pause)
- bp->link_params.req_flow_ctrl |= FLOW_CTRL_RX;
+ bp->link_params.req_flow_ctrl |= BNX2X_FLOW_CTRL_RX;
if (epause->tx_pause)
- bp->link_params.req_flow_ctrl |= FLOW_CTRL_TX;
+ bp->link_params.req_flow_ctrl |= BNX2X_FLOW_CTRL_TX;
- if (bp->link_params.req_flow_ctrl == FLOW_CTRL_AUTO)
- bp->link_params.req_flow_ctrl = FLOW_CTRL_NONE;
+ if (bp->link_params.req_flow_ctrl == BNX2X_FLOW_CTRL_AUTO)
+ bp->link_params.req_flow_ctrl = BNX2X_FLOW_CTRL_NONE;
if (epause->autoneg) {
if (!(bp->port.supported & SUPPORTED_Autoneg)) {
@@ -8396,7 +8396,7 @@ static int bnx2x_set_pauseparam(struct net_device *dev,
}
if (bp->link_params.req_line_speed == SPEED_AUTO_NEG)
- bp->link_params.req_flow_ctrl = FLOW_CTRL_AUTO;
+ bp->link_params.req_flow_ctrl = BNX2X_FLOW_CTRL_AUTO;
}
DP(NETIF_MSG_LINK,
--
1.5.6.5
^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: linux-next: net tree build warnings
2008-12-17 7:53 ` David Miller
@ 2008-12-17 8:04 ` Eilon Greenstein
0 siblings, 0 replies; 27+ messages in thread
From: Eilon Greenstein @ 2008-12-17 8:04 UTC (permalink / raw)
To: David Miller
Cc: sfr@canb•auug.org.au, linux-next@vger•kernel.org,
steve.glendinning@smsc•com, Yaniv Rosner
On Tue, 2008-12-16 at 23:53 -0800, David Miller wrote:
> From: Stephen Rothwell <sfr@canb•auug.org.au>
> Date: Wed, 17 Dec 2008 18:22:24 +1100
>
> > Today's linux-next build (x86_64 allmodconfig) produced these warnings:
> >
> > In file included from drivers/net/bnx2x_main.c:58:
> > drivers/net/bnx2x_link.h:30:1: warning: "FLOW_CTRL_TX" redefined
> > In file included from drivers/net/bnx2x_main.c:40:
> > include/linux/mii.h:139:1: warning: this is the location of the previous definition
> > In file included from drivers/net/bnx2x_main.c:58:
> > drivers/net/bnx2x_link.h:31:1: warning: "FLOW_CTRL_RX" redefined
> > In file included from drivers/net/bnx2x_main.c:40:
> > include/linux/mii.h:140:1: warning: this is the location of the previous definition
> >
> > Caused by commit e18ce3465477502108187c6c08b6423fb784a313 ("net: Move flow control definitions to mii.h").
> > --
>
> Thanks, I'll fix this up with the following two commits:
>
....
> --------------------
> bnx2x: Fix namespace collision with FLOW_CTRL_{TX,RX}
>
> These are now defined in linux/mii.h and the bnx2x driver
> defines different values which are shared with hardware
> data structures.
>
> So add a "BNX2X_" prefix to these macro names.
>
> Based upon a report from Stephen Rothwell.
>
> Signed-off-by: David S. Miller <davem@davemloft•net>
> ---
> drivers/net/bnx2x_link.c | 72 +++++++++++++++++++++++-----------------------
> drivers/net/bnx2x_link.h | 10 +++---
> drivers/net/bnx2x_main.c | 38 ++++++++++++------------
> 3 files changed, 60 insertions(+), 60 deletions(-)
Thanks Dave - I was just writing the email header for the exact same
fix ;)
Funny how we both miraculously chose the same prefix...
Thanks,
Eilon
^ permalink raw reply [flat|nested] 27+ messages in thread
* linux-next: net tree build warnings
@ 2009-03-16 6:03 Stephen Rothwell
2009-03-16 6:05 ` Dhananjay Phadke
0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2009-03-16 6:03 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-next, Dhananjay Phadke
[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]
Hi Dave,
Today's (and for a while) linux-next build (x86_64 allmodconfig) produced
these warnings:
drivers/net/netxen/netxen_nic_hw.c: In function 'netxen_load_firmware':
drivers/net/netxen/netxen_nic_hw.c:1146: warning: comparison with string literal results in unspecified behavior
drivers/net/netxen/netxen_nic_hw.c:1146: warning: comparison with string literal results in unspecified behavior
drivers/net/netxen/netxen_nic_hw.c:1146: warning: comparison with string literal results in unspecified behavior
drivers/net/netxen/netxen_nic_hw.c:1159: warning: comparison with string literal results in unspecified behavior
drivers/net/netxen/netxen_nic_hw.c:1159: warning: comparison with string literal results in unspecified behavior
drivers/net/netxen/netxen_nic_hw.c:1159: warning: comparison with string literal results in unspecified behavior
Introduced by commit 567c6c4e2b92f4b8632b043f9395b216b7e7c3ce ("netxen:
firmware download improvements").
--
Cheers,
Stephen Rothwell sfr@canb•auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: linux-next: net tree build warnings
2009-03-16 6:03 Stephen Rothwell
@ 2009-03-16 6:05 ` Dhananjay Phadke
0 siblings, 0 replies; 27+ messages in thread
From: Dhananjay Phadke @ 2009-03-16 6:05 UTC (permalink / raw)
To: Stephen Rothwell, David S. Miller; +Cc: linux-next@vger•kernel.org
This has been introduced before 567c6c4e2b92f4b86, I'll post a fix (needs a little work).
Thanks,
-Dhananjay
________________________________________
From: Stephen Rothwell [sfr@canb•auug.org.au]
Sent: Sunday, March 15, 2009 11:03 PM
To: David S. Miller
Cc: linux-next@vger•kernel.org; Dhananjay Phadke
Subject: linux-next: net tree build warnings
Hi Dave,
Today's (and for a while) linux-next build (x86_64 allmodconfig) produced
these warnings:
drivers/net/netxen/netxen_nic_hw.c: In function 'netxen_load_firmware':
drivers/net/netxen/netxen_nic_hw.c:1146: warning: comparison with string literal results in unspecified behavior
drivers/net/netxen/netxen_nic_hw.c:1146: warning: comparison with string literal results in unspecified behavior
drivers/net/netxen/netxen_nic_hw.c:1146: warning: comparison with string literal results in unspecified behavior
drivers/net/netxen/netxen_nic_hw.c:1159: warning: comparison with string literal results in unspecified behavior
drivers/net/netxen/netxen_nic_hw.c:1159: warning: comparison with string literal results in unspecified behavior
drivers/net/netxen/netxen_nic_hw.c:1159: warning: comparison with string literal results in unspecified behavior
Introduced by commit 567c6c4e2b92f4b8632b043f9395b216b7e7c3ce ("netxen:
firmware download improvements").
--
Cheers,
Stephen Rothwell sfr@canb•auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply [flat|nested] 27+ messages in thread
* linux-next: net tree build warnings
@ 2009-03-26 6:37 Stephen Rothwell
2009-03-26 7:50 ` Eric Leblond
0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2009-03-26 6:37 UTC (permalink / raw)
To: David S. Miller
Cc: linux-next, Eric Leblond, Patrick McHardy, netdev,
netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]
Hi Dave,
Today's linux-next build (x86_64 allmodconfig) produced these warnings:
net/bridge/netfilter/ebt_log.c: In function 'ebt_log_init':
net/bridge/netfilter/ebt_log.c:230: warning: passing argument 2 of 'nf_log_register' discards qualifiers from pointer target type
net/bridge/netfilter/ebt_log.c: In function 'ebt_log_fini':
net/bridge/netfilter/ebt_log.c:236: warning: passing argument 1 of 'nf_log_unregister' discards qualifiers from pointer target type
net/bridge/netfilter/ebt_ulog.c: In function 'ebt_ulog_init':
net/bridge/netfilter/ebt_ulog.c:317: warning: passing argument 2 of 'nf_log_register' discards qualifiers from pointer target type
net/bridge/netfilter/ebt_ulog.c: In function 'ebt_ulog_fini':
net/bridge/netfilter/ebt_ulog.c:327: warning: passing argument 1 of 'nf_log_unregister' discards qualifiers from pointer target type
Caused by commit ca735b3aaa945626ba65a3e51145bfe4ecd9e222 ("netfilter:
use a linked list of loggers") which removed const from the "struct
nf_logger *" arguments.
--
Cheers,
Stephen Rothwell sfr@canb•auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: net tree build warnings
2009-03-26 6:37 Stephen Rothwell
@ 2009-03-26 7:50 ` Eric Leblond
2009-03-26 13:17 ` Patrick McHardy
2009-03-26 22:01 ` Stephen Rothwell
0 siblings, 2 replies; 27+ messages in thread
From: Eric Leblond @ 2009-03-26 7:50 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David S. Miller, linux-next, Patrick McHardy, netdev,
netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 1744 bytes --]
Hi Stephen,
Le jeudi 26 mars 2009 à 17:37 +1100, Stephen Rothwell a écrit :
> Hi Dave,
>
> Today's linux-next build (x86_64 allmodconfig) produced these warnings:
>
> net/bridge/netfilter/ebt_log.c: In function 'ebt_log_init':
> net/bridge/netfilter/ebt_log.c:230: warning: passing argument 2 of 'nf_log_register' discards qualifiers from pointer target type
> net/bridge/netfilter/ebt_log.c: In function 'ebt_log_fini':
> net/bridge/netfilter/ebt_log.c:236: warning: passing argument 1 of 'nf_log_unregister' discards qualifiers from pointer target type
> net/bridge/netfilter/ebt_ulog.c: In function 'ebt_ulog_init':
> net/bridge/netfilter/ebt_ulog.c:317: warning: passing argument 2 of 'nf_log_register' discards qualifiers from pointer target type
> net/bridge/netfilter/ebt_ulog.c: In function 'ebt_ulog_fini':
> net/bridge/netfilter/ebt_ulog.c:327: warning: passing argument 1 of 'nf_log_unregister' discards qualifiers from pointer target type
Thanks a lot for pointing this. I stupidely forgot to build this module
during my testing.
I've made the necessary modifications and a patch fixing this will
follow this mail.
Doing some testing of the ebt_ulog module, I've found some problems. One
of them was the following messages:
sys_init_module: 'ebt_ulog'->init suspiciously returned 1, it should
follow 0/-E convention
sys_init_module: loading module anyway...
Pid: 2334, comm: modprobe Not tainted 2.6.29-rc5edenwall0-00883-g199e57b
#146
Call Trace:
[<c0441b81>] ? printk+0xf/0x16
[<c02311af>] sys_init_module+0x107/0x186
[<c0202cfa>] syscall_call+0x7/0xb
A patch fixing this will also follow.
BR,
--
Eric Leblond <eric@inl•fr>
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/
[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: net tree build warnings
2009-03-26 7:50 ` Eric Leblond
@ 2009-03-26 13:17 ` Patrick McHardy
2009-03-26 22:01 ` Stephen Rothwell
1 sibling, 0 replies; 27+ messages in thread
From: Patrick McHardy @ 2009-03-26 13:17 UTC (permalink / raw)
To: Eric Leblond
Cc: Stephen Rothwell, David S. Miller, linux-next, netdev,
netfilter-devel
Eric Leblond wrote:
> Hi Stephen,
>
> Le jeudi 26 mars 2009 à 17:37 +1100, Stephen Rothwell a écrit :
>> Hi Dave,
>>
>> Today's linux-next build (x86_64 allmodconfig) produced these warnings:
>>
>> net/bridge/netfilter/ebt_log.c: In function 'ebt_log_init':
>> net/bridge/netfilter/ebt_log.c:230: warning: passing argument 2 of 'nf_log_register' discards qualifiers from pointer target type
>> net/bridge/netfilter/ebt_log.c: In function 'ebt_log_fini':
>> net/bridge/netfilter/ebt_log.c:236: warning: passing argument 1 of 'nf_log_unregister' discards qualifiers from pointer target type
>> net/bridge/netfilter/ebt_ulog.c: In function 'ebt_ulog_init':
>> net/bridge/netfilter/ebt_ulog.c:317: warning: passing argument 2 of 'nf_log_register' discards qualifiers from pointer target type
>> net/bridge/netfilter/ebt_ulog.c: In function 'ebt_ulog_fini':
>> net/bridge/netfilter/ebt_ulog.c:327: warning: passing argument 1 of 'nf_log_unregister' discards qualifiers from pointer target type
>
> Thanks a lot for pointing this. I stupidely forgot to build this module
> during my testing.
Same here, I seem to have accidentally disabled bridging in my test
builds, sorry.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger•kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: net tree build warnings
2009-03-26 7:50 ` Eric Leblond
2009-03-26 13:17 ` Patrick McHardy
@ 2009-03-26 22:01 ` Stephen Rothwell
1 sibling, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2009-03-26 22:01 UTC (permalink / raw)
To: Eric Leblond
Cc: David S. Miller, linux-next, Patrick McHardy, netdev,
netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 397 bytes --]
Hi Eric,
On Thu, 26 Mar 2009 08:50:19 +0100 Eric Leblond <eric@inl•fr> wrote:
>
> Thanks a lot for pointing this. I stupidely forgot to build this module
> during my testing.
>
> I've made the necessary modifications and a patch fixing this will
> follow this mail.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb•auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* linux-next: net tree build warnings
@ 2009-04-29 4:59 Stephen Rothwell
2009-04-29 6:02 ` David Miller
0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2009-04-29 4:59 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-next, Alexander Beregalov
[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]
Hi Dave,
Today's linux-next build (x86_64 allmodconfig) produced these warnings:
drivers/net/vxge/vxge-traffic.c: In function '__vxge_hw_vpath_alarm_process':
drivers/net/vxge/vxge-traffic.c:1924: warning: comparison of distinct pointer types lacks a cast
drivers/net/vxge/vxge-traffic.c:1934: warning: comparison of distinct pointer types lacks a cast
drivers/net/vxge/vxge-traffic.c:1948: warning: comparison of distinct pointer types lacks a cast
drivers/net/vxge/vxge-traffic.c:1978: warning: comparison of distinct pointer types lacks a cast
drivers/net/vxge/vxge-traffic.c:1999: warning: comparison of distinct pointer types lacks a cast
drivers/net/vxge/vxge-traffic.c:2006: warning: comparison of distinct pointer types lacks a cast
drivers/net/vxge/vxge-traffic.c:2029: warning: comparison of distinct pointer types lacks a cast
drivers/net/vxge/vxge-traffic.c:2038: warning: comparison of distinct pointer types lacks a cast
drivers/net/vxge/vxge-traffic.c:2060: warning: comparison of distinct pointer types lacks a cast
drivers/net/vxge/vxge-traffic.c:2076: warning: comparison of distinct pointer types lacks a cast
drivers/net/vxge/vxge-traffic.c:2085: warning: comparison of distinct pointer types lacks a cast
drivers/net/vxge/vxge-traffic.c:2094: warning: comparison of distinct pointer types lacks a cast
drivers/net/vxge/vxge-traffic.c:2101: warning: comparison of distinct pointer types lacks a cast
drivers/net/vxge/vxge-traffic.c:2125: warning: comparison of distinct pointer types lacks a cast
drivers/net/vxge/vxge-traffic.c:2133: warning: comparison of distinct pointer types lacks a cast
drivers/net/vxge/vxge-traffic.c:2141: warning: comparison of distinct pointer types lacks a cast
drivers/net/vxge/vxge-traffic.c:2148: warning: comparison of distinct pointer types lacks a cast
Caused by commit 011983048a120e520147361be1067dd82343038e ("vxge: use max()
instead of VXGE_HW_SET_LEVEL").
--
Cheers,
Stephen Rothwell sfr@canb•auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: net tree build warnings
2009-04-29 4:59 Stephen Rothwell
@ 2009-04-29 6:02 ` David Miller
2009-04-30 0:54 ` David Miller
0 siblings, 1 reply; 27+ messages in thread
From: David Miller @ 2009-04-29 6:02 UTC (permalink / raw)
To: sfr; +Cc: linux-next, a.beregalov
From: Stephen Rothwell <sfr@canb•auug.org.au>
Date: Wed, 29 Apr 2009 14:59:21 +1000
> Caused by commit 011983048a120e520147361be1067dd82343038e ("vxge: use max()
> instead of VXGE_HW_SET_LEVEL").
Maybe that's why the macro was used in the first place :-)
We probably have to use something like max_t() here, and to me that's
worse than the macro it is replacing.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: net tree build warnings
2009-04-29 6:02 ` David Miller
@ 2009-04-30 0:54 ` David Miller
2009-04-30 7:06 ` Stephen Rothwell
0 siblings, 1 reply; 27+ messages in thread
From: David Miller @ 2009-04-30 0:54 UTC (permalink / raw)
To: sfr; +Cc: linux-next, a.beregalov
From: David Miller <davem@davemloft•net>
Date: Tue, 28 Apr 2009 23:02:32 -0700 (PDT)
> From: Stephen Rothwell <sfr@canb•auug.org.au>
> Date: Wed, 29 Apr 2009 14:59:21 +1000
>
>> Caused by commit 011983048a120e520147361be1067dd82343038e ("vxge: use max()
>> instead of VXGE_HW_SET_LEVEL").
>
> Maybe that's why the macro was used in the first place :-)
>
> We probably have to use something like max_t() here, and to me that's
> worse than the macro it is replacing.
Nobody is doing anything about this so I'm simply reverting.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: net tree build warnings
2009-04-30 0:54 ` David Miller
@ 2009-04-30 7:06 ` Stephen Rothwell
0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2009-04-30 7:06 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, a.beregalov
[-- Attachment #1: Type: text/plain, Size: 798 bytes --]
Hi Dave,
On Wed, 29 Apr 2009 17:54:13 -0700 (PDT) David Miller <davem@davemloft•net> wrote:
>
> From: David Miller <davem@davemloft•net>
> Date: Tue, 28 Apr 2009 23:02:32 -0700 (PDT)
>
> > From: Stephen Rothwell <sfr@canb•auug.org.au>
> > Date: Wed, 29 Apr 2009 14:59:21 +1000
> >
> >> Caused by commit 011983048a120e520147361be1067dd82343038e ("vxge: use max()
> >> instead of VXGE_HW_SET_LEVEL").
> >
> > Maybe that's why the macro was used in the first place :-)
> >
> > We probably have to use something like max_t() here, and to me that's
> > worse than the macro it is replacing.
>
> Nobody is doing anything about this so I'm simply reverting.
OK, thanks.
--
Cheers,
Stephen Rothwell sfr@canb•auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* linux-next: net tree build warnings
@ 2009-06-11 4:55 Stephen Rothwell
2009-06-11 6:47 ` David Miller
0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2009-06-11 4:55 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-next, linux-kernel, Sergey Lapin
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
Hi Dave,
Today's linux-next build (x86_64 allmodconfig) produced these warnings:
net/ieee802154/raw.c: In function 'raw_sendmsg':
net/ieee802154/raw.c:135: warning: format '%u' expects type 'unsigned int', but argument 2 has type 'size_t'
net/ieee802154/dgram.c: In function 'dgram_sendmsg':
net/ieee802154/dgram.c:251: warning: format '%u' expects type 'unsigned int', but argument 2 has type 'size_t'
Introduced by commit 9ec7671603573ede31207eb5b0b3e1aa211b2854 ("net: add
IEEE 802.15.4 socket family implementation").
--
Cheers,
Stephen Rothwell sfr@canb•auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: net tree build warnings
2009-06-11 4:55 Stephen Rothwell
@ 2009-06-11 6:47 ` David Miller
2009-06-11 7:20 ` Stephen Rothwell
0 siblings, 1 reply; 27+ messages in thread
From: David Miller @ 2009-06-11 6:47 UTC (permalink / raw)
To: sfr; +Cc: linux-next, linux-kernel, slapin
From: Stephen Rothwell <sfr@canb•auug.org.au>
Date: Thu, 11 Jun 2009 14:55:41 +1000
> Today's linux-next build (x86_64 allmodconfig) produced these warnings:
>
> net/ieee802154/raw.c: In function 'raw_sendmsg':
> net/ieee802154/raw.c:135: warning: format '%u' expects type 'unsigned int', but argument 2 has type 'size_t'
> net/ieee802154/dgram.c: In function 'dgram_sendmsg':
> net/ieee802154/dgram.c:251: warning: format '%u' expects type 'unsigned int', but argument 2 has type 'size_t'
>
> Introduced by commit 9ec7671603573ede31207eb5b0b3e1aa211b2854 ("net: add
> IEEE 802.15.4 socket family implementation").
Similar to what you reported yesterday :-)
I'll get this fixed.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: net tree build warnings
2009-06-11 6:47 ` David Miller
@ 2009-06-11 7:20 ` Stephen Rothwell
0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2009-06-11 7:20 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, linux-kernel, slapin
[-- Attachment #1: Type: text/plain, Size: 373 bytes --]
Hi Dave,
On Wed, 10 Jun 2009 23:47:57 -0700 (PDT) David Miller <davem@davemloft•net> wrote:
>
> Similar to what you reported yesterday :-)
I wondered if I had done that - looks like senility is creeping up on
me. :-(
> I'll get this fixed.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb•auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* linux-next: net tree build warnings
@ 2009-09-04 4:34 Stephen Rothwell
2009-09-04 4:35 ` David Miller
0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2009-09-04 4:34 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-next, linux-kernel, Stephen Hemminger, netdev
[-- Attachment #1: Type: text/plain, Size: 554 bytes --]
Hi Dave,
Today's linux-next build (x86_64 allmodconfig gcc-4.4.0) produced thes
warnings:
drivers/net/wan/dlci.c: In function 'dlci_transmit':
drivers/net/wan/dlci.c:205: warning: enumeration value 'NETDEV_TX_LOCKED' not handled in switch
drivers/net/wan/dlci.c:215: warning: case value '2' not in enumerated type 'netdev_tx_t'
Introduced by commit d71a674922e7519edb477ecb585e7d29d69c7aa7 ("wan:
convert drivers to netdev_tx_t").
--
Cheers,
Stephen Rothwell sfr@canb•auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: net tree build warnings
2009-09-04 4:34 linux-next: net tree build warnings Stephen Rothwell
@ 2009-09-04 4:35 ` David Miller
2009-09-04 15:33 ` [PATCH net-next] wan: dlci/sdla transmit return dehacking Stephen Hemminger
0 siblings, 1 reply; 27+ messages in thread
From: David Miller @ 2009-09-04 4:35 UTC (permalink / raw)
To: sfr; +Cc: linux-next, linux-kernel, shemminger, netdev
From: Stephen Rothwell <sfr@canb•auug.org.au>
Date: Fri, 4 Sep 2009 14:34:39 +1000
> Today's linux-next build (x86_64 allmodconfig gcc-4.4.0) produced thes
> warnings:
>
> drivers/net/wan/dlci.c: In function 'dlci_transmit':
> drivers/net/wan/dlci.c:205: warning: enumeration value 'NETDEV_TX_LOCKED' not handled in switch
> drivers/net/wan/dlci.c:215: warning: case value '2' not in enumerated type 'netdev_tx_t'
>
> Introduced by commit d71a674922e7519edb477ecb585e7d29d69c7aa7 ("wan:
> convert drivers to netdev_tx_t").
I know about it, this code sucks and it's not easy to quelch that
one trivially.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH net-next] wan: dlci/sdla transmit return dehacking
2009-09-04 4:35 ` David Miller
@ 2009-09-04 15:33 ` Stephen Hemminger
2009-09-04 18:48 ` Krzysztof Halasa
2009-09-07 8:57 ` David Miller
0 siblings, 2 replies; 27+ messages in thread
From: Stephen Hemminger @ 2009-09-04 15:33 UTC (permalink / raw)
To: David Miller, Krzysztof Halasa; +Cc: sfr, linux-next, netdev
This is a brute force removal of the wierd slave interface done for DLCI -> SDLA
transmit. Before it was using non-standard return values and freeing skb in caller.
This changes it to using normal return values, and freeing in the callee.
Luckly only one driver pair was doing this. Not tested on real hardware,
in fact I wonder if this driver pair is even being used by any users.
Signed-off-by: Stephen Hemminger <shemminger@vyatta•com>
---
drivers/net/wan/dlci.c | 43 +++++--------------------------------------
drivers/net/wan/sdla.c | 8 ++++----
include/linux/if_frad.h | 5 -----
3 files changed, 9 insertions(+), 47 deletions(-)
--- a/drivers/net/wan/dlci.c 2009-09-04 08:14:38.993377174 -0700
+++ b/drivers/net/wan/dlci.c 2009-09-04 08:25:03.024404089 -0700
@@ -186,46 +186,13 @@ static void dlci_receive(struct sk_buff
dev_kfree_skb(skb);
}
-static netdev_tx_t dlci_transmit(struct sk_buff *skb,
- struct net_device *dev)
+static netdev_tx_t dlci_transmit(struct sk_buff *skb, struct net_device *dev)
{
- struct dlci_local *dlp;
- netdev_tx_t ret;
-
- if (!skb || !dev)
- return NETDEV_TX_OK;
-
- dlp = netdev_priv(dev);
-
- netif_stop_queue(dev);
-
- /* This is hackish, overloads driver specific return values
- on top of normal transmit return! */
- ret = dlp->slave->netdev_ops->ndo_start_xmit(skb, dlp->slave);
- switch (ret)
- {
- case DLCI_RET_OK:
- dev->stats.tx_packets++;
- ret = NETDEV_TX_OK;
- break;
- case DLCI_RET_ERR:
- dev->stats.tx_errors++;
- ret = NETDEV_TX_OK;
- break;
- case DLCI_RET_DROP:
- dev->stats.tx_dropped++;
- ret = NETDEV_TX_BUSY;
- break;
- }
- /* Alan Cox recommends always returning 0, and always freeing the packet */
- /* experience suggest a slightly more conservative approach */
+ struct dlci_local *dlp = netdev_priv(dev);
- if (ret == NETDEV_TX_OK)
- {
- dev_kfree_skb(skb);
- netif_wake_queue(dev);
- }
- return(ret);
+ if (skb)
+ dlp->slave->netdev_ops->ndo_start_xmit(skb, dlp->slave);
+ return NETDEV_TX_OK;
}
static int dlci_config(struct net_device *dev, struct dlci_conf __user *conf, int get)
--- a/drivers/net/wan/sdla.c 2009-09-04 08:18:22.917065991 -0700
+++ b/drivers/net/wan/sdla.c 2009-09-04 08:24:53.587189004 -0700
@@ -652,7 +652,7 @@ static int sdla_dlci_conf(struct net_dev
/* NOTE: the DLCI driver deals with freeing the SKB!! */
static netdev_tx_t sdla_transmit(struct sk_buff *skb,
- struct net_device *dev)
+ struct net_device *dev)
{
struct frad_local *flp;
int ret, addr, accept, i;
@@ -712,23 +712,21 @@ static netdev_tx_t sdla_transmit(struct
}
break;
}
+
switch (ret)
{
case SDLA_RET_OK:
dev->stats.tx_packets++;
- ret = DLCI_RET_OK;
break;
case SDLA_RET_CIR_OVERFLOW:
case SDLA_RET_BUF_OVERSIZE:
case SDLA_RET_NO_BUFS:
dev->stats.tx_dropped++;
- ret = DLCI_RET_DROP;
break;
default:
dev->stats.tx_errors++;
- ret = DLCI_RET_ERR;
break;
}
}
@@ -738,6 +736,8 @@ static netdev_tx_t sdla_transmit(struct
if(flp->master[i]!=NULL)
netif_wake_queue(flp->master[i]);
}
+
+ dev_kfree_skb(skb);
return NETDEV_TX_OK;
}
--- a/include/linux/if_frad.h 2009-09-04 08:19:04.459045748 -0700
+++ b/include/linux/if_frad.h 2009-09-04 08:19:47.487006328 -0700
@@ -69,11 +69,6 @@ struct dlci_conf {
#define DLCI_VALID_FLAGS 0x000B
-/* FRAD driver uses these to indicate what it did with packet */
-#define DLCI_RET_OK 0x00
-#define DLCI_RET_ERR 0x01
-#define DLCI_RET_DROP 0x02
-
/* defines for the actual Frame Relay hardware */
#define FRAD_GET_CONF (SIOCDEVPRIVATE)
#define FRAD_SET_CONF (SIOCDEVPRIVATE + 1)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH net-next] wan: dlci/sdla transmit return dehacking
2009-09-04 15:33 ` [PATCH net-next] wan: dlci/sdla transmit return dehacking Stephen Hemminger
@ 2009-09-04 18:48 ` Krzysztof Halasa
2009-09-05 2:38 ` Stephen Hemminger
2009-09-07 8:57 ` David Miller
1 sibling, 1 reply; 27+ messages in thread
From: Krzysztof Halasa @ 2009-09-04 18:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, sfr, linux-next, netdev
Stephen Hemminger <shemminger@vyatta•com> writes:
> This is a brute force removal of the wierd slave interface done for
> DLCI -> SDLA transmit. Before it was using non-standard return values
> and freeing skb in caller. This changes it to using normal return
> values, and freeing in the callee. Luckly only one driver pair was
> doing this. Not tested on real hardware, in fact I wonder if this
> driver pair is even being used by any users.
The only hardware which seems to be driven by dlci.c is sdla.c =
old Sangoma ISA cards.
Sangoma seems to maintain their own drivers for their hw (including
these ISA cards).
Are the in-kernel drivers functional after all those years? I don't
know.
--
Krzysztof Halasa
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH net-next] wan: dlci/sdla transmit return dehacking
2009-09-04 18:48 ` Krzysztof Halasa
@ 2009-09-05 2:38 ` Stephen Hemminger
2009-09-05 11:09 ` Krzysztof Halasa
0 siblings, 1 reply; 27+ messages in thread
From: Stephen Hemminger @ 2009-09-05 2:38 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: David Miller, sfr, linux-next, netdev
On Fri, 04 Sep 2009 20:48:50 +0200
Krzysztof Halasa <khc@pm•waw.pl> wrote:
> Stephen Hemminger <shemminger@vyatta•com> writes:
>
> > This is a brute force removal of the wierd slave interface done for
> > DLCI -> SDLA transmit. Before it was using non-standard return values
> > and freeing skb in caller. This changes it to using normal return
> > values, and freeing in the callee. Luckly only one driver pair was
> > doing this. Not tested on real hardware, in fact I wonder if this
> > driver pair is even being used by any users.
>
> The only hardware which seems to be driven by dlci.c is sdla.c =
> old Sangoma ISA cards.
>
> Sangoma seems to maintain their own drivers for their hw (including
> these ISA cards).
>
> Are the in-kernel drivers functional after all those years? I don't
> know.
In the Vyatta product we use the Sangoma drivers, so we actually have
to make and not configure in the existing WAN drivers.
--
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH net-next] wan: dlci/sdla transmit return dehacking
2009-09-05 2:38 ` Stephen Hemminger
@ 2009-09-05 11:09 ` Krzysztof Halasa
0 siblings, 0 replies; 27+ messages in thread
From: Krzysztof Halasa @ 2009-09-05 11:09 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, sfr, linux-next, netdev
Stephen Hemminger <shemminger@vyatta•com> writes:
> In the Vyatta product we use the Sangoma drivers, so we actually have
> to make and not configure in the existing WAN drivers.
I'd expect all users of their hw are doing precisely the same (not to
imply there are any S5* (ISA) cards still in use).
But I don't know for sure, sometimes people use really old and long
unmaintained drivers with success. OTOH ISA...
--
Krzysztof Halasa
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH net-next] wan: dlci/sdla transmit return dehacking
2009-09-04 15:33 ` [PATCH net-next] wan: dlci/sdla transmit return dehacking Stephen Hemminger
2009-09-04 18:48 ` Krzysztof Halasa
@ 2009-09-07 8:57 ` David Miller
1 sibling, 0 replies; 27+ messages in thread
From: David Miller @ 2009-09-07 8:57 UTC (permalink / raw)
To: shemminger; +Cc: khc, sfr, linux-next, netdev
From: Stephen Hemminger <shemminger@vyatta•com>
Date: Fri, 4 Sep 2009 08:33:46 -0700
> This is a brute force removal of the wierd slave interface done for DLCI -> SDLA
> transmit. Before it was using non-standard return values and freeing skb in caller.
> This changes it to using normal return values, and freeing in the callee.
> Luckly only one driver pair was doing this. Not tested on real hardware,
> in fact I wonder if this driver pair is even being used by any users.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta•com>
Irregardless of what we should do with the SDLA driver, this patch
should go in while that code is still in the tree.
Applied to net-next-2.6, thanks.
^ permalink raw reply [flat|nested] 27+ messages in thread
* linux-next: net tree build warnings
@ 2009-10-14 4:20 Stephen Rothwell
2009-10-14 4:34 ` Stephen Rothwell
0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2009-10-14 4:20 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-next, linux-kernel, Arnaldo Carvalho de Melo
[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]
Hi Dave,
Today's linux-next build (powerpc ppc44x_defconfig) produced these
warnings:
In file included from net/socket.c:94:
include/net/compat.h:45: warning: 'struct compat_mmsghdr' declared inside parameter list
include/net/compat.h:45: warning: its scope is only this definition or declaration, which is probably not what you want
In file included from net/core/scm.c:36:
include/net/compat.h:45: warning: 'struct compat_mmsghdr' declared inside parameter list
include/net/compat.h:45: warning: its scope is only this definition or declaration, which is probably not what you want
In file included from net/ipv4/ip_sockglue.c:37:
include/net/compat.h:45: warning: 'struct compat_mmsghdr' declared inside parameter list
include/net/compat.h:45: warning: its scope is only this definition or declaration, which is probably not what you want
In file included from net/ipv6/ipv6_sockglue.c:53:
include/net/compat.h:45: warning: 'struct compat_mmsghdr' declared inside parameter list
include/net/compat.h:45: warning: its scope is only this definition or declaration, which is probably not what you want
CONFIG_COMPAT is not set.
Caused by commit a2e2725541fad72416326798c2d7fa4dafb7d337 ("net:
Introduce recvmmsg socket syscall").
--
Cheers,
Stephen Rothwell sfr@canb•auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: net tree build warnings
2009-10-14 4:20 linux-next: net tree build warnings Stephen Rothwell
@ 2009-10-14 4:34 ` Stephen Rothwell
2009-10-14 22:11 ` David Miller
0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2009-10-14 4:34 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-next, linux-kernel, Arnaldo Carvalho de Melo
[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]
Hi Dave,
On Wed, 14 Oct 2009 15:20:00 +1100 Stephen Rothwell <sfr@canb•auug.org.au> wrote:
>
> Today's linux-next build (powerpc ppc44x_defconfig) produced these
> warnings:
>
> In file included from net/socket.c:94:
> include/net/compat.h:45: warning: 'struct compat_mmsghdr' declared inside parameter list
> include/net/compat.h:45: warning: its scope is only this definition or declaration, which is probably not what you want
> In file included from net/core/scm.c:36:
> include/net/compat.h:45: warning: 'struct compat_mmsghdr' declared inside parameter list
> include/net/compat.h:45: warning: its scope is only this definition or declaration, which is probably not what you want
> In file included from net/ipv4/ip_sockglue.c:37:
> include/net/compat.h:45: warning: 'struct compat_mmsghdr' declared inside parameter list
> include/net/compat.h:45: warning: its scope is only this definition or declaration, which is probably not what you want
> In file included from net/ipv6/ipv6_sockglue.c:53:
> include/net/compat.h:45: warning: 'struct compat_mmsghdr' declared inside parameter list
> include/net/compat.h:45: warning: its scope is only this definition or declaration, which is probably not what you want
>
> CONFIG_COMPAT is not set.
>
> Caused by commit a2e2725541fad72416326798c2d7fa4dafb7d337 ("net:
> Introduce recvmmsg socket syscall").
I also get these for i386 and sparc32 defconfig builds.
--
Cheers,
Stephen Rothwell sfr@canb•auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: net tree build warnings
2009-10-14 4:34 ` Stephen Rothwell
@ 2009-10-14 22:11 ` David Miller
2009-10-15 1:55 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 27+ messages in thread
From: David Miller @ 2009-10-14 22:11 UTC (permalink / raw)
To: sfr; +Cc: linux-next, linux-kernel, acme
From: Stephen Rothwell <sfr@canb•auug.org.au>
Date: Wed, 14 Oct 2009 15:34:50 +1100
> On Wed, 14 Oct 2009 15:20:00 +1100 Stephen Rothwell <sfr@canb•auug.org.au> wrote:
>>
>> Today's linux-next build (powerpc ppc44x_defconfig) produced these
>> warnings:
>>
>> In file included from net/socket.c:94:
>> include/net/compat.h:45: warning: 'struct compat_mmsghdr' declared inside parameter list
>>
>> CONFIG_COMPAT is not set.
>>
>> Caused by commit a2e2725541fad72416326798c2d7fa4dafb7d337 ("net:
>> Introduce recvmmsg socket syscall").
...
>
> I also get these for i386 and sparc32 defconfig builds.
I've asked Arnaldo to work on fixing this.
Thanks!
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: net tree build warnings
2009-10-14 22:11 ` David Miller
@ 2009-10-15 1:55 ` Arnaldo Carvalho de Melo
0 siblings, 0 replies; 27+ messages in thread
From: Arnaldo Carvalho de Melo @ 2009-10-15 1:55 UTC (permalink / raw)
To: David Miller; +Cc: sfr, linux-next, linux-kernel
Em Wed, Oct 14, 2009 at 03:11:37PM -0700, David Miller escreveu:
> From: Stephen Rothwell <sfr@canb•auug.org.au>
> Date: Wed, 14 Oct 2009 15:34:50 +1100
>
> > On Wed, 14 Oct 2009 15:20:00 +1100 Stephen Rothwell <sfr@canb•auug.org.au> wrote:
> >>
> >> Today's linux-next build (powerpc ppc44x_defconfig) produced these
> >> warnings:
> >>
> >> In file included from net/socket.c:94:
> >> include/net/compat.h:45: warning: 'struct compat_mmsghdr' declared inside parameter list
> >>
> >> CONFIG_COMPAT is not set.
> >>
> >> Caused by commit a2e2725541fad72416326798c2d7fa4dafb7d337 ("net:
> >> Introduce recvmmsg socket syscall").
> ...
> >
> > I also get these for i386 and sparc32 defconfig builds.
>
> I've asked Arnaldo to work on fixing this.
I'll fix that early tomorrow.
- Arnaldo
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2009-10-15 1:55 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-09-04 4:34 linux-next: net tree build warnings Stephen Rothwell
2009-09-04 4:35 ` David Miller
2009-09-04 15:33 ` [PATCH net-next] wan: dlci/sdla transmit return dehacking Stephen Hemminger
2009-09-04 18:48 ` Krzysztof Halasa
2009-09-05 2:38 ` Stephen Hemminger
2009-09-05 11:09 ` Krzysztof Halasa
2009-09-07 8:57 ` David Miller
-- strict thread matches above, loose matches on Subject: below --
2009-10-14 4:20 linux-next: net tree build warnings Stephen Rothwell
2009-10-14 4:34 ` Stephen Rothwell
2009-10-14 22:11 ` David Miller
2009-10-15 1:55 ` Arnaldo Carvalho de Melo
2009-06-11 4:55 Stephen Rothwell
2009-06-11 6:47 ` David Miller
2009-06-11 7:20 ` Stephen Rothwell
2009-04-29 4:59 Stephen Rothwell
2009-04-29 6:02 ` David Miller
2009-04-30 0:54 ` David Miller
2009-04-30 7:06 ` Stephen Rothwell
2009-03-26 6:37 Stephen Rothwell
2009-03-26 7:50 ` Eric Leblond
2009-03-26 13:17 ` Patrick McHardy
2009-03-26 22:01 ` Stephen Rothwell
2009-03-16 6:03 Stephen Rothwell
2009-03-16 6:05 ` Dhananjay Phadke
2008-12-17 7:22 Stephen Rothwell
2008-12-17 7:53 ` David Miller
2008-12-17 8:04 ` Eilon Greenstein
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox