* Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
From: Wolfgang Grandegger @ 2011-08-08 15:50 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
U Bhaskar-B22300, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110808153835.GC4926-sJ/iWh9BUns@public.gmane.org>
On 08/08/2011 05:38 PM, Robin Holt wrote:
> On Mon, Aug 08, 2011 at 05:22:41PM +0200, Wolfgang Grandegger wrote:
>> On 08/08/2011 05:18 PM, Wolfgang Grandegger wrote:
>>> On 08/08/2011 05:09 PM, Robin Holt wrote:
>>>> On Mon, Aug 08, 2011 at 04:59:54PM +0200, Wolfgang Grandegger wrote:
>>>>> On 08/08/2011 04:44 PM, Robin Holt wrote:
>>>>>> On Mon, Aug 08, 2011 at 04:37:44PM +0200, Wolfgang Grandegger wrote:
>>>>>>> On 08/08/2011 04:21 PM, Robin Holt wrote:
>>>>>>>> On Mon, Aug 08, 2011 at 04:16:27PM +0200, Wolfgang Grandegger wrote:
>>>>>>>>> On 08/08/2011 03:56 PM, Robin Holt wrote:
>>>>>>>>>>> commit 65bb8b060a873fa4f5188f2951081f6011259614
>>>>>>>>>>> Author: Bhaskar Upadhaya <Bhaskar.Upadhaya-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>>>>>>>>>>> Date: Fri Mar 4 20:27:58 2011 +0530
>>>>>>>>>>
>>>>>>>>>> On a side note, that commit fixes up "fsl,flexcan-v1.0"
>>>>>>>>>> ...
>>>>>>>>>> + do_fixup_by_compat_u32(blob, "fsl,flexcan-v1.0",
>>>>>>>>>> + "clock_freq", gd->bus_clk, 1);
>>>>>>>>>>
>>>>>>>>>> Should I go back to flexcan-v1.0 in my patches?
>>>>>>>>>
>>>>>>>>> Well, no. Let's wait. I don't think we need it. Also, it sets
>>>>>>>>> "clock_freq" while
>>>>>>>>>
>>>>>>>>> http://lxr.linux.no/#linux+v3.0.1/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
>>>>>>>>>
>>>>>>>>> documents "clock-frequencies"... :-(.
>>>>>>>>
>>>>>>>> You answered a different question that I was asking. I was asking if
>>>>>>>> I should change fsl,flexcan back to fsl,flexcan-v1.0 as documented on
>>>>>>>> line 5. The clock_freq looks like a uboot change will need to be made
>>>>>>>> as well.
>>>>>>>
>>>>>>> Well, I wrote above: "Well, no. Let's wait. I don't think we need it."
>>>>>>>
>>>>>>> For the P1010 we can sinmply derive the clock frequency from
>>>>>>> "fsl_get_sys_freq()", which is fine for the time being. No extra
>>>>>>> properties, etc. The clk implemetation might go into
>>>>>>>
>>>>>>> http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/platforms/85xx/clock.c
>>>>>>>
>>>>>>> or
>>>>>>>
>>>>>>> http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/sysdev/fsl_soc.c
>>>>>>>
>>>>>>> And may depend on HAVE_CAN_FLEXCAN
>>>>>>>
>>>>>>> BTW, I have not found HAVE_CAN_FLEXCAN in your patch. What kernel are
>>>>>>> you using?
>>>>>>
>>>>>> I am starting with the v3.0 kernel, apply one patch from the freescale BSP
>>>>>> we receive under NDA which introduces the P1010RDB board into the QorIQ
>>>>>> platform, and then work from there for the flexcan stuff. That patch
>>>>>> introduces the HAVE_CAN_FLEXCAN. I do not like how freescale structured
>>>>>> that Kconfig bit, so I have tweaked it to be selected automatically
>>>>>> when P1010RDB, NET, and CAN are selected. That allows the CAN_FLEXCAN
>>>>>> selection to determine is we are going to build the flexcan.c file.
>>>>>
>>>>> ARM boards select HAVE_CAN_FLEXCAN and I do not see a good reason why
>>>>> we should do it differently for PowerPC.
>>>>>
>>>>> For mainline inclusion, you should provide your patches against the
>>>>> David Millers "net-next-2.6" tree, which already seems to have support
>>>>> for the P1010RDB:
>>>>>
>>>>> config P1010_RDB
>>>>> bool "Freescale P1010RDB"
>>>>> select DEFAULT_UIMAGE
>>>>> help
>>>>> This option enables support for the MPC85xx RDB (P1010 RDB) board
>>>>>
>>>>> P1010RDB contains P1010Si, which provides CPU performance up to 800
>>>>> MHz and 1600 DMIPS, additional functionality and faster interfaces
>>>>> (DDR3/3L, SATA II, and PCI Express).
>>>>>
>>>>>
>>>>>> Our contact with Freescale would prefer that I not post that patch until
>>>>>> we get the OK from freescale to do so since we received it under NDA.
>>>>>
>>>>> I don't think we currently need it. I prefer dropping and cleaning up
>>>>> the device tree stuff as it is not needed for the P1010 anyway. If a
>>>>> new processor shows up with enhanced capabilities requiring
>>>>> configuration via device tree, we or somebody else can provide a patch.
>>>>> Marc, what do you think?
>>>>
>>>> I will rebase shortly and provide a newer set of patches.
>>>>
>>>> I do think powerpc does need the device tree support. That is how the flexcan_probe
>>>> is getting called. How would you suggest I do it otherwise?
>>>
>>> Why do you think that?
>>
>> To be clear. I mean we do not need the extra "fsl," properties for the
>> clock source and divider and frequency.
>
> I agree with that. The can definition in the .dts file, however,
> should be can0@... "fsl,flexcan" in an ideal world, correct? If that
No, it's normally <device-type>@<address>.
> is correct, then I will make the of_match string match fsl,flexcan and
> update the .dts file accordingly.
As I said. For the P1010 the clock get function just needs to return
"fsl_get_sys_freq()". No need to inspect the device tree. And I would
provide the clk implementation in
http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/platforms/85xx/clock.c
or even:
http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/sysdev/fsl_soc.c
Wolfgang.
^ permalink raw reply
* [PATCH net-next 0/2] bnx2x: Logging message cleanups
From: Joe Perches @ 2011-08-08 15:53 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
Joe Perches (2):
bnx2x: Remove local defines for %pM and mac address
bnx2x: Coalesce pr_cont uses and fix DP typos
drivers/net/bnx2x/bnx2x.h | 4 -
drivers/net/bnx2x/bnx2x_cmn.c | 42 ++++++-----
drivers/net/bnx2x/bnx2x_cmn.h | 4 +-
drivers/net/bnx2x/bnx2x_dcb.c | 2 +-
drivers/net/bnx2x/bnx2x_link.c | 155 +++++++++++++++++++++-------------------
drivers/net/bnx2x/bnx2x_main.c | 47 ++++++-------
drivers/net/bnx2x/bnx2x_sp.c | 64 ++++++++---------
7 files changed, 158 insertions(+), 160 deletions(-)
--
1.7.6.405.gc1be0
^ permalink raw reply
* [PATCH net-next 1/2] bnx2x: Remove local defines for %pM and mac address
From: Joe Perches @ 2011-08-08 15:53 UTC (permalink / raw)
To: Eilon Greenstein; +Cc: netdev, linux-kernel
In-Reply-To: <cover.1312818707.git.joe@perches.com>
Use %pM and mac address directly instead.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/bnx2x/bnx2x.h | 4 ---
drivers/net/bnx2x/bnx2x_main.c | 14 +++++-------
drivers/net/bnx2x/bnx2x_sp.c | 41 ++++++++++++++++-----------------------
3 files changed, 23 insertions(+), 36 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index c423504..5aac959 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -115,10 +115,6 @@ do { \
dev_info(&bp->pdev->dev, __fmt, ##__args); \
} while (0)
-#define BNX2X_MAC_FMT "%pM"
-#define BNX2X_MAC_PRN_LIST(mac) (mac)
-
-
#ifdef BNX2X_STOP_ON_ERROR
void bnx2x_int_disable(struct bnx2x *bp);
#define bnx2x_panic() do { \
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index 1507091..173b258 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -9315,9 +9315,8 @@ static void __devinit bnx2x_get_mac_hwinfo(struct bnx2x *bp)
val = MF_CFG_RD(bp, func_ext_config[func].
iscsi_mac_addr_lower);
bnx2x_set_mac_buf(iscsi_mac, val, val2);
- BNX2X_DEV_INFO("Read iSCSI MAC: "
- BNX2X_MAC_FMT"\n",
- BNX2X_MAC_PRN_LIST(iscsi_mac));
+ BNX2X_DEV_INFO("Read iSCSI MAC: %pM\n",
+ iscsi_mac);
} else
bp->flags |= NO_ISCSI_OOO_FLAG | NO_ISCSI_FLAG;
@@ -9327,9 +9326,8 @@ static void __devinit bnx2x_get_mac_hwinfo(struct bnx2x *bp)
val = MF_CFG_RD(bp, func_ext_config[func].
fcoe_mac_addr_lower);
bnx2x_set_mac_buf(fip_mac, val, val2);
- BNX2X_DEV_INFO("Read FCoE L2 MAC to "
- BNX2X_MAC_FMT"\n",
- BNX2X_MAC_PRN_LIST(fip_mac));
+ BNX2X_DEV_INFO("Read FCoE L2 MAC to %pM\n",
+ fip_mac);
} else
bp->flags |= NO_FCOE_FLAG;
@@ -9384,9 +9382,9 @@ static void __devinit bnx2x_get_mac_hwinfo(struct bnx2x *bp)
if (!is_valid_ether_addr(bp->dev->dev_addr))
dev_err(&bp->pdev->dev,
"bad Ethernet MAC address configuration: "
- BNX2X_MAC_FMT", change it manually before bringing up "
+ "%pM, change it manually before bringing up "
"the appropriate network interface\n",
- BNX2X_MAC_PRN_LIST(bp->dev->dev_addr));
+ bp->dev->dev_addr);
}
static int __devinit bnx2x_get_hwinfo(struct bnx2x *bp)
diff --git a/drivers/net/bnx2x/bnx2x_sp.c b/drivers/net/bnx2x/bnx2x_sp.c
index df52f11..b4d9c16 100644
--- a/drivers/net/bnx2x/bnx2x_sp.c
+++ b/drivers/net/bnx2x/bnx2x_sp.c
@@ -707,9 +707,8 @@ static void bnx2x_set_one_mac_e2(struct bnx2x *bp,
bnx2x_vlan_mac_set_cmd_hdr_e2(bp, o, add, CLASSIFY_RULE_OPCODE_MAC,
&rule_entry->mac.header);
- DP(BNX2X_MSG_SP, "About to %s MAC "BNX2X_MAC_FMT" for "
- "Queue %d\n", (add ? "add" : "delete"),
- BNX2X_MAC_PRN_LIST(mac), raw->cl_id);
+ DP(BNX2X_MSG_SP, "About to %s MAC %pM for Queue %d\n",
+ add ? "add" : "delete", mac, raw->cl_id);
/* Set a MAC itself */
bnx2x_set_fw_mac_addr(&rule_entry->mac.mac_msb,
@@ -801,9 +800,9 @@ static inline void bnx2x_vlan_mac_set_rdata_e1x(struct bnx2x *bp,
bnx2x_vlan_mac_set_cfg_entry_e1x(bp, o, add, opcode, mac, vlan_id,
cfg_entry);
- DP(BNX2X_MSG_SP, "%s MAC "BNX2X_MAC_FMT" CLID %d CAM offset %d\n",
- (add ? "setting" : "clearing"),
- BNX2X_MAC_PRN_LIST(mac), raw->cl_id, cam_offset);
+ DP(BNX2X_MSG_SP, "%s MAC %pM CLID %d CAM offset %d\n",
+ add ? "setting" : "clearing",
+ mac, raw->cl_id, cam_offset);
}
/**
@@ -2579,9 +2578,8 @@ static inline void bnx2x_mcast_hdl_pending_add_e2(struct bnx2x *bp,
cnt++;
- DP(BNX2X_MSG_SP, "About to configure "BNX2X_MAC_FMT
- " mcast MAC\n",
- BNX2X_MAC_PRN_LIST(pmac_pos->mac));
+ DP(BNX2X_MSG_SP, "About to configure %pM mcast MAC\n",
+ pmac_pos->mac);
list_del(&pmac_pos->link);
@@ -2702,9 +2700,8 @@ static inline void bnx2x_mcast_hdl_add(struct bnx2x *bp,
cnt++;
- DP(BNX2X_MSG_SP, "About to configure "BNX2X_MAC_FMT
- " mcast MAC\n",
- BNX2X_MAC_PRN_LIST(mlist_pos->mac));
+ DP(BNX2X_MSG_SP, "About to configure %pM mcast MAC\n",
+ mlist_pos->mac);
}
*line_idx = cnt;
@@ -2998,9 +2995,8 @@ static inline void bnx2x_mcast_hdl_add_e1h(struct bnx2x *bp,
bit = bnx2x_mcast_bin_from_mac(mlist_pos->mac);
BNX2X_57711_SET_MC_FILTER(mc_filter, bit);
- DP(BNX2X_MSG_SP, "About to configure "
- BNX2X_MAC_FMT" mcast MAC, bin %d\n",
- BNX2X_MAC_PRN_LIST(mlist_pos->mac), bit);
+ DP(BNX2X_MSG_SP, "About to configure %pM mcast MAC, bin %d\n",
+ mlist_pos->mac, bit);
/* bookkeeping... */
BIT_VEC64_SET_BIT(o->registry.aprox_match.vec,
@@ -3233,9 +3229,8 @@ static inline int bnx2x_mcast_handle_restore_cmd_e1(
i++;
- DP(BNX2X_MSG_SP, "About to configure "BNX2X_MAC_FMT
- " mcast MAC\n",
- BNX2X_MAC_PRN_LIST(cfg_data.mac));
+ DP(BNX2X_MSG_SP, "About to configure %pM mcast MAC\n",
+ cfg_data.mac);
}
*rdata_idx = i;
@@ -3270,9 +3265,8 @@ static inline int bnx2x_mcast_handle_pending_cmds_e1(
cnt++;
- DP(BNX2X_MSG_SP, "About to configure "BNX2X_MAC_FMT
- " mcast MAC\n",
- BNX2X_MAC_PRN_LIST(pmac_pos->mac));
+ DP(BNX2X_MSG_SP, "About to configure %pM mcast MAC\n",
+ pmac_pos->mac);
}
break;
@@ -3357,9 +3351,8 @@ static inline int bnx2x_mcast_refresh_registry_e1(struct bnx2x *bp,
&data->config_table[i].middle_mac_addr,
&data->config_table[i].lsb_mac_addr,
elem->mac);
- DP(BNX2X_MSG_SP, "Adding registry entry for ["
- BNX2X_MAC_FMT"]\n",
- BNX2X_MAC_PRN_LIST(elem->mac));
+ DP(BNX2X_MSG_SP, "Adding registry entry for [%pM]\n",
+ elem->mac);
list_add_tail(&elem->link,
&o->registry.exact_match.macs);
}
--
1.7.6.405.gc1be0
^ permalink raw reply related
* [PATCH net-next 2/2] bnx2x: Coalesce pr_cont uses and fix DP typos
From: Joe Perches @ 2011-08-08 15:53 UTC (permalink / raw)
To: Eilon Greenstein; +Cc: netdev, linux-kernel
In-Reply-To: <cover.1312818707.git.joe@perches.com>
Uses of pr_cont should be avoided where reasonably possible
because they can be interleaved by other threads and processes.
Coalesce pr_cont uses.
Fix typos, duplicated words and spacing in DP uses caused
by split multi-line formats. Coalesce some of these
split formats. Add missing terminating newlines to DP uses.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/bnx2x/bnx2x_cmn.c | 42 ++++++-----
drivers/net/bnx2x/bnx2x_cmn.h | 4 +-
drivers/net/bnx2x/bnx2x_dcb.c | 2 +-
drivers/net/bnx2x/bnx2x_link.c | 155 +++++++++++++++++++++-------------------
drivers/net/bnx2x/bnx2x_main.c | 33 ++++-----
drivers/net/bnx2x/bnx2x_sp.c | 23 +++---
6 files changed, 135 insertions(+), 124 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_cmn.c b/drivers/net/bnx2x/bnx2x_cmn.c
index 5b0dba6..456baf6 100644
--- a/drivers/net/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/bnx2x/bnx2x_cmn.c
@@ -953,15 +953,16 @@ void __bnx2x_link_report(struct bnx2x *bp)
netdev_err(bp->dev, "NIC Link is Down\n");
return;
} else {
+ const char *duplex;
+ const char *flow;
+
netif_carrier_on(bp->dev);
- netdev_info(bp->dev, "NIC Link is Up, ");
- pr_cont("%d Mbps ", cur_data.line_speed);
if (test_and_clear_bit(BNX2X_LINK_REPORT_FD,
&cur_data.link_report_flags))
- pr_cont("full duplex");
+ duplex = "full";
else
- pr_cont("half duplex");
+ duplex = "half";
/* Handle the FC at the end so that only these flags would be
* possibly set. This way we may easily check if there is no FC
@@ -970,16 +971,19 @@ void __bnx2x_link_report(struct bnx2x *bp)
if (cur_data.link_report_flags) {
if (test_bit(BNX2X_LINK_REPORT_RX_FC_ON,
&cur_data.link_report_flags)) {
- pr_cont(", receive ");
if (test_bit(BNX2X_LINK_REPORT_TX_FC_ON,
&cur_data.link_report_flags))
- pr_cont("& transmit ");
+ flow = "ON - receive & transmit";
+ else
+ flow = "ON - receive";
} else {
- pr_cont(", transmit ");
+ flow = "ON - transmit";
}
- pr_cont("flow control ON");
+ } else {
+ flow = "none";
}
- pr_cont("\n");
+ netdev_info(bp->dev, "NIC Link is Up, %d Mbps %s duplex, Flow control: %s\n",
+ cur_data.line_speed, duplex, flow);
}
}
@@ -2578,7 +2582,7 @@ netdev_tx_t bnx2x_start_xmit(struct sk_buff *skb, struct net_device *dev)
#endif
/* enable this debug print to view the transmission queue being used
- DP(BNX2X_MSG_FP, "indices: txq %d, fp %d, txdata %d",
+ DP(BNX2X_MSG_FP, "indices: txq %d, fp %d, txdata %d\n",
txq_index, fp_index, txdata_index); */
/* locate the fastpath and the txdata */
@@ -2587,7 +2591,7 @@ netdev_tx_t bnx2x_start_xmit(struct sk_buff *skb, struct net_device *dev)
/* enable this debug print to view the tranmission details
DP(BNX2X_MSG_FP,"transmitting packet cid %d fp index %d txdata_index %d"
- " tx_data ptr %p fp pointer %p",
+ " tx_data ptr %p fp pointer %p\n",
txdata->cid, fp_index, txdata_index, txdata, fp); */
if (unlikely(bnx2x_tx_avail(bp, txdata) <
@@ -2904,14 +2908,14 @@ int bnx2x_setup_tc(struct net_device *dev, u8 num_tc)
/* requested to support too many traffic classes */
if (num_tc > bp->max_cos) {
DP(NETIF_MSG_TX_ERR, "support for too many traffic classes"
- " requested: %d. max supported is %d",
+ " requested: %d. max supported is %d\n",
num_tc, bp->max_cos);
return -EINVAL;
}
/* declare amount of supported traffic classes */
if (netdev_set_num_tc(dev, num_tc)) {
- DP(NETIF_MSG_TX_ERR, "failed to declare %d traffic classes",
+ DP(NETIF_MSG_TX_ERR, "failed to declare %d traffic classes\n",
num_tc);
return -EINVAL;
}
@@ -2919,7 +2923,7 @@ int bnx2x_setup_tc(struct net_device *dev, u8 num_tc)
/* configure priority to traffic class mapping */
for (prio = 0; prio < BNX2X_MAX_PRIORITY; prio++) {
netdev_set_prio_tc_map(dev, prio, bp->prio_to_cos[prio]);
- DP(BNX2X_MSG_SP, "mapping priority %d to tc %d",
+ DP(BNX2X_MSG_SP, "mapping priority %d to tc %d\n",
prio, bp->prio_to_cos[prio]);
}
@@ -2928,10 +2932,10 @@ int bnx2x_setup_tc(struct net_device *dev, u8 num_tc)
This can be used for ets or pfc, and save the effort of setting
up a multio class queue disc or negotiating DCBX with a switch
netdev_set_prio_tc_map(dev, 0, 0);
- DP(BNX2X_MSG_SP, "mapping priority %d to tc %d", 0, 0);
+ DP(BNX2X_MSG_SP, "mapping priority %d to tc %d\n", 0, 0);
for (prio = 1; prio < 16; prio++) {
netdev_set_prio_tc_map(dev, prio, 1);
- DP(BNX2X_MSG_SP, "mapping priority %d to tc %d", prio, 1);
+ DP(BNX2X_MSG_SP, "mapping priority %d to tc %d\n", prio, 1);
} */
/* configure traffic class to transmission queue mapping */
@@ -2939,7 +2943,7 @@ int bnx2x_setup_tc(struct net_device *dev, u8 num_tc)
count = BNX2X_NUM_ETH_QUEUES(bp);
offset = cos * MAX_TXQS_PER_COS;
netdev_set_tc_queue(dev, cos, count, offset);
- DP(BNX2X_MSG_SP, "mapping tc %d to offset %d count %d",
+ DP(BNX2X_MSG_SP, "mapping tc %d to offset %d count %d\n",
cos, offset, count);
}
@@ -3027,7 +3031,7 @@ static void bnx2x_free_fp_mem_at(struct bnx2x *bp, int fp_index)
struct bnx2x_fp_txdata *txdata = &fp->txdata[cos];
DP(BNX2X_MSG_SP,
- "freeing tx memory of fp %d cos %d cid %d",
+ "freeing tx memory of fp %d cos %d cid %d\n",
fp_index, cos, txdata->cid);
BNX2X_FREE(txdata->tx_buf_ring);
@@ -3109,7 +3113,7 @@ static int bnx2x_alloc_fp_mem_at(struct bnx2x *bp, int index)
struct bnx2x_fp_txdata *txdata = &fp->txdata[cos];
DP(BNX2X_MSG_SP, "allocating tx memory of "
- "fp %d cos %d",
+ "fp %d cos %d\n",
index, cos);
BNX2X_ALLOC(txdata->tx_buf_ring,
diff --git a/drivers/net/bnx2x/bnx2x_cmn.h b/drivers/net/bnx2x/bnx2x_cmn.h
index 223bfee..501a24b 100644
--- a/drivers/net/bnx2x/bnx2x_cmn.h
+++ b/drivers/net/bnx2x/bnx2x_cmn.h
@@ -1289,7 +1289,7 @@ static inline void bnx2x_init_txdata(struct bnx2x *bp,
txdata->txq_index = txq_index;
txdata->tx_cons_sb = tx_cons_sb;
- DP(BNX2X_MSG_SP, "created tx data cid %d, txq %d",
+ DP(BNX2X_MSG_SP, "created tx data cid %d, txq %d\n",
txdata->cid, txdata->txq_index);
}
@@ -1333,7 +1333,7 @@ static inline void bnx2x_init_fcoe_fp(struct bnx2x *bp)
bnx2x_init_txdata(bp, &bnx2x_fcoe(bp, txdata[0]),
fp->cid, FCOE_TXQ_IDX(bp), BNX2X_FCOE_L2_TX_INDEX);
- DP(BNX2X_MSG_SP, "created fcoe tx data (fp index %d)", fp->index);
+ DP(BNX2X_MSG_SP, "created fcoe tx data (fp index %d)\n", fp->index);
/* qZone id equals to FW (per path) client id */
bnx2x_fcoe(bp, cl_qzone_id) = bnx2x_fp_qzone_id(fp);
diff --git a/drivers/net/bnx2x/bnx2x_dcb.c b/drivers/net/bnx2x/bnx2x_dcb.c
index a4ea35f..38b5ca5 100644
--- a/drivers/net/bnx2x/bnx2x_dcb.c
+++ b/drivers/net/bnx2x/bnx2x_dcb.c
@@ -350,7 +350,7 @@ static void bnx2x_dcbx_map_nw(struct bnx2x *bp)
if (cos_params[i].pri_bitmask & nw_prio) {
/* extend the bitmask with unmapped */
DP(NETIF_MSG_LINK,
- "cos %d extended with 0x%08x", i, unmapped);
+ "cos %d extended with 0x%08x\n", i, unmapped);
cos_params[i].pri_bitmask |= unmapped;
break;
}
diff --git a/drivers/net/bnx2x/bnx2x_link.c b/drivers/net/bnx2x/bnx2x_link.c
index bcd8f00..5874f68 100644
--- a/drivers/net/bnx2x/bnx2x_link.c
+++ b/drivers/net/bnx2x/bnx2x_link.c
@@ -694,8 +694,8 @@ static int bnx2x_ets_e3b0_disabled(const struct link_params *params,
struct bnx2x *bp = params->bp;
if (!CHIP_IS_E3B0(bp)) {
- DP(NETIF_MSG_LINK, "bnx2x_ets_e3b0_disabled the chip isn't E3B0"
- "\n");
+ DP(NETIF_MSG_LINK,
+ "bnx2x_ets_e3b0_disabled the chip isn't E3B0\n");
return -EINVAL;
}
@@ -854,8 +854,8 @@ static int bnx2x_ets_e3b0_get_total_bw(
if (bnx2x_cos_state_bw == ets_params->cos[cos_idx].state) {
if (0 == ets_params->cos[cos_idx].params.bw_params.bw) {
- DP(NETIF_MSG_LINK, "bnx2x_ets_E3B0_config BW"
- "was set to 0\n");
+ DP(NETIF_MSG_LINK,
+ "bnx2x_ets_E3B0_config BW was set to 0\n");
return -EINVAL;
}
*total_bw +=
@@ -866,12 +866,12 @@ static int bnx2x_ets_e3b0_get_total_bw(
/*Check taotl BW is valid */
if ((100 != *total_bw) || (0 == *total_bw)) {
if (0 == *total_bw) {
- DP(NETIF_MSG_LINK, "bnx2x_ets_E3B0_config toatl BW"
- "shouldn't be 0\n");
+ DP(NETIF_MSG_LINK,
+ "bnx2x_ets_E3B0_config toatl BW shouldn't be 0\n");
return -EINVAL;
}
- DP(NETIF_MSG_LINK, "bnx2x_ets_E3B0_config toatl BW should be"
- "100\n");
+ DP(NETIF_MSG_LINK,
+ "bnx2x_ets_E3B0_config toatl BW should be 100\n");
/**
* We can handle a case whre the BW isn't 100 this can happen
* if the TC are joined.
@@ -908,13 +908,13 @@ static int bnx2x_ets_e3b0_sp_pri_to_cos_set(const struct link_params *params,
if (DCBX_INVALID_COS != sp_pri_to_cos[pri]) {
DP(NETIF_MSG_LINK, "bnx2x_ets_e3b0_sp_pri_to_cos_set invalid "
- "parameter There can't be two COS's with"
+ "parameter There can't be two COS's with "
"the same strict pri\n");
return -EINVAL;
}
if (pri > max_num_of_cos) {
- DP(NETIF_MSG_LINK, "bnx2x_ets_e3b0_sp_pri_to_cos_set invalid"
+ DP(NETIF_MSG_LINK, "bnx2x_ets_e3b0_sp_pri_to_cos_set invalid "
"parameter Illegal strict priority\n");
return -EINVAL;
}
@@ -1090,8 +1090,8 @@ int bnx2x_ets_e3b0_config(const struct link_params *params,
u8 cos_entry = 0;
if (!CHIP_IS_E3B0(bp)) {
- DP(NETIF_MSG_LINK, "bnx2x_ets_e3b0_disabled the chip isn't E3B0"
- "\n");
+ DP(NETIF_MSG_LINK,
+ "bnx2x_ets_e3b0_disabled the chip isn't E3B0\n");
return -EINVAL;
}
@@ -1108,8 +1108,8 @@ int bnx2x_ets_e3b0_config(const struct link_params *params,
bnx2x_status = bnx2x_ets_e3b0_get_total_bw(params, ets_params,
&total_bw);
if (0 != bnx2x_status) {
- DP(NETIF_MSG_LINK, "bnx2x_ets_E3B0_config get_total_bw failed "
- "\n");
+ DP(NETIF_MSG_LINK,
+ "bnx2x_ets_E3B0_config get_total_bw failed\n");
return -EINVAL;
}
@@ -1144,13 +1144,13 @@ int bnx2x_ets_e3b0_config(const struct link_params *params,
cos_entry);
} else {
- DP(NETIF_MSG_LINK, "bnx2x_ets_e3b0_config cos state not"
- " valid\n");
+ DP(NETIF_MSG_LINK,
+ "bnx2x_ets_e3b0_config cos state not valid\n");
return -EINVAL;
}
if (0 != bnx2x_status) {
- DP(NETIF_MSG_LINK, "bnx2x_ets_e3b0_config set cos bw "
- "failed\n");
+ DP(NETIF_MSG_LINK,
+ "bnx2x_ets_e3b0_config set cos bw failed\n");
return bnx2x_status;
}
}
@@ -1160,8 +1160,8 @@ int bnx2x_ets_e3b0_config(const struct link_params *params,
sp_pri_to_cos);
if (0 != bnx2x_status) {
- DP(NETIF_MSG_LINK, "bnx2x_ets_E3B0_config set_pri_cli_reg "
- "failed\n");
+ DP(NETIF_MSG_LINK,
+ "bnx2x_ets_E3B0_config set_pri_cli_reg failed\n");
return bnx2x_status;
}
@@ -1612,8 +1612,8 @@ static void bnx2x_xmac_init(struct bnx2x *bp, u32 max_speed)
if (is_port4mode && (REG_RD(bp, MISC_REG_RESET_REG_2) &
MISC_REGISTERS_RESET_REG_2_XMAC)) {
- DP(NETIF_MSG_LINK, "XMAC already out of reset"
- " in 4-port mode\n");
+ DP(NETIF_MSG_LINK,
+ "XMAC already out of reset in 4-port mode\n");
return;
}
@@ -1636,13 +1636,13 @@ static void bnx2x_xmac_init(struct bnx2x *bp, u32 max_speed)
/* Set the number of ports on the system side to 1 */
REG_WR(bp, MISC_REG_XMAC_CORE_PORT_MODE, 0);
if (max_speed == SPEED_10000) {
- DP(NETIF_MSG_LINK, "Init XMAC to 10G x 1"
- " port per path\n");
+ DP(NETIF_MSG_LINK,
+ "Init XMAC to 10G x 1 port per path\n");
/* Set the number of ports on the Warp Core to 10G */
REG_WR(bp, MISC_REG_XMAC_PHY_PORT_MODE, 3);
} else {
- DP(NETIF_MSG_LINK, "Init XMAC to 20G x 2 ports"
- " per path\n");
+ DP(NETIF_MSG_LINK,
+ "Init XMAC to 20G x 2 ports per path\n");
/* Set the number of ports on the Warp Core to 20G */
REG_WR(bp, MISC_REG_XMAC_PHY_PORT_MODE, 1);
}
@@ -3945,8 +3945,8 @@ static void bnx2x_warpcore_set_sgmii_speed(struct bnx2x_phy *phy,
val16 |= 0x0040;
break;
default:
- DP(NETIF_MSG_LINK, "Speed not supported: 0x%x"
- "\n", phy->req_line_speed);
+ DP(NETIF_MSG_LINK,
+ "Speed not supported: 0x%x\n", phy->req_line_speed);
return;
}
@@ -4078,9 +4078,9 @@ static int bnx2x_get_mod_abs_int_cfg(struct bnx2x *bp,
*/
if ((cfg_pin < PIN_CFG_GPIO0_P0) ||
(cfg_pin > PIN_CFG_GPIO3_P1)) {
- DP(NETIF_MSG_LINK, "ERROR: Invalid cfg pin %x for "
- "module detect indication\n",
- cfg_pin);
+ DP(NETIF_MSG_LINK,
+ "ERROR: Invalid cfg pin %x for module detect indication\n",
+ cfg_pin);
return -EINVAL;
}
@@ -4208,8 +4208,9 @@ static void bnx2x_warpcore_config_init(struct bnx2x_phy *phy,
break;
default:
- DP(NETIF_MSG_LINK, "Unsupported Serdes Net Interface "
- "0x%x\n", serdes_net_if);
+ DP(NETIF_MSG_LINK,
+ "Unsupported Serdes Net Interface 0x%x\n",
+ serdes_net_if);
return;
}
}
@@ -6098,8 +6099,8 @@ static int bnx2x_link_initialize(struct link_params *params,
if (phy_index == EXT_PHY2 &&
(bnx2x_phy_selection(params) ==
PORT_HW_CFG_PHY_SELECTION_FIRST_PHY)) {
- DP(NETIF_MSG_LINK, "Not initializing"
- " second phy\n");
+ DP(NETIF_MSG_LINK,
+ "Not initializing second phy\n");
continue;
}
params->phy[phy_index].config_init(
@@ -6416,8 +6417,8 @@ int bnx2x_link_update(struct link_params *params, struct link_vars *vars)
*/
if (active_external_phy == EXT_PHY1) {
if (params->phy[EXT_PHY2].phy_specific_func) {
- DP(NETIF_MSG_LINK, "Disabling TX on"
- " EXT_PHY2\n");
+ DP(NETIF_MSG_LINK,
+ "Disabling TX on EXT_PHY2\n");
params->phy[EXT_PHY2].phy_specific_func(
¶ms->phy[EXT_PHY2],
params, DISABLE_TX);
@@ -7310,8 +7311,8 @@ static int bnx2x_8726_read_sfp_module_eeprom(struct bnx2x_phy *phy,
u16 val = 0;
u16 i;
if (byte_cnt > 16) {
- DP(NETIF_MSG_LINK, "Reading from eeprom is"
- " is limited to 0xf\n");
+ DP(NETIF_MSG_LINK,
+ "Reading from eeprom is limited to 0xf\n");
return -EINVAL;
}
/* Set the read command byte count */
@@ -7382,8 +7383,8 @@ static int bnx2x_warpcore_read_sfp_module_eeprom(struct bnx2x_phy *phy,
" addr %d, cnt %d\n",
addr, byte_cnt);*/
if (byte_cnt > 16) {
- DP(NETIF_MSG_LINK, "Reading from eeprom is"
- " is limited to 16 bytes\n");
+ DP(NETIF_MSG_LINK,
+ "Reading from eeprom is limited to 16 bytes\n");
return -EINVAL;
}
@@ -7412,8 +7413,8 @@ static int bnx2x_8727_read_sfp_module_eeprom(struct bnx2x_phy *phy,
u16 val, i;
if (byte_cnt > 16) {
- DP(NETIF_MSG_LINK, "Reading from eeprom is"
- " is limited to 0xf\n");
+ DP(NETIF_MSG_LINK,
+ "Reading from eeprom is limited to 0xf\n");
return -EINVAL;
}
@@ -7560,13 +7561,14 @@ static int bnx2x_get_edc_mode(struct bnx2x_phy *phy,
check_limiting_mode = 1;
} else if (copper_module_type &
SFP_EEPROM_FC_TX_TECH_BITMASK_COPPER_PASSIVE) {
- DP(NETIF_MSG_LINK, "Passive Copper"
- " cable detected\n");
+ DP(NETIF_MSG_LINK,
+ "Passive Copper cable detected\n");
*edc_mode =
EDC_MODE_PASSIVE_DAC;
} else {
- DP(NETIF_MSG_LINK, "Unknown copper-cable-"
- "type 0x%x !!!\n", copper_module_type);
+ DP(NETIF_MSG_LINK,
+ "Unknown copper-cable-type 0x%x !!!\n",
+ copper_module_type);
return -EINVAL;
}
break;
@@ -7604,8 +7606,8 @@ static int bnx2x_get_edc_mode(struct bnx2x_phy *phy,
SFP_EEPROM_OPTIONS_ADDR,
SFP_EEPROM_OPTIONS_SIZE,
options) != 0) {
- DP(NETIF_MSG_LINK, "Failed to read Option"
- " field from module EEPROM\n");
+ DP(NETIF_MSG_LINK,
+ "Failed to read Option field from module EEPROM\n");
return -EINVAL;
}
if ((options[0] & SFP_EEPROM_OPTIONS_LINEAR_RX_OUT_MASK))
@@ -7646,15 +7648,15 @@ static int bnx2x_verify_sfp_module(struct bnx2x_phy *phy,
FEATURE_CONFIG_BC_SUPPORTS_OPT_MDL_VRFY) {
/* Use first phy request only in case of non-dual media*/
if (DUAL_MEDIA(params)) {
- DP(NETIF_MSG_LINK, "FW does not support OPT MDL "
- "verification\n");
+ DP(NETIF_MSG_LINK,
+ "FW does not support OPT MDL verification\n");
return -EINVAL;
}
cmd = DRV_MSG_CODE_VRFY_FIRST_PHY_OPT_MDL;
} else {
/* No support in OPT MDL detection */
- DP(NETIF_MSG_LINK, "FW does not support OPT MDL "
- "verification\n");
+ DP(NETIF_MSG_LINK,
+ "FW does not support OPT MDL verification\n");
return -EINVAL;
}
@@ -7705,8 +7707,9 @@ static int bnx2x_wait_for_sfp_module_initialized(struct bnx2x_phy *phy,
for (timeout = 0; timeout < 60; timeout++) {
if (bnx2x_read_sfp_module_eeprom(phy, params, 1, 1, &val)
== 0) {
- DP(NETIF_MSG_LINK, "SFP+ module initialization "
- "took %d ms\n", timeout * 5);
+ DP(NETIF_MSG_LINK,
+ "SFP+ module initialization took %d ms\n",
+ timeout * 5);
return 0;
}
msleep(5);
@@ -8478,8 +8481,8 @@ static int bnx2x_8726_config_init(struct bnx2x_phy *phy,
/* Set TX PreEmphasis if needed */
if ((params->feature_config_flags &
FEATURE_CONFIG_OVERRIDE_PREEMPHASIS_ENABLED)) {
- DP(NETIF_MSG_LINK, "Setting TX_CTRL1 0x%x,"
- "TX_CTRL2 0x%x\n",
+ DP(NETIF_MSG_LINK,
+ "Setting TX_CTRL1 0x%x, TX_CTRL2 0x%x\n",
phy->tx_preemphasis[0],
phy->tx_preemphasis[1]);
bnx2x_cl45_write(bp, phy,
@@ -8763,8 +8766,8 @@ static void bnx2x_8727_handle_mod_abs(struct bnx2x_phy *phy,
if (mod_abs & (1<<8)) {
/* Module is absent */
- DP(NETIF_MSG_LINK, "MOD_ABS indication "
- "show module is absent\n");
+ DP(NETIF_MSG_LINK,
+ "MOD_ABS indication show module is absent\n");
phy->media_type = ETH_PHY_NOT_PRESENT;
/*
* 1. Set mod_abs to detect next module
@@ -8791,8 +8794,8 @@ static void bnx2x_8727_handle_mod_abs(struct bnx2x_phy *phy,
} else {
/* Module is present */
- DP(NETIF_MSG_LINK, "MOD_ABS indication "
- "show module is present\n");
+ DP(NETIF_MSG_LINK,
+ "MOD_ABS indication show module is present\n");
/*
* First disable transmitter, and if the module is ok, the
* module_detection will enable it
@@ -8883,8 +8886,9 @@ static u8 bnx2x_8727_read_status(struct bnx2x_phy *phy,
if ((val1 & (1<<8)) == 0) {
if (!CHIP_IS_E1x(bp))
oc_port = BP_PATH(bp) + (params->port << 1);
- DP(NETIF_MSG_LINK, "8727 Power fault has been detected"
- " on port %d\n", oc_port);
+ DP(NETIF_MSG_LINK,
+ "8727 Power fault has been detected on port %d\n",
+ oc_port);
netdev_err(bp->dev, "Error: Power fault on Port %d has"
" been detected and the power to "
"that SFP+ module has been removed"
@@ -9660,8 +9664,8 @@ static u8 bnx2x_848xx_read_status(struct bnx2x_phy *phy,
MDIO_AN_REG_8481_EXPANSION_REG_RD_RW,
&legacy_status);
- DP(NETIF_MSG_LINK, "Legacy speed status"
- " = 0x%x\n", legacy_status);
+ DP(NETIF_MSG_LINK, "Legacy speed status = 0x%x\n",
+ legacy_status);
link_up = ((legacy_status & (1<<11)) == (1<<11));
if (link_up) {
legacy_speed = (legacy_status & (3<<9));
@@ -9679,9 +9683,10 @@ static u8 bnx2x_848xx_read_status(struct bnx2x_phy *phy,
else
vars->duplex = DUPLEX_HALF;
- DP(NETIF_MSG_LINK, "Link is up in %dMbps,"
- " is_duplex_full= %d\n", vars->line_speed,
- (vars->duplex == DUPLEX_FULL));
+ DP(NETIF_MSG_LINK,
+ "Link is up in %dMbps, is_duplex_full= %d\n",
+ vars->line_speed,
+ (vars->duplex == DUPLEX_FULL));
/* Check legacy speed AN resolution */
bnx2x_cl45_read(bp, phy,
MDIO_AN_DEVAD,
@@ -10251,9 +10256,10 @@ static u8 bnx2x_54618se_read_status(struct bnx2x_phy *phy,
} else /* Should not happen */
vars->line_speed = 0;
- DP(NETIF_MSG_LINK, "Link is up in %dMbps,"
- " is_duplex_full= %d\n", vars->line_speed,
- (vars->duplex == DUPLEX_FULL));
+ DP(NETIF_MSG_LINK,
+ "Link is up in %dMbps, is_duplex_full= %d\n",
+ vars->line_speed,
+ (vars->duplex == DUPLEX_FULL));
/* Check legacy speed AN resolution */
bnx2x_cl22_read(bp, phy,
@@ -11295,8 +11301,9 @@ static void bnx2x_phy_def_cfg(struct link_params *params,
dev_info.
port_hw_config[params->port].speed_capability_mask));
}
- DP(NETIF_MSG_LINK, "Default config phy idx %x cfg 0x%x speed_cap_mask"
- " 0x%x\n", phy_index, link_config, phy->speed_cap_mask);
+ DP(NETIF_MSG_LINK,
+ "Default config phy idx %x cfg 0x%x speed_cap_mask 0x%x\n",
+ phy_index, link_config, phy->speed_cap_mask);
phy->req_duplex = DUPLEX_FULL;
switch (link_config & PORT_FEATURE_LINK_SPEED_MASK) {
@@ -12254,7 +12261,7 @@ void bnx2x_period_func(struct link_params *params, struct link_vars *vars)
{
struct bnx2x *bp = params->bp;
if (!params) {
- DP(NETIF_MSG_LINK, "Ininitliazed params !\n");
+ DP(NETIF_MSG_LINK, "Uninitialized params !\n");
return;
}
/* DP(NETIF_MSG_LINK, "Periodic called vars->phy_flags 0x%x speed 0x%x
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index 173b258..e899e87 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -4388,7 +4388,7 @@ static inline void bnx2x_handle_rx_mode_eqe(struct bnx2x *bp)
static inline struct bnx2x_queue_sp_obj *bnx2x_cid_to_q_obj(
struct bnx2x *bp, u32 cid)
{
- DP(BNX2X_MSG_SP, "retrieving fp from cid %d", cid);
+ DP(BNX2X_MSG_SP, "retrieving fp from cid %d\n", cid);
#ifdef BCM_CNIC
if (cid == BNX2X_FCOE_ETH_CID)
return &bnx2x_fcoe(bp, q_obj);
@@ -7176,7 +7176,7 @@ static inline void bnx2x_pf_q_prep_init(struct bnx2x *bp,
/* set maximum number of COSs supported by this queue */
init_params->max_cos = fp->max_cos;
- DP(BNX2X_MSG_SP, "fp: %d setting queue params max cos to: %d",
+ DP(BNX2X_MSG_SP, "fp: %d setting queue params max cos to: %d\n",
fp->index, init_params->max_cos);
/* set the context pointers queue object */
@@ -7209,7 +7209,7 @@ int bnx2x_setup_tx_only(struct bnx2x *bp, struct bnx2x_fastpath *fp,
DP(BNX2X_MSG_SP, "preparing to send tx-only ramrod for connection:"
"cos %d, primary cid %d, cid %d, "
- "client id %d, sp-client id %d, flags %lx",
+ "client id %d, sp-client id %d, flags %lx\n",
tx_index, q_params->q_obj->cids[FIRST_TX_COS_INDEX],
q_params->q_obj->cids[tx_index], q_params->q_obj->cl_id,
tx_only_params->gen_params.spcl_id, tx_only_params->flags);
@@ -7241,7 +7241,7 @@ int bnx2x_setup_queue(struct bnx2x *bp, struct bnx2x_fastpath *fp,
int rc;
u8 tx_index;
- DP(BNX2X_MSG_SP, "setting up queue %d", fp->index);
+ DP(BNX2X_MSG_SP, "setting up queue %d\n", fp->index);
/* reset IGU state skip FCoE L2 queue */
if (!IS_FCOE_FP(fp))
@@ -7265,7 +7265,7 @@ int bnx2x_setup_queue(struct bnx2x *bp, struct bnx2x_fastpath *fp,
return rc;
}
- DP(BNX2X_MSG_SP, "init complete");
+ DP(BNX2X_MSG_SP, "init complete\n");
/* Now move the Queue to the SETUP state... */
@@ -7319,7 +7319,7 @@ static int bnx2x_stop_queue(struct bnx2x *bp, int index)
struct bnx2x_queue_state_params q_params = {0};
int rc, tx_index;
- DP(BNX2X_MSG_SP, "stopping queue %d cid %d", index, fp->cid);
+ DP(BNX2X_MSG_SP, "stopping queue %d cid %d\n", index, fp->cid);
q_params.q_obj = &fp->q_obj;
/* We want to wait for completion in this context */
@@ -7334,7 +7334,7 @@ static int bnx2x_stop_queue(struct bnx2x *bp, int index)
/* ascertain this is a normal queue*/
txdata = &fp->txdata[tx_index];
- DP(BNX2X_MSG_SP, "stopping tx-only queue %d",
+ DP(BNX2X_MSG_SP, "stopping tx-only queue %d\n",
txdata->txq_index);
/* send halt terminate on tx-only connection */
@@ -10704,7 +10704,7 @@ static int __devinit bnx2x_init_one(struct pci_dev *pdev,
return rc;
}
- DP(NETIF_MSG_DRV, "max_non_def_sbs %d", max_non_def_sbs);
+ DP(NETIF_MSG_DRV, "max_non_def_sbs %d\n", max_non_def_sbs);
rc = bnx2x_init_bp(bp);
if (rc)
@@ -10759,15 +10759,14 @@ static int __devinit bnx2x_init_one(struct pci_dev *pdev,
bnx2x_get_pcie_width_speed(bp, &pcie_width, &pcie_speed);
- netdev_info(dev, "%s (%c%d) PCI-E x%d %s found at mem %lx,"
- " IRQ %d, ", board_info[ent->driver_data].name,
- (CHIP_REV(bp) >> 12) + 'A', (CHIP_METAL(bp) >> 4),
- pcie_width,
- ((!CHIP_IS_E2(bp) && pcie_speed == 2) ||
- (CHIP_IS_E2(bp) && pcie_speed == 1)) ?
- "5GHz (Gen2)" : "2.5GHz",
- dev->base_addr, bp->pdev->irq);
- pr_cont("node addr %pM\n", dev->dev_addr);
+ netdev_info(dev, "%s (%c%d) PCI-E x%d %s found at mem %lx, IRQ %d, node addr %pM\n",
+ board_info[ent->driver_data].name,
+ (CHIP_REV(bp) >> 12) + 'A', (CHIP_METAL(bp) >> 4),
+ pcie_width,
+ ((!CHIP_IS_E2(bp) && pcie_speed == 2) ||
+ (CHIP_IS_E2(bp) && pcie_speed == 1)) ?
+ "5GHz (Gen2)" : "2.5GHz",
+ dev->base_addr, bp->pdev->irq, dev->dev_addr);
return 0;
diff --git a/drivers/net/bnx2x/bnx2x_sp.c b/drivers/net/bnx2x/bnx2x_sp.c
index b4d9c16..1f88c19 100644
--- a/drivers/net/bnx2x/bnx2x_sp.c
+++ b/drivers/net/bnx2x/bnx2x_sp.c
@@ -3045,8 +3045,8 @@ static int bnx2x_mcast_setup_e1h(struct bnx2x *bp,
break;
case BNX2X_MCAST_CMD_DEL:
- DP(BNX2X_MSG_SP, "Invalidating multicast "
- "MACs configuration\n");
+ DP(BNX2X_MSG_SP,
+ "Invalidating multicast MACs configuration\n");
/* clear the registry */
memset(o->registry.aprox_match.vec, 0,
@@ -4239,7 +4239,7 @@ static int bnx2x_queue_comp_cmd(struct bnx2x *bp,
o->cids[BNX2X_PRIMARY_CID_INDEX], o->next_state);
if (o->next_tx_only) /* print num tx-only if any exist */
- DP(BNX2X_MSG_SP, "primary cid %d: num tx-only cons %d",
+ DP(BNX2X_MSG_SP, "primary cid %d: num tx-only cons %d\n",
o->cids[BNX2X_PRIMARY_CID_INDEX], o->next_tx_only);
o->state = o->next_state;
@@ -4301,7 +4301,7 @@ static void bnx2x_q_fill_init_general_data(struct bnx2x *bp,
test_bit(BNX2X_Q_FLG_FCOE, flags) ?
LLFC_TRAFFIC_TYPE_FCOE : LLFC_TRAFFIC_TYPE_NW;
- DP(BNX2X_MSG_SP, "flags: active %d, cos %d, stats en %d",
+ DP(BNX2X_MSG_SP, "flags: active %d, cos %d, stats en %d\n",
gen_data->activate_flg, gen_data->cos, gen_data->statistics_en_flg);
}
@@ -4454,7 +4454,7 @@ static void bnx2x_q_fill_setup_tx_only(struct bnx2x *bp,
&data->tx,
&cmd_params->params.tx_only.flags);
- DP(BNX2X_MSG_SP, "cid %d, tx bd page lo %x hi %x",cmd_params->q_obj->cids[0],
+ DP(BNX2X_MSG_SP, "cid %d, tx bd page lo %x hi %x\n",cmd_params->q_obj->cids[0],
data->tx.tx_bd_page_base.lo, data->tx.tx_bd_page_base.hi);
}
@@ -4501,9 +4501,9 @@ static inline int bnx2x_q_init(struct bnx2x *bp,
/* Set CDU context validation values */
for (cos = 0; cos < o->max_cos; cos++) {
- DP(BNX2X_MSG_SP, "setting context validation. cid %d, cos %d",
+ DP(BNX2X_MSG_SP, "setting context validation. cid %d, cos %d\n",
o->cids[cos], cos);
- DP(BNX2X_MSG_SP, "context pointer %p", init->cxts[cos]);
+ DP(BNX2X_MSG_SP, "context pointer %p\n", init->cxts[cos]);
bnx2x_set_ctx_validation(bp, init->cxts[cos], o->cids[cos]);
}
@@ -4592,7 +4592,7 @@ static inline int bnx2x_q_send_setup_tx_only(struct bnx2x *bp,
return -EINVAL;
}
- DP(BNX2X_MSG_SP, "parameters received: cos: %d sp-id: %d",
+ DP(BNX2X_MSG_SP, "parameters received: cos: %d sp-id: %d\n",
tx_only_params->gen_params.cos,
tx_only_params->gen_params.spcl_id);
@@ -4603,7 +4603,7 @@ static inline int bnx2x_q_send_setup_tx_only(struct bnx2x *bp,
bnx2x_q_fill_setup_tx_only(bp, params, rdata);
DP(BNX2X_MSG_SP, "sending tx-only ramrod: cid %d, client-id %d,"
- "sp-client id %d, cos %d",
+ "sp-client id %d, cos %d\n",
o->cids[cid_index],
rdata->general.client_id,
rdata->general.sp_client_id, rdata->general.cos);
@@ -5160,8 +5160,9 @@ static inline int bnx2x_func_state_change_comp(struct bnx2x *bp,
return -EINVAL;
}
- DP(BNX2X_MSG_SP, "Completing command %d for func %d, setting state to "
- "%d\n", cmd, BP_FUNC(bp), o->next_state);
+ DP(BNX2X_MSG_SP,
+ "Completing command %d for func %d, setting state to %d\n",
+ cmd, BP_FUNC(bp), o->next_state);
o->state = o->next_state;
o->next_state = BNX2X_F_STATE_MAX;
--
1.7.6.405.gc1be0
^ permalink raw reply related
* Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
From: Robin Holt @ 2011-08-08 15:55 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300
In-Reply-To: <4E4001E1.3030508-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Mon, Aug 08, 2011 at 05:33:53PM +0200, Wolfgang Grandegger wrote:
> On 08/08/2011 05:14 PM, Marc Kleine-Budde wrote:
...
> > On 08/08/2011 04:59 PM, Wolfgang Grandegger wrote:
> >> On 08/08/2011 04:44 PM, Robin Holt wrote:
> >>> On Mon, Aug 08, 2011 at 04:37:44PM +0200, Wolfgang Grandegger wrote:
> >>>> On 08/08/2011 04:21 PM, Robin Holt wrote:
> >>>>> On Mon, Aug 08, 2011 at 04:16:27PM +0200, Wolfgang Grandegger wrote:
> >>>>>> On 08/08/2011 03:56 PM, Robin Holt wrote:
> >>>>>>>> commit 65bb8b060a873fa4f5188f2951081f6011259614
> >>>>>>>> Author: Bhaskar Upadhaya <Bhaskar.Upadhaya-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> >>>>>>>> Date: Fri Mar 4 20:27:58 2011 +0530
> >>>>>>>
> >>>>>>> On a side note, that commit fixes up "fsl,flexcan-v1.0"
> >>>>>>> ...
> >>>>>>> + do_fixup_by_compat_u32(blob, "fsl,flexcan-v1.0",
> >>>>>>> + "clock_freq", gd->bus_clk, 1);
> >>>>>>>
> >>>>>>> Should I go back to flexcan-v1.0 in my patches?
> >>>>>>
> >>>>>> Well, no. Let's wait. I don't think we need it. Also, it sets
> >>>>>> "clock_freq" while
> >>>>>>
> >>>>>> http://lxr.linux.no/#linux+v3.0.1/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> >>>>>>
> >>>>>> documents "clock-frequencies"... :-(.
> >>>>>
> >>>>> You answered a different question that I was asking. I was asking if
> >>>>> I should change fsl,flexcan back to fsl,flexcan-v1.0 as documented on
> >>>>> line 5. The clock_freq looks like a uboot change will need to be made
> >>>>> as well.
> >>>>
> >>>> Well, I wrote above: "Well, no. Let's wait. I don't think we need it."
> >>>>
> >>>> For the P1010 we can sinmply derive the clock frequency from
> >>>> "fsl_get_sys_freq()", which is fine for the time being. No extra
> >>>> properties, etc. The clk implemetation might go into
> >>>>
> >>>> http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/platforms/85xx/clock.c
> >>>>
> >>>> or
> >>>>
> >>>> http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/sysdev/fsl_soc.c
> >>>>
> >>>> And may depend on HAVE_CAN_FLEXCAN
> >>>>
> >>>> BTW, I have not found HAVE_CAN_FLEXCAN in your patch. What kernel are
> >>>> you using?
> >>>
> >>> I am starting with the v3.0 kernel, apply one patch from the freescale BSP
> >>> we receive under NDA which introduces the P1010RDB board into the QorIQ
> >>> platform, and then work from there for the flexcan stuff. That patch
> >>> introduces the HAVE_CAN_FLEXCAN. I do not like how freescale structured
> >>> that Kconfig bit, so I have tweaked it to be selected automatically
> >>> when P1010RDB, NET, and CAN are selected. That allows the CAN_FLEXCAN
> >>> selection to determine is we are going to build the flexcan.c file.
> >>
> >> ARM boards select HAVE_CAN_FLEXCAN and I do not see a good reason why
> >> we should do it differently for PowerPC.
> >>
> >> For mainline inclusion, you should provide your patches against the
> >> David Millers "net-next-2.6" tree, which already seems to have support
> >> for the P1010RDB:
> >>
> >> config P1010_RDB
> >> bool "Freescale P1010RDB"
> >> select DEFAULT_UIMAGE
> >> help
> >> This option enables support for the MPC85xx RDB (P1010 RDB) board
> >>
> >> P1010RDB contains P1010Si, which provides CPU performance up to 800
> >> MHz and 1600 DMIPS, additional functionality and faster interfaces
> >> (DDR3/3L, SATA II, and PCI Express).
> >>
> >>
> >>> Our contact with Freescale would prefer that I not post that patch until
> >>> we get the OK from freescale to do so since we received it under NDA.
> >>
> >> I don't think we currently need it. I prefer dropping and cleaning up
> >> the device tree stuff as it is not needed for the P1010 anyway. If a
> >> new processor shows up with enhanced capabilities requiring
> >> configuration via device tree, we or somebody else can provide a patch.
> >> Marc, what do you think?
> >
> > ACK - The device tree bindings as in mainline's Documentation is a mess.
> > If the powerpc guys are happy with a clock interfaces based approach
> > somewhere in arch/ppc, I'm more than happy to remove:
> > - fsl,flexcan-clock-source (not implemented, even in the fsl driver)
> >
> > - fsl,flexcan-clock-divider \__ replace with code in arch/ppc, or
> > - clock-frequency / a single clock-frequency attribute
>
> In the "net-next-2.6" tree there is also:
>
> $ grep flexcan arch/powerpc/boots/dts/*.dts
> p1010rdb.dts: fsl,flexcan-clock-source = "platform";
> p1010rdb.dts: fsl,flexcan-clock-source = "platform";
> p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
> p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
> p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
> p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
>
> Especially the fsl,flexcan-clock-divider = <2>; might make people think,
> that they could set something else.
I am currently lost on the direction. I think I need something like:
1) Patch 1/5 removing the "#include <mach/clock.h>" stays.
2) Patch 2/5 abstracting readl/writel stays.
3) Patch 3/5 of_match for ppc and the match string is "fsl,flexcan" stays.
4) Patch 4/5 I have not been given clear direction to not do it but have
not gotten a favorable response.
5) Patch 5/5 goes from being a powerpc patch back to being a flexcan.c
patch which determines the clock source not using the device tree
information, but rather from some system register. I need more detail
on how this would work for both arm and powerpc. How would I absract
that or am I providing a flexcan_clk_* set of functions like I have
in earlier generations of the patch set?
Thanks,
Robin
^ permalink raw reply
* Re: 802.3ad bonding brain damaged?
From: Eric Dumazet @ 2011-08-08 15:59 UTC (permalink / raw)
To: David Lamparter; +Cc: Phillip Susi, netdev
In-Reply-To: <1312790234.7020.26.camel@arkology.n2.diac24.net>
Le lundi 08 août 2011 à 09:57 +0200, David Lamparter a écrit :
> Am Sonntag, den 07.08.2011, 15:52 -0400 schrieb Phillip Susi:
> > - From Documentation/networking/bonding.txt:
> >
> > Additionally, the linux bonding 802.3ad implementation
> > distributes traffic by peer (using an XOR of MAC addresses),
> >
> > This is counter to the entire point of 802.3ad. Distributing traffic by
> > hash of the destination address is poor mans load balancing for
> > systems not supporting 802.3ad.
>
> No, it isn't. 802.3ad/.1AX explicitly requires that no packet
> re-ordering may ever occur, which can only be guaranteed by enqueueing
> packets for one host on one TX interface. This behaviour is mandated by
> 802.1AX-2008 page 15 which reads:
>
> This standard does not mandate any particular distribution
> algorithm(s); however, any distribution algorithm shall ensure that,
> when frames are received by a Frame Collector as specified in 5.2.3,
> the algorithm shall not cause
> a) Misordering of frames that are part of any given conversation, or
> b) Duplication of frames.
> | The above requirement to maintain frame ordering is met by ensuring
> | that all frames that compose a given conversation are transmitted on a
> | single link in the order that they are generated by the MAC Client;
> hence, this requirement does not involve the addition (or
> modification) of any information to the MAC frame, nor any buffering
> or processing on the part of the corresponding Frame Collector in
> order to reorder frames. This approach to the operation of the
> distribution function permits a wide variety of distribution and load
> balancing algorithms to be used, while also ensuring interoperability
> between devices that adopt differing algorithms.
>
It all depends on the definition of 'conversation'
Phillip assumed two (or more) TCP flows from machine A to machine B
could use two different links, while you assert they MUST use a single
link.
^ permalink raw reply
* Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
From: Robin Holt @ 2011-08-08 15:59 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300
In-Reply-To: <20110808155540.GD4926-sJ/iWh9BUns@public.gmane.org>
Ignore this. We cross in the mail. I will go back to your other thread.
Robin
On Mon, Aug 08, 2011 at 10:55:40AM -0500, Robin Holt wrote:
> On Mon, Aug 08, 2011 at 05:33:53PM +0200, Wolfgang Grandegger wrote:
> > On 08/08/2011 05:14 PM, Marc Kleine-Budde wrote:
> ...
>
> > > On 08/08/2011 04:59 PM, Wolfgang Grandegger wrote:
> > >> On 08/08/2011 04:44 PM, Robin Holt wrote:
> > >>> On Mon, Aug 08, 2011 at 04:37:44PM +0200, Wolfgang Grandegger wrote:
> > >>>> On 08/08/2011 04:21 PM, Robin Holt wrote:
> > >>>>> On Mon, Aug 08, 2011 at 04:16:27PM +0200, Wolfgang Grandegger wrote:
> > >>>>>> On 08/08/2011 03:56 PM, Robin Holt wrote:
> > >>>>>>>> commit 65bb8b060a873fa4f5188f2951081f6011259614
> > >>>>>>>> Author: Bhaskar Upadhaya <Bhaskar.Upadhaya-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > >>>>>>>> Date: Fri Mar 4 20:27:58 2011 +0530
> > >>>>>>>
> > >>>>>>> On a side note, that commit fixes up "fsl,flexcan-v1.0"
> > >>>>>>> ...
> > >>>>>>> + do_fixup_by_compat_u32(blob, "fsl,flexcan-v1.0",
> > >>>>>>> + "clock_freq", gd->bus_clk, 1);
> > >>>>>>>
> > >>>>>>> Should I go back to flexcan-v1.0 in my patches?
> > >>>>>>
> > >>>>>> Well, no. Let's wait. I don't think we need it. Also, it sets
> > >>>>>> "clock_freq" while
> > >>>>>>
> > >>>>>> http://lxr.linux.no/#linux+v3.0.1/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > >>>>>>
> > >>>>>> documents "clock-frequencies"... :-(.
> > >>>>>
> > >>>>> You answered a different question that I was asking. I was asking if
> > >>>>> I should change fsl,flexcan back to fsl,flexcan-v1.0 as documented on
> > >>>>> line 5. The clock_freq looks like a uboot change will need to be made
> > >>>>> as well.
> > >>>>
> > >>>> Well, I wrote above: "Well, no. Let's wait. I don't think we need it."
> > >>>>
> > >>>> For the P1010 we can sinmply derive the clock frequency from
> > >>>> "fsl_get_sys_freq()", which is fine for the time being. No extra
> > >>>> properties, etc. The clk implemetation might go into
> > >>>>
> > >>>> http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/platforms/85xx/clock.c
> > >>>>
> > >>>> or
> > >>>>
> > >>>> http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/sysdev/fsl_soc.c
> > >>>>
> > >>>> And may depend on HAVE_CAN_FLEXCAN
> > >>>>
> > >>>> BTW, I have not found HAVE_CAN_FLEXCAN in your patch. What kernel are
> > >>>> you using?
> > >>>
> > >>> I am starting with the v3.0 kernel, apply one patch from the freescale BSP
> > >>> we receive under NDA which introduces the P1010RDB board into the QorIQ
> > >>> platform, and then work from there for the flexcan stuff. That patch
> > >>> introduces the HAVE_CAN_FLEXCAN. I do not like how freescale structured
> > >>> that Kconfig bit, so I have tweaked it to be selected automatically
> > >>> when P1010RDB, NET, and CAN are selected. That allows the CAN_FLEXCAN
> > >>> selection to determine is we are going to build the flexcan.c file.
> > >>
> > >> ARM boards select HAVE_CAN_FLEXCAN and I do not see a good reason why
> > >> we should do it differently for PowerPC.
> > >>
> > >> For mainline inclusion, you should provide your patches against the
> > >> David Millers "net-next-2.6" tree, which already seems to have support
> > >> for the P1010RDB:
> > >>
> > >> config P1010_RDB
> > >> bool "Freescale P1010RDB"
> > >> select DEFAULT_UIMAGE
> > >> help
> > >> This option enables support for the MPC85xx RDB (P1010 RDB) board
> > >>
> > >> P1010RDB contains P1010Si, which provides CPU performance up to 800
> > >> MHz and 1600 DMIPS, additional functionality and faster interfaces
> > >> (DDR3/3L, SATA II, and PCI Express).
> > >>
> > >>
> > >>> Our contact with Freescale would prefer that I not post that patch until
> > >>> we get the OK from freescale to do so since we received it under NDA.
> > >>
> > >> I don't think we currently need it. I prefer dropping and cleaning up
> > >> the device tree stuff as it is not needed for the P1010 anyway. If a
> > >> new processor shows up with enhanced capabilities requiring
> > >> configuration via device tree, we or somebody else can provide a patch.
> > >> Marc, what do you think?
> > >
> > > ACK - The device tree bindings as in mainline's Documentation is a mess.
> > > If the powerpc guys are happy with a clock interfaces based approach
> > > somewhere in arch/ppc, I'm more than happy to remove:
> > > - fsl,flexcan-clock-source (not implemented, even in the fsl driver)
> > >
> > > - fsl,flexcan-clock-divider \__ replace with code in arch/ppc, or
> > > - clock-frequency / a single clock-frequency attribute
> >
> > In the "net-next-2.6" tree there is also:
> >
> > $ grep flexcan arch/powerpc/boots/dts/*.dts
> > p1010rdb.dts: fsl,flexcan-clock-source = "platform";
> > p1010rdb.dts: fsl,flexcan-clock-source = "platform";
> > p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
> > p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
> > p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
> > p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
> >
> > Especially the fsl,flexcan-clock-divider = <2>; might make people think,
> > that they could set something else.
>
> I am currently lost on the direction. I think I need something like:
>
> 1) Patch 1/5 removing the "#include <mach/clock.h>" stays.
> 2) Patch 2/5 abstracting readl/writel stays.
> 3) Patch 3/5 of_match for ppc and the match string is "fsl,flexcan" stays.
> 4) Patch 4/5 I have not been given clear direction to not do it but have
> not gotten a favorable response.
> 5) Patch 5/5 goes from being a powerpc patch back to being a flexcan.c
> patch which determines the clock source not using the device tree
> information, but rather from some system register. I need more detail
> on how this would work for both arm and powerpc. How would I absract
> that or am I providing a flexcan_clk_* set of functions like I have
> in earlier generations of the patch set?
>
> Thanks,
> Robin
> _______________________________________________
> Socketcan-core mailing list
> Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
> https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
From: Wolfgang Grandegger @ 2011-08-08 16:03 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, Marc Kleine-Budde,
U Bhaskar-B22300
In-Reply-To: <20110808155540.GD4926-sJ/iWh9BUns@public.gmane.org>
On 08/08/2011 05:55 PM, Robin Holt wrote:
> On Mon, Aug 08, 2011 at 05:33:53PM +0200, Wolfgang Grandegger wrote:
>> On 08/08/2011 05:14 PM, Marc Kleine-Budde wrote:
> ...
>
>>> On 08/08/2011 04:59 PM, Wolfgang Grandegger wrote:
>>>> On 08/08/2011 04:44 PM, Robin Holt wrote:
>>>>> On Mon, Aug 08, 2011 at 04:37:44PM +0200, Wolfgang Grandegger wrote:
>>>>>> On 08/08/2011 04:21 PM, Robin Holt wrote:
>>>>>>> On Mon, Aug 08, 2011 at 04:16:27PM +0200, Wolfgang Grandegger wrote:
>>>>>>>> On 08/08/2011 03:56 PM, Robin Holt wrote:
>>>>>>>>>> commit 65bb8b060a873fa4f5188f2951081f6011259614
>>>>>>>>>> Author: Bhaskar Upadhaya <Bhaskar.Upadhaya-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>>>>>>>>>> Date: Fri Mar 4 20:27:58 2011 +0530
>>>>>>>>>
>>>>>>>>> On a side note, that commit fixes up "fsl,flexcan-v1.0"
>>>>>>>>> ...
>>>>>>>>> + do_fixup_by_compat_u32(blob, "fsl,flexcan-v1.0",
>>>>>>>>> + "clock_freq", gd->bus_clk, 1);
>>>>>>>>>
>>>>>>>>> Should I go back to flexcan-v1.0 in my patches?
>>>>>>>>
>>>>>>>> Well, no. Let's wait. I don't think we need it. Also, it sets
>>>>>>>> "clock_freq" while
>>>>>>>>
>>>>>>>> http://lxr.linux.no/#linux+v3.0.1/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
>>>>>>>>
>>>>>>>> documents "clock-frequencies"... :-(.
>>>>>>>
>>>>>>> You answered a different question that I was asking. I was asking if
>>>>>>> I should change fsl,flexcan back to fsl,flexcan-v1.0 as documented on
>>>>>>> line 5. The clock_freq looks like a uboot change will need to be made
>>>>>>> as well.
>>>>>>
>>>>>> Well, I wrote above: "Well, no. Let's wait. I don't think we need it."
>>>>>>
>>>>>> For the P1010 we can sinmply derive the clock frequency from
>>>>>> "fsl_get_sys_freq()", which is fine for the time being. No extra
>>>>>> properties, etc. The clk implemetation might go into
>>>>>>
>>>>>> http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/platforms/85xx/clock.c
>>>>>>
>>>>>> or
>>>>>>
>>>>>> http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/sysdev/fsl_soc.c
>>>>>>
>>>>>> And may depend on HAVE_CAN_FLEXCAN
>>>>>>
>>>>>> BTW, I have not found HAVE_CAN_FLEXCAN in your patch. What kernel are
>>>>>> you using?
>>>>>
>>>>> I am starting with the v3.0 kernel, apply one patch from the freescale BSP
>>>>> we receive under NDA which introduces the P1010RDB board into the QorIQ
>>>>> platform, and then work from there for the flexcan stuff. That patch
>>>>> introduces the HAVE_CAN_FLEXCAN. I do not like how freescale structured
>>>>> that Kconfig bit, so I have tweaked it to be selected automatically
>>>>> when P1010RDB, NET, and CAN are selected. That allows the CAN_FLEXCAN
>>>>> selection to determine is we are going to build the flexcan.c file.
>>>>
>>>> ARM boards select HAVE_CAN_FLEXCAN and I do not see a good reason why
>>>> we should do it differently for PowerPC.
>>>>
>>>> For mainline inclusion, you should provide your patches against the
>>>> David Millers "net-next-2.6" tree, which already seems to have support
>>>> for the P1010RDB:
>>>>
>>>> config P1010_RDB
>>>> bool "Freescale P1010RDB"
>>>> select DEFAULT_UIMAGE
>>>> help
>>>> This option enables support for the MPC85xx RDB (P1010 RDB) board
>>>>
>>>> P1010RDB contains P1010Si, which provides CPU performance up to 800
>>>> MHz and 1600 DMIPS, additional functionality and faster interfaces
>>>> (DDR3/3L, SATA II, and PCI Express).
>>>>
>>>>
>>>>> Our contact with Freescale would prefer that I not post that patch until
>>>>> we get the OK from freescale to do so since we received it under NDA.
>>>>
>>>> I don't think we currently need it. I prefer dropping and cleaning up
>>>> the device tree stuff as it is not needed for the P1010 anyway. If a
>>>> new processor shows up with enhanced capabilities requiring
>>>> configuration via device tree, we or somebody else can provide a patch.
>>>> Marc, what do you think?
>>>
>>> ACK - The device tree bindings as in mainline's Documentation is a mess.
>>> If the powerpc guys are happy with a clock interfaces based approach
>>> somewhere in arch/ppc, I'm more than happy to remove:
>>> - fsl,flexcan-clock-source (not implemented, even in the fsl driver)
>>>
>>> - fsl,flexcan-clock-divider \__ replace with code in arch/ppc, or
>>> - clock-frequency / a single clock-frequency attribute
>>
>> In the "net-next-2.6" tree there is also:
>>
>> $ grep flexcan arch/powerpc/boots/dts/*.dts
>> p1010rdb.dts: fsl,flexcan-clock-source = "platform";
>> p1010rdb.dts: fsl,flexcan-clock-source = "platform";
>> p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
>> p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
>> p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
>> p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
>>
>> Especially the fsl,flexcan-clock-divider = <2>; might make people think,
>> that they could set something else.
>
> I am currently lost on the direction. I think I need something like:
>
> 1) Patch 1/5 removing the "#include <mach/clock.h>" stays.
OK.
> 2) Patch 2/5 abstracting readl/writel stays.
OK.
> 3) Patch 3/5 of_match for ppc and the match string is "fsl,flexcan" stays.
Yep.
> 4) Patch 4/5 I have not been given clear direction to not do it but have
> not gotten a favorable response.
Please drop this one for mainline.
> 5) Patch 5/5 goes from being a powerpc patch back to being a flexcan.c
No, I just would prefer a more general place, e.g.:
http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/platforms/85xx/clock.c
Furthermore you need patches to cleanup some DTS and platform files and
the Documentation.
Wolfgang.
^ permalink raw reply
* Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
From: Robin Holt @ 2011-08-08 16:08 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300,
Marc Kleine-Budde
In-Reply-To: <4E4008BA.6030303-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Mon, Aug 08, 2011 at 06:03:06PM +0200, Wolfgang Grandegger wrote:
> On 08/08/2011 05:55 PM, Robin Holt wrote:
> > On Mon, Aug 08, 2011 at 05:33:53PM +0200, Wolfgang Grandegger wrote:
> >> On 08/08/2011 05:14 PM, Marc Kleine-Budde wrote:
> > ...
> >
> >>> On 08/08/2011 04:59 PM, Wolfgang Grandegger wrote:
> >>>> On 08/08/2011 04:44 PM, Robin Holt wrote:
> >>>>> On Mon, Aug 08, 2011 at 04:37:44PM +0200, Wolfgang Grandegger wrote:
> >>>>>> On 08/08/2011 04:21 PM, Robin Holt wrote:
> >>>>>>> On Mon, Aug 08, 2011 at 04:16:27PM +0200, Wolfgang Grandegger wrote:
> >>>>>>>> On 08/08/2011 03:56 PM, Robin Holt wrote:
> >>>>>>>>>> commit 65bb8b060a873fa4f5188f2951081f6011259614
> >>>>>>>>>> Author: Bhaskar Upadhaya <Bhaskar.Upadhaya-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> >>>>>>>>>> Date: Fri Mar 4 20:27:58 2011 +0530
> >>>>>>>>>
> >>>>>>>>> On a side note, that commit fixes up "fsl,flexcan-v1.0"
> >>>>>>>>> ...
> >>>>>>>>> + do_fixup_by_compat_u32(blob, "fsl,flexcan-v1.0",
> >>>>>>>>> + "clock_freq", gd->bus_clk, 1);
> >>>>>>>>>
> >>>>>>>>> Should I go back to flexcan-v1.0 in my patches?
> >>>>>>>>
> >>>>>>>> Well, no. Let's wait. I don't think we need it. Also, it sets
> >>>>>>>> "clock_freq" while
> >>>>>>>>
> >>>>>>>> http://lxr.linux.no/#linux+v3.0.1/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> >>>>>>>>
> >>>>>>>> documents "clock-frequencies"... :-(.
> >>>>>>>
> >>>>>>> You answered a different question that I was asking. I was asking if
> >>>>>>> I should change fsl,flexcan back to fsl,flexcan-v1.0 as documented on
> >>>>>>> line 5. The clock_freq looks like a uboot change will need to be made
> >>>>>>> as well.
> >>>>>>
> >>>>>> Well, I wrote above: "Well, no. Let's wait. I don't think we need it."
> >>>>>>
> >>>>>> For the P1010 we can sinmply derive the clock frequency from
> >>>>>> "fsl_get_sys_freq()", which is fine for the time being. No extra
> >>>>>> properties, etc. The clk implemetation might go into
> >>>>>>
> >>>>>> http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/platforms/85xx/clock.c
> >>>>>>
> >>>>>> or
> >>>>>>
> >>>>>> http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/sysdev/fsl_soc.c
> >>>>>>
> >>>>>> And may depend on HAVE_CAN_FLEXCAN
> >>>>>>
> >>>>>> BTW, I have not found HAVE_CAN_FLEXCAN in your patch. What kernel are
> >>>>>> you using?
> >>>>>
> >>>>> I am starting with the v3.0 kernel, apply one patch from the freescale BSP
> >>>>> we receive under NDA which introduces the P1010RDB board into the QorIQ
> >>>>> platform, and then work from there for the flexcan stuff. That patch
> >>>>> introduces the HAVE_CAN_FLEXCAN. I do not like how freescale structured
> >>>>> that Kconfig bit, so I have tweaked it to be selected automatically
> >>>>> when P1010RDB, NET, and CAN are selected. That allows the CAN_FLEXCAN
> >>>>> selection to determine is we are going to build the flexcan.c file.
> >>>>
> >>>> ARM boards select HAVE_CAN_FLEXCAN and I do not see a good reason why
> >>>> we should do it differently for PowerPC.
> >>>>
> >>>> For mainline inclusion, you should provide your patches against the
> >>>> David Millers "net-next-2.6" tree, which already seems to have support
> >>>> for the P1010RDB:
> >>>>
> >>>> config P1010_RDB
> >>>> bool "Freescale P1010RDB"
> >>>> select DEFAULT_UIMAGE
> >>>> help
> >>>> This option enables support for the MPC85xx RDB (P1010 RDB) board
> >>>>
> >>>> P1010RDB contains P1010Si, which provides CPU performance up to 800
> >>>> MHz and 1600 DMIPS, additional functionality and faster interfaces
> >>>> (DDR3/3L, SATA II, and PCI Express).
> >>>>
> >>>>
> >>>>> Our contact with Freescale would prefer that I not post that patch until
> >>>>> we get the OK from freescale to do so since we received it under NDA.
> >>>>
> >>>> I don't think we currently need it. I prefer dropping and cleaning up
> >>>> the device tree stuff as it is not needed for the P1010 anyway. If a
> >>>> new processor shows up with enhanced capabilities requiring
> >>>> configuration via device tree, we or somebody else can provide a patch.
> >>>> Marc, what do you think?
> >>>
> >>> ACK - The device tree bindings as in mainline's Documentation is a mess.
> >>> If the powerpc guys are happy with a clock interfaces based approach
> >>> somewhere in arch/ppc, I'm more than happy to remove:
> >>> - fsl,flexcan-clock-source (not implemented, even in the fsl driver)
> >>>
> >>> - fsl,flexcan-clock-divider \__ replace with code in arch/ppc, or
> >>> - clock-frequency / a single clock-frequency attribute
> >>
> >> In the "net-next-2.6" tree there is also:
> >>
> >> $ grep flexcan arch/powerpc/boots/dts/*.dts
> >> p1010rdb.dts: fsl,flexcan-clock-source = "platform";
> >> p1010rdb.dts: fsl,flexcan-clock-source = "platform";
> >> p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
> >> p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
> >> p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
> >> p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
> >>
> >> Especially the fsl,flexcan-clock-divider = <2>; might make people think,
> >> that they could set something else.
> >
> > I am currently lost on the direction. I think I need something like:
> >
> > 1) Patch 1/5 removing the "#include <mach/clock.h>" stays.
>
> OK.
Is that an Acked-by: or not?
>
> > 2) Patch 2/5 abstracting readl/writel stays.
>
> OK.
Is that an Acked-by: or not?
>
> > 3) Patch 3/5 of_match for ppc and the match string is "fsl,flexcan" stays.
>
> Yep.
Done.
>
> > 4) Patch 4/5 I have not been given clear direction to not do it but have
> > not gotten a favorable response.
>
> Please drop this one for mainline.
Done.
>
> > 5) Patch 5/5 goes from being a powerpc patch back to being a flexcan.c
>
> No, I just would prefer a more general place, e.g.:
>
> http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/platforms/85xx/clock.c
>
> Furthermore you need patches to cleanup some DTS and platform files and
> the Documentation.
So we would stay with the clk_* functions. I assume clk_get() would
return NULL, clk_get_rate() would just return fsl_get_sys_freq() and
the other functions would do nothing. Doesn't this really polute what
clk_* functions are supposed to do? Aren't we making flexcan dictate
a different behavior for powerpc than for the arm (and possibly other)
architectures?
Thanks,
Robin
^ permalink raw reply
* Re: Bonding problem
From: Andy Gospodarek @ 2011-08-08 16:26 UTC (permalink / raw)
To: Eduard Sinelnikov; +Cc: majordomo, netdev, Jay Vosburgh, Andy Gospodarek
In-Reply-To: <CANMAZFUibmkyfWP2TyjwV6wtox6LNry2Gh3AtXB2KHnhGF80rQ@mail.gmail.com>
On Sun, Aug 07, 2011 at 03:00:30PM +0300, Eduard Sinelnikov wrote:
> Hi,
>
> In the kernel 2.6.39.3 ( /drivers/net/bond/bond_main.c).
> In the function ‘bond_xmit_roundrobin’
> The code check if the bond is active via
> ‘bond_is_active_slave(slave)’ Function call.
> Which actually checks if the slave is backup or active
> What is the meaning of slave being backup in round robin mode?
> Correct me if I wrong but in round robin every slave should send a
> packet, regardless of being active or backup.
>
> Thank you,
> Eduard
There probably is not a compelling reason to continue to have it. There
may be a reason historically, but I'm not aware what that might be at
this point. For modes other than active-backup, the value of
slave->link and slave->backup should always contain a value that
indicates the slave is up and available for transmit.
^ permalink raw reply
* [PATCH] drivers/net/can/sja1000/plx_pci.c: eliminate double free
From: Julia Lawall @ 2011-08-08 16:28 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: kernel-janitors, Joe Perches, netdev, linux-kernel
From: Julia Lawall <julia@diku.dk>
In this code, the failure_cleanup label calls the function
plx_pci_del_card, which frees everything in the card->net_dev array. dev
is placed in this array immediately after allocation, so the two subsequent
jumps to failure_cleanup should not also call free_sja1000dev, but the
second one does.
If plx_pci_check_sja1000 fails, then free_sja1000dev is also called on
dev. Because dev is already in the card->net_dev array, this implies that
when plx_pci_del_card is later called, it may get freed again. So that
entry is reset to NULL after the free.
Finally, if there is a problem with one channel, there will be a hole in the
array. card->channels counts the number of channels that have succeeded,
and does not keep track of the index of the largest element in the array
that is valid. So the loop in plx_pci_del_card is changed to go up to
PLX_PCI_MAX_CHAN, which is only 2.
Signed-off-by: Julia Lawall <julia@diku.dk>
---
Compiled but not tested. I'm not sure the fix is sufficient to take into
account possible failures. In particular, is it safe to call
unregister_sja1000dev without previously having (successfully) called
register_sja1000dev?
drivers/net/can/sja1000/plx_pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/sja1000/plx_pci.c b/drivers/net/can/sja1000/plx_pci.c
index 231385b..c7f3d4e 100644
--- a/drivers/net/can/sja1000/plx_pci.c
+++ b/drivers/net/can/sja1000/plx_pci.c
@@ -408,7 +408,7 @@ static void plx_pci_del_card(struct pci_dev *pdev)
struct sja1000_priv *priv;
int i = 0;
- for (i = 0; i < card->channels; i++) {
+ for (i = 0; i < PLX_PCI_MAX_CHAN; i++) {
dev = card->net_dev[i];
if (!dev)
continue;
@@ -536,7 +536,6 @@ static int __devinit plx_pci_add_card(struct pci_dev *pdev,
if (err) {
dev_err(&pdev->dev, "Registering device failed "
"(err=%d)\n", err);
- free_sja1000dev(dev);
goto failure_cleanup;
}
@@ -549,6 +548,7 @@ static int __devinit plx_pci_add_card(struct pci_dev *pdev,
dev_err(&pdev->dev, "Channel #%d not detected\n",
i + 1);
free_sja1000dev(dev);
+ card->net_dev[i] = NULL;
}
}
^ permalink raw reply related
* Re: 802.3ad bonding brain damaged?
From: Jay Vosburgh @ 2011-08-08 16:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Lamparter, Phillip Susi, netdev
In-Reply-To: <1312819168.2531.3.camel@edumazet-laptop>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
>Le lundi 08 août 2011 à 09:57 +0200, David Lamparter a écrit :
>> Am Sonntag, den 07.08.2011, 15:52 -0400 schrieb Phillip Susi:
>> > - From Documentation/networking/bonding.txt:
>> >
>> > Additionally, the linux bonding 802.3ad implementation
>> > distributes traffic by peer (using an XOR of MAC addresses),
>> >
>> > This is counter to the entire point of 802.3ad. Distributing traffic by
>> > hash of the destination address is poor mans load balancing for
>> > systems not supporting 802.3ad.
>>
>> No, it isn't. 802.3ad/.1AX explicitly requires that no packet
>> re-ordering may ever occur, which can only be guaranteed by enqueueing
>> packets for one host on one TX interface. This behaviour is mandated by
>> 802.1AX-2008 page 15 which reads:
>>
>> This standard does not mandate any particular distribution
>> algorithm(s); however, any distribution algorithm shall ensure that,
>> when frames are received by a Frame Collector as specified in 5.2.3,
>> the algorithm shall not cause
>> a) Misordering of frames that are part of any given conversation, or
>> b) Duplication of frames.
>> | The above requirement to maintain frame ordering is met by ensuring
>> | that all frames that compose a given conversation are transmitted on a
>> | single link in the order that they are generated by the MAC Client;
>> hence, this requirement does not involve the addition (or
>> modification) of any information to the MAC frame, nor any buffering
>> or processing on the part of the corresponding Frame Collector in
>> order to reorder frames. This approach to the operation of the
>> distribution function permits a wide variety of distribution and load
>> balancing algorithms to be used, while also ensuring interoperability
>> between devices that adopt differing algorithms.
>>
>
>It all depends on the definition of 'conversation'
The definition from 802.1AX is:
3.8 conversation: A set of frames transmitted from one end station to
another, where all of the frames form an ordered sequence, and where the
communicating end stations require the ordering to be maintained among
the set of frames exchanged. (See IEEE Std 802.1AX, Clause 5.)
So, basically, a TCP connection or a sequence of UDP datagrams
from one IP.port to another and optionally the reverse.
>Phillip assumed two (or more) TCP flows from machine A to machine B
>could use two different links, while you assert they MUST use a single
>link.
The standard permits us to place separate conversations on
different ports, even if they are going to the same MAC destination.
802.1AX 5.2.1:
f) Frame ordering must be maintained for certain sequences of frame
exchanges between MAC Clients (known as conversations, see Clause
3). The Distributor ensures that all frames of a given conversation are
passed to a single port. For any given port, the Collector is required
to pass frames to the MAC Client in the order that they are received
from that port. The Collector is otherwise free to select frames
received from the aggregated ports in any order. Since there are no
means for frames to be misordered on a single link, this guarantees that
frame ordering is maintained for any conversation.
g) Conversations may be moved among ports within an aggregation, both
for load balancing and to maintain availability in the event of link
failures.
The standard requires ordering for frames within any one
conversation, but does not require ordering of frames between
conversations.
The layer2 (MAC) and layer3 (MAC + IP) hashes in bonding are
compliant to this. The layer3+4 (IP + TCP/UDP port) is not, because
fragmented datagrams will hash differently than unfragmented datagrams.
I've not heard that this noncompliance has been a problem in actual
practice.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [RFC PATCH] common receive API + r8169 use
From: Eric Dumazet @ 2011-08-08 16:47 UTC (permalink / raw)
To: Michał Mirosław; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20110802214349.GA17411@rere.qmqm.pl>
Le mardi 02 août 2011 à 23:43 +0200, Michał Mirosław a écrit :
> I don't have fast enough transmitter yet, so have no real data. Eric's
> testing showed dramatic reduction in CPU usage after changing igb to use
> build_skb(). Inlined version of this patch should give similar results.
>
> Eric: can you share the igb changes? I have no hardware for it, but could
> merge our changes for you to test.
>
Hi Michal
I am just coming back from one vacation period, I'll send patches before
another one, maybe tomorrow, stay tuned ;)
^ permalink raw reply
* Re: Bonding problem
From: Jay Vosburgh @ 2011-08-08 17:06 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: Eduard Sinelnikov, netdev
In-Reply-To: <20110808162645.GT21309@gospo.rdu.redhat.com>
Andy Gospodarek <andy@greyhouse.net> wrote:
>On Sun, Aug 07, 2011 at 03:00:30PM +0300, Eduard Sinelnikov wrote:
>> Hi,
>>
>> In the kernel 2.6.39.3 ( /drivers/net/bond/bond_main.c).
>> In the function ‘bond_xmit_roundrobin’
>> The code check if the bond is active via
>> ‘bond_is_active_slave(slave)’ Function call.
>> Which actually checks if the slave is backup or active
>> What is the meaning of slave being backup in round robin mode?
>> Correct me if I wrong but in round robin every slave should send a
>> packet, regardless of being active or backup.
>>
>> Thank you,
>> Eduard
>
>There probably is not a compelling reason to continue to have it. There
>may be a reason historically, but I'm not aware what that might be at
>this point. For modes other than active-backup, the value of
>slave->link and slave->backup should always contain a value that
>indicates the slave is up and available for transmit.
If you read Eduard's other posts regarding this, the actual
issue is that when changing from another mode into round-robin,
occasionally slaves will still be marked as "backup" and won't be used:
>Date: Mon, 8 Aug 2011 11:16:39 +0300
>Subject: On line Bonding configuration change fails
>From: Eduard Sinelnikov <eduard.sinelnikov@gmail.com>
>To: netdev@vger.kernel.org
>Sender: netdev-owner@vger.kernel.org
>
>Hi,
>
>My configuration is a follows:
>
> | eth0 -------------->
>Ububntu | eth1 --------------> Swith ------------> Other computer
>
>Scenario:
>• change the bond mode to active/backup
>• unplug some of the cable
>• plug-in the unplugged cable
>• change bond mode to round robin
>
>I can see that only one eth1 is sending data. When I unplug it the ping stops.
>
>Is it a bug or some mis-configuration?
>
>In the kernel ( /drivers/net/bond/bond_main.c).
>In the function ‘bond_xmit_roundrobin
>’
>The code check if the bond is active via
>‘bond_is_active_slave(slave)’ Function call.
>Which actually checks if the slave is backup or active
>What is the meaning of backup in round robin?
>Correct me if I wrong but in round robin every slave should send a
>packet, regardless of being active or backup.
So from looking at the code, it seems that the actual problem is
that when transitioning to round-robin mode, one or more slaves can
remain marked as "backup," and in round-robin mode, that won't ever
change. We could probably work around that by removing the "is_active"
test (essentially declaring that "is_active" is only valid in
active-backup mode). That might produce a few odd messages here and
there (when removing a slave or during a link failure, for example).
From inspection, the bond_xmit_xor function likely has this same
problem.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: Bonding problem
From: Andy Gospodarek @ 2011-08-08 17:31 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Andy Gospodarek, Eduard Sinelnikov, netdev
In-Reply-To: <26478.1312823165@death>
On Mon, Aug 08, 2011 at 10:06:05AM -0700, Jay Vosburgh wrote:
>
> Andy Gospodarek <andy@greyhouse.net> wrote:
>
> >On Sun, Aug 07, 2011 at 03:00:30PM +0300, Eduard Sinelnikov wrote:
> >> Hi,
> >>
> >> In the kernel 2.6.39.3 ( /drivers/net/bond/bond_main.c).
> >> In the function ‘bond_xmit_roundrobin’
> >> The code check if the bond is active via
> >> ‘bond_is_active_slave(slave)’ Function call.
> >> Which actually checks if the slave is backup or active
> >> What is the meaning of slave being backup in round robin mode?
> >> Correct me if I wrong but in round robin every slave should send a
> >> packet, regardless of being active or backup.
> >>
> >> Thank you,
> >> Eduard
> >
> >There probably is not a compelling reason to continue to have it. There
> >may be a reason historically, but I'm not aware what that might be at
> >this point. For modes other than active-backup, the value of
> >slave->link and slave->backup should always contain a value that
> >indicates the slave is up and available for transmit.
>
> If you read Eduard's other posts regarding this, the actual
> issue is that when changing from another mode into round-robin,
> occasionally slaves will still be marked as "backup" and won't be used:
>
I did notice that one after I sent this first response.
> >Date: Mon, 8 Aug 2011 11:16:39 +0300
> >Subject: On line Bonding configuration change fails
> >From: Eduard Sinelnikov <eduard.sinelnikov@gmail.com>
> >To: netdev@vger.kernel.org
> >Sender: netdev-owner@vger.kernel.org
> >
> >Hi,
> >
> >My configuration is a follows:
> >
> > | eth0 -------------->
> >Ububntu | eth1 --------------> Swith ------------> Other computer
> >
> >Scenario:
> >• change the bond mode to active/backup
> >• unplug some of the cable
> >• plug-in the unplugged cable
> >• change bond mode to round robin
> >
> >I can see that only one eth1 is sending data. When I unplug it the ping stops.
> >
> >Is it a bug or some mis-configuration?
> >
> >In the kernel ( /drivers/net/bond/bond_main.c).
> >In the function ‘bond_xmit_roundrobin
> >’
> >The code check if the bond is active via
> >‘bond_is_active_slave(slave)’ Function call.
> >Which actually checks if the slave is backup or active
> >What is the meaning of backup in round robin?
> >Correct me if I wrong but in round robin every slave should send a
> >packet, regardless of being active or backup.
>
> So from looking at the code, it seems that the actual problem is
> that when transitioning to round-robin mode, one or more slaves can
> remain marked as "backup," and in round-robin mode, that won't ever
> change. We could probably work around that by removing the "is_active"
> test (essentially declaring that "is_active" is only valid in
> active-backup mode). That might produce a few odd messages here and
> there (when removing a slave or during a link failure, for example).
>
> From inspection, the bond_xmit_xor function likely has this same
> problem.
>
Agreed.
> -J
>
> ---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [BUG] 3.0-rc1 Bridge not forwarding unicast packages
From: Michael Guntsche @ 2011-08-08 17:42 UTC (permalink / raw)
To: netdev, linux-kernel
Hi list,
I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
testing. On a first look everything seemed to work fine, but when I
tried to connect via openvpn to my internal network (tap0 being bridged
with the internal network) I noticed that I was not able to access the
server on my internal network. I could access the bridge (which is
acting as the openvpn server as well) just fine though.
To debug this I ran tcpdump on the openvpn client and started a ping to the
internal network. I could see the ARP requests being answered.
19:23:49.247846 ARP, Request who-has 192.168.42.127 tell 192.168.42.96,
length 28
19:23:49.287752 ARP, Reply 192.168.42.127 is-at 00:13:d4:4f:a2:dc,
length 46
in this case .127 is the server on the internal net and .96 the openvpn
client, but the icmp request did not arrive on the server.
The strange thing I noticed was that I could see broadcasts packages
from the server on the client
19:23:28.135185 IP 192.168.42.127.631 > 192.168.42.255.631: UDP, length
187
19:23:29.470975 IP 192.168.42.96.5353 > 224.0.0.251.5353: .......
but no icmp packages arrived on the server side.
brctl showmacs lan
port no mac addr is local? ageing timer
1 00:0c:42:28:de:4e yes 0.00
2 00:0c:42:61:7f:f2 yes 0.00
1 00:13:d4:4f:a2:dc no 0.00 <---- server on the lan side
3 8e:22:41:d9:95:23 yes 0.00
3 b6:e1:e3:06:c9:1a no 5.00 <---- client connected via tap0
Reverting to 3.0 solves the problem for me. I tried just reverting the bridge code on the server to the 3.0 version to make sure that it is really Bridge related, but there are too many changes outside the bridge tree so compilation fails for me.
If you need more information, please to not hesitate to conact me.
Kind regards,
Michael Guntsche
^ permalink raw reply
* Re: [BUG] 3.0-rc1 Bridge not forwarding unicast packages
From: Stephen Hemminger @ 2011-08-08 17:48 UTC (permalink / raw)
To: Michael Guntsche; +Cc: netdev, linux-kernel
In-Reply-To: <20110808192646@it-loops.com>
On Mon, 8 Aug 2011 19:42:19 +0200
Michael Guntsche <mike@it-loops.com> wrote:
> Hi list,
>
> I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
> testing. On a first look everything seemed to work fine, but when I
> tried to connect via openvpn to my internal network (tap0 being bridged
> with the internal network) I noticed that I was not able to access the
> server on my internal network. I could access the bridge (which is
> acting as the openvpn server as well) just fine though.
> To debug this I ran tcpdump on the openvpn client and started a ping to the
> internal network. I could see the ARP requests being answered.
>
> 19:23:49.247846 ARP, Request who-has 192.168.42.127 tell 192.168.42.96,
> length 28
> 19:23:49.287752 ARP, Reply 192.168.42.127 is-at 00:13:d4:4f:a2:dc,
> length 46
>
> in this case .127 is the server on the internal net and .96 the openvpn
> client, but the icmp request did not arrive on the server.
> The strange thing I noticed was that I could see broadcasts packages
> from the server on the client
>
> 19:23:28.135185 IP 192.168.42.127.631 > 192.168.42.255.631: UDP, length
> 187
> 19:23:29.470975 IP 192.168.42.96.5353 > 224.0.0.251.5353: .......
>
> but no icmp packages arrived on the server side.
>
>
> brctl showmacs lan
> port no mac addr is local? ageing timer
> 1 00:0c:42:28:de:4e yes 0.00
> 2 00:0c:42:61:7f:f2 yes 0.00
> 1 00:13:d4:4f:a2:dc no 0.00 <---- server on the lan side
> 3 8e:22:41:d9:95:23 yes 0.00
> 3 b6:e1:e3:06:c9:1a no 5.00 <---- client connected via tap0
>
> Reverting to 3.0 solves the problem for me. I tried just reverting the bridge code on the server to the 3.0 version to make sure that it is really Bridge related, but there are too many changes outside the bridge tree so compilation fails for me.
>
> If you need more information, please to not hesitate to conact me.
>
> Kind regards,
> Michael Guntsche
Do you have spanning tree enabled?
If so you may have a packet loop and now it is being detected.
^ permalink raw reply
* Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits
From: Tom Herbert @ 2011-08-08 17:51 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev
In-Reply-To: <20110808084016.063a0699@nehalam.ftrdhcpuser.net>
On Mon, Aug 8, 2011 at 8:40 AM, Stephen Hemminger <shemminger@vyatta.com> wrote:
> On Sun, 7 Aug 2011 21:43:13 -0700 (PDT)
> Tom Herbert <therbert@google.com> wrote:
>
>> netdev_tx_completed_queue: Called at end of transmit completion
>> to inform stack of number of bytes and packets processed.
>> netdev_tx_sent_queue: Called to inform stack when packets are
>> queued.
>
> Couldn't these be done for the device in the existing qdisc infra
> structure (or dev_start_xmit). Alternatively, rename ndo_start_xmit
> to something else and make all the callers use the wrapper.
>
> Changing all the drivers for something that the driver has no real
> need to care about seems like incorrect object design.
>
The netdev_tx_completed_queue is needed to inform the stack of number
of packets and bytes completed in an execution of transmit completion
(epic). I don't see a way to get that information outside of the
driver.
Tom
^ permalink raw reply
* Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits
From: Stephen Hemminger @ 2011-08-08 17:55 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <CA+mtBx_vgsH+uHLi6p80E8CEhU7SHXY=Fw1Z-W2OFWy44LP-ig@mail.gmail.com>
On Mon, 8 Aug 2011 10:51:06 -0700
Tom Herbert <therbert@google.com> wrote:
> On Mon, Aug 8, 2011 at 8:40 AM, Stephen Hemminger <shemminger@vyatta.com> wrote:
> > On Sun, 7 Aug 2011 21:43:13 -0700 (PDT)
> > Tom Herbert <therbert@google.com> wrote:
> >
> >> netdev_tx_completed_queue: Called at end of transmit completion
> >> to inform stack of number of bytes and packets processed.
> >> netdev_tx_sent_queue: Called to inform stack when packets are
> >> queued.
> >
> > Couldn't these be done for the device in the existing qdisc infra
> > structure (or dev_start_xmit). Alternatively, rename ndo_start_xmit
> > to something else and make all the callers use the wrapper.
> >
> > Changing all the drivers for something that the driver has no real
> > need to care about seems like incorrect object design.
> >
> The netdev_tx_completed_queue is needed to inform the stack of number
> of packets and bytes completed in an execution of transmit completion
> (epic). I don't see a way to get that information outside of the
> driver.
>
> Tom
Since transmit completion means calling dev_kfree_skb() why not account
there? You could add some info to netdev if necessary to get compile
the statistics.
I just hate driver api complexity growth.
^ permalink raw reply
* Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits
From: Tom Herbert @ 2011-08-08 17:56 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev
In-Reply-To: <20110808105529.4c8c52e1@nehalam.ftrdhcpuser.net>
On Mon, Aug 8, 2011 at 10:55 AM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Mon, 8 Aug 2011 10:51:06 -0700
> Tom Herbert <therbert@google.com> wrote:
>
>> On Mon, Aug 8, 2011 at 8:40 AM, Stephen Hemminger <shemminger@vyatta.com> wrote:
>> > On Sun, 7 Aug 2011 21:43:13 -0700 (PDT)
>> > Tom Herbert <therbert@google.com> wrote:
>> >
>> >> netdev_tx_completed_queue: Called at end of transmit completion
>> >> to inform stack of number of bytes and packets processed.
>> >> netdev_tx_sent_queue: Called to inform stack when packets are
>> >> queued.
>> >
>> > Couldn't these be done for the device in the existing qdisc infra
>> > structure (or dev_start_xmit). Alternatively, rename ndo_start_xmit
>> > to something else and make all the callers use the wrapper.
>> >
>> > Changing all the drivers for something that the driver has no real
>> > need to care about seems like incorrect object design.
>> >
>> The netdev_tx_completed_queue is needed to inform the stack of number
>> of packets and bytes completed in an execution of transmit completion
>> (epic). I don't see a way to get that information outside of the
>> driver.
>>
>> Tom
>
> Since transmit completion means calling dev_kfree_skb() why not account
> there? You could add some info to netdev if necessary to get compile
> the statistics.
>
> I just hate driver api complexity growth.
>
>
^ permalink raw reply
* Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits
From: Tom Herbert @ 2011-08-08 18:01 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev
In-Reply-To: <20110808105529.4c8c52e1@nehalam.ftrdhcpuser.net>
> Since transmit completion means calling dev_kfree_skb() why not account
> there? You could add some info to netdev if necessary to get compile
> the statistics.
>
The algorithm depends on knowing the total number of packets competed
in a single execution of transmit completion (epic based). We only
want to recalculate the limits once per completion, which happens when
the completion function is called.
> I just hate driver api complexity growth.
>
>
^ permalink raw reply
* Re: [BUG] 3.0-rc1 Bridge not forwarding unicast packages
From: Michael Guntsche @ 2011-08-08 18:02 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, linux-kernel
In-Reply-To: <20110808104803.2762dbf7@nehalam.ftrdhcpuser.net>
On 08 Aug 11 10:48, Stephen Hemminger wrote:
> On Mon, 8 Aug 2011 19:42:19 +0200
> Michael Guntsche <mike@it-loops.com> wrote:
>
> > Hi list,
> >
> > I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
> > testing. On a first look everything seemed to work fine, but when I
> > tried to connect via openvpn to my internal network (tap0 being bridged
> > with the internal network) I noticed that I was not able to access the
> > server on my internal network. I could access the bridge (which is
> > acting as the openvpn server as well) just fine though.
> > To debug this I ran tcpdump on the openvpn client and started a ping to the
> > internal network. I could see the ARP requests being answered.
> >
> > 19:23:49.247846 ARP, Request who-has 192.168.42.127 tell 192.168.42.96,
> > length 28
> > 19:23:49.287752 ARP, Reply 192.168.42.127 is-at 00:13:d4:4f:a2:dc,
> > length 46
> >
> > in this case .127 is the server on the internal net and .96 the openvpn
> > client, but the icmp request did not arrive on the server.
> > The strange thing I noticed was that I could see broadcasts packages
> > from the server on the client
> >
> > 19:23:28.135185 IP 192.168.42.127.631 > 192.168.42.255.631: UDP, length
> > 187
> > 19:23:29.470975 IP 192.168.42.96.5353 > 224.0.0.251.5353: .......
> >
> > but no icmp packages arrived on the server side.
> >
> >
> > brctl showmacs lan
> > port no mac addr is local? ageing timer
> > 1 00:0c:42:28:de:4e yes 0.00
> > 2 00:0c:42:61:7f:f2 yes 0.00
> > 1 00:13:d4:4f:a2:dc no 0.00 <---- server on the lan side
> > 3 8e:22:41:d9:95:23 yes 0.00
> > 3 b6:e1:e3:06:c9:1a no 5.00 <---- client connected via tap0
> >
> > Reverting to 3.0 solves the problem for me. I tried just reverting the bridge code on the server to the 3.0 version to make sure that it is really Bridge related, but there are too many changes outside the bridge tree so compilation fails for me.
> >
> > If you need more information, please to not hesitate to conact me.
> >
> > Kind regards,
> > Michael Guntsche
>
> Do you have spanning tree enabled?
> If so you may have a packet loop and now it is being detected.
No STP is not enabled
brctl show lan
bridge name bridge id STP enabled interfaces
lan 8000.000c4228de4e no lan_wire
tap0
wlan0
No ebtables rules either just checked that.
Is there a way to revert just the bridge code to the 3.0 version so i can make sure it is really the bridge code, and not something else?
Kind regards,
Mike
PS: And of COURSE the subject line should be 3.1-rc1!!!! Sorry
^ permalink raw reply
* Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits
From: Stephen Hemminger @ 2011-08-08 18:19 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <CA+mtBx_bdCGvR+xBMq9px0vOV6a6kFn0wYyJH26+CdSPLtvgfw@mail.gmail.com>
On Mon, 8 Aug 2011 11:01:57 -0700
Tom Herbert <therbert@google.com> wrote:
> > Since transmit completion means calling dev_kfree_skb() why not account
> > there? You could add some info to netdev if necessary to get compile
> > the statistics.
> >
> The algorithm depends on knowing the total number of packets competed
> in a single execution of transmit completion (epic based). We only
> want to recalculate the limits once per completion, which happens when
> the completion function is called.
So just add some stats to netdev and count the number of dev_kfree_skb
calls and do your work at napi complete.
^ permalink raw reply
* Re: [BUG] 3.0-rc1 Bridge not forwarding unicast packages
From: Stephen Hemminger @ 2011-08-08 18:20 UTC (permalink / raw)
To: Michael Guntsche; +Cc: netdev, linux-kernel
In-Reply-To: <20110808195930@it-loops.com>
On Mon, 8 Aug 2011 20:02:52 +0200
Michael Guntsche <mike@it-loops.com> wrote:
> On 08 Aug 11 10:48, Stephen Hemminger wrote:
> > On Mon, 8 Aug 2011 19:42:19 +0200
> > Michael Guntsche <mike@it-loops.com> wrote:
> >
> > > Hi list,
> > >
> > > I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
> > > testing. On a first look everything seemed to work fine, but when I
> > > tried to connect via openvpn to my internal network (tap0 being bridged
> > > with the internal network) I noticed that I was not able to access the
> > > server on my internal network. I could access the bridge (which is
> > > acting as the openvpn server as well) just fine though.
> > > To debug this I ran tcpdump on the openvpn client and started a ping to the
> > > internal network. I could see the ARP requests being answered.
> > >
> > > 19:23:49.247846 ARP, Request who-has 192.168.42.127 tell 192.168.42.96,
> > > length 28
> > > 19:23:49.287752 ARP, Reply 192.168.42.127 is-at 00:13:d4:4f:a2:dc,
> > > length 46
> > >
> > > in this case .127 is the server on the internal net and .96 the openvpn
> > > client, but the icmp request did not arrive on the server.
> > > The strange thing I noticed was that I could see broadcasts packages
> > > from the server on the client
> > >
> > > 19:23:28.135185 IP 192.168.42.127.631 > 192.168.42.255.631: UDP, length
> > > 187
> > > 19:23:29.470975 IP 192.168.42.96.5353 > 224.0.0.251.5353: .......
> > >
> > > but no icmp packages arrived on the server side.
> > >
> > >
> > > brctl showmacs lan
> > > port no mac addr is local? ageing timer
> > > 1 00:0c:42:28:de:4e yes 0.00
> > > 2 00:0c:42:61:7f:f2 yes 0.00
> > > 1 00:13:d4:4f:a2:dc no 0.00 <---- server on the lan side
> > > 3 8e:22:41:d9:95:23 yes 0.00
> > > 3 b6:e1:e3:06:c9:1a no 5.00 <---- client connected via tap0
> > >
> > > Reverting to 3.0 solves the problem for me. I tried just reverting the bridge code on the server to the 3.0 version to make sure that it is really Bridge related, but there are too many changes outside the bridge tree so compilation fails for me.
> > >
> > > If you need more information, please to not hesitate to conact me.
> > >
> > > Kind regards,
> > > Michael Guntsche
> >
> > Do you have spanning tree enabled?
> > If so you may have a packet loop and now it is being detected.
> No STP is not enabled
>
> brctl show lan
> bridge name bridge id STP enabled interfaces
> lan 8000.000c4228de4e no lan_wire
> tap0
> wlan0
>
> No ebtables rules either just checked that.
> Is there a way to revert just the bridge code to the 3.0 version so i can make sure it is really the bridge code, and not something else?
>
You need to use git bisect, it is not necessarily the bridge code.
Could be vpn, tap, wlan or lots of other things.
^ permalink raw reply
* Re: [PATCH 11/12] headers, scc: Add missing #include to <linux/scc.h>
From: Ben Hutchings @ 2011-08-08 18:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Joerg Reuter, Klaus Kudielka, linux-hams
In-Reply-To: <1312809869.2591.1151.camel@deadeye>
On Mon, Aug 08, 2011 at 02:24:29PM +0100, Ben Hutchings wrote:
> <linux/scc.h> uses SIOCDEVPRIVATE, defined in <linux/sockios.h>.
Unfortunately SIOCDEVPRIVATE is also defined elsewhere by glibc,
so including <linux/sockios.h> can result in duplicate definitions.
So I don't think we can make this change.
Ben.
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> This file isn't listed in MAINTAINERS but appears to be associated with
> one of the hamradio drivers; please could one of the hams claim it?
>
> Ben.
>
> include/linux/scc.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/scc.h b/include/linux/scc.h
> index 3495bd9..d5916e5 100644
> --- a/include/linux/scc.h
> +++ b/include/linux/scc.h
> @@ -3,6 +3,7 @@
> #ifndef _SCC_H
> #define _SCC_H
>
> +#include <linux/sockios.h>
>
> /* selection of hardware types */
>
> --
> 1.7.5.4
>
>
>
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox