* [PATCHv3 5/9] net: fec: improve access to quirk flags by copying them into fec_enet_private struct
From: Lothar Waßmann @ 2014-10-28 13:23 UTC (permalink / raw)
To: netdev
Cc: Fabio Estevam, Frank Li, linux-kernel, Russell King,
David S. Miller, linux-arm-kernel, Lothar Waßmann
In-Reply-To: <1414502584-10583-1-git-send-email-LW@KARO-electronics.de>
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
---
drivers/net/ethernet/freescale/fec.h | 1 +
drivers/net/ethernet/freescale/fec_main.c | 106 +++++++++++------------------
2 files changed, 39 insertions(+), 68 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index 1418813..7aa9388 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -504,6 +504,7 @@ struct fec_enet_private {
int irq[FEC_IRQ_NUM];
bool bufdesc_ex;
int pause_flag;
+ u32 quirks;
struct napi_struct napi;
int csum_flags;
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index bb006e1..5c1d517 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -351,8 +351,6 @@ fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq,
struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
- const struct platform_device_id *id_entry =
- platform_get_device_id(fep->pdev);
struct bufdesc *bdp = txq->cur_tx;
struct bufdesc_ex *ebdp;
int nr_frags = skb_shinfo(skb)->nr_frags;
@@ -388,7 +386,7 @@ fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq,
}
if (fep->bufdesc_ex) {
- if (id_entry->driver_data & FEC_QUIRK_HAS_AVB)
+ if (fep->quirks & FEC_QUIRK_HAS_AVB)
estatus |= FEC_TX_BD_FTYPE(queue);
if (skb->ip_summed == CHECKSUM_PARTIAL)
estatus |= BD_ENET_TX_PINS | BD_ENET_TX_IINS;
@@ -400,11 +398,11 @@ fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq,
index = fec_enet_get_bd_index(txq->tx_bd_base, bdp, fep);
if (((unsigned long) bufaddr) & fep->tx_align ||
- id_entry->driver_data & FEC_QUIRK_SWAP_FRAME) {
+ fep->quirks & FEC_QUIRK_SWAP_FRAME) {
memcpy(txq->tx_bounce[index], bufaddr, frag_len);
bufaddr = txq->tx_bounce[index];
- if (id_entry->driver_data & FEC_QUIRK_SWAP_FRAME)
+ if (fep->quirks & FEC_QUIRK_SWAP_FRAME)
swap_buffer(bufaddr, frag_len);
}
@@ -440,8 +438,6 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
struct sk_buff *skb, struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
- const struct platform_device_id *id_entry =
- platform_get_device_id(fep->pdev);
int nr_frags = skb_shinfo(skb)->nr_frags;
struct bufdesc *bdp, *last_bdp;
void *bufaddr;
@@ -480,11 +476,11 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
queue = skb_get_queue_mapping(skb);
index = fec_enet_get_bd_index(txq->tx_bd_base, bdp, fep);
if (((unsigned long) bufaddr) & fep->tx_align ||
- id_entry->driver_data & FEC_QUIRK_SWAP_FRAME) {
+ fep->quirks & FEC_QUIRK_SWAP_FRAME) {
memcpy(txq->tx_bounce[index], skb->data, buflen);
bufaddr = txq->tx_bounce[index];
- if (id_entry->driver_data & FEC_QUIRK_SWAP_FRAME)
+ if (fep->quirks & FEC_QUIRK_SWAP_FRAME)
swap_buffer(bufaddr, buflen);
}
@@ -519,7 +515,7 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
fep->hwts_tx_en))
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
- if (id_entry->driver_data & FEC_QUIRK_HAS_AVB)
+ if (fep->quirks & FEC_QUIRK_HAS_AVB)
estatus |= FEC_TX_BD_FTYPE(queue);
if (skb->ip_summed == CHECKSUM_PARTIAL)
@@ -563,8 +559,6 @@ fec_enet_txq_put_data_tso(struct fec_enet_priv_tx_q *txq, struct sk_buff *skb,
int size, bool last_tcp, bool is_last)
{
struct fec_enet_private *fep = netdev_priv(ndev);
- const struct platform_device_id *id_entry =
- platform_get_device_id(fep->pdev);
struct bufdesc_ex *ebdp = container_of(bdp, struct bufdesc_ex, desc);
unsigned short queue = skb_get_queue_mapping(skb);
unsigned short status;
@@ -577,11 +571,11 @@ fec_enet_txq_put_data_tso(struct fec_enet_priv_tx_q *txq, struct sk_buff *skb,
status |= (BD_ENET_TX_TC | BD_ENET_TX_READY);
if (((unsigned long) data) & fep->tx_align ||
- id_entry->driver_data & FEC_QUIRK_SWAP_FRAME) {
+ fep->quirks & FEC_QUIRK_SWAP_FRAME) {
memcpy(txq->tx_bounce[index], data, size);
data = txq->tx_bounce[index];
- if (id_entry->driver_data & FEC_QUIRK_SWAP_FRAME)
+ if (fep->quirks & FEC_QUIRK_SWAP_FRAME)
swap_buffer(data, size);
}
@@ -597,7 +591,7 @@ fec_enet_txq_put_data_tso(struct fec_enet_priv_tx_q *txq, struct sk_buff *skb,
bdp->cbd_bufaddr = addr;
if (fep->bufdesc_ex) {
- if (id_entry->driver_data & FEC_QUIRK_HAS_AVB)
+ if (fep->quirks & FEC_QUIRK_HAS_AVB)
estatus |= FEC_TX_BD_FTYPE(queue);
if (skb->ip_summed == CHECKSUM_PARTIAL)
estatus |= BD_ENET_TX_PINS | BD_ENET_TX_IINS;
@@ -625,8 +619,6 @@ fec_enet_txq_put_hdr_tso(struct fec_enet_priv_tx_q *txq,
struct bufdesc *bdp, int index)
{
struct fec_enet_private *fep = netdev_priv(ndev);
- const struct platform_device_id *id_entry =
- platform_get_device_id(fep->pdev);
int hdr_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
struct bufdesc_ex *ebdp = container_of(bdp, struct bufdesc_ex, desc);
unsigned short queue = skb_get_queue_mapping(skb);
@@ -642,11 +634,11 @@ fec_enet_txq_put_hdr_tso(struct fec_enet_priv_tx_q *txq,
bufaddr = txq->tso_hdrs + index * TSO_HEADER_SIZE;
dmabuf = txq->tso_hdrs_dma + index * TSO_HEADER_SIZE;
if (((unsigned long)bufaddr) & fep->tx_align ||
- id_entry->driver_data & FEC_QUIRK_SWAP_FRAME) {
+ fep->quirks & FEC_QUIRK_SWAP_FRAME) {
memcpy(txq->tx_bounce[index], skb->data, hdr_len);
bufaddr = txq->tx_bounce[index];
- if (id_entry->driver_data & FEC_QUIRK_SWAP_FRAME)
+ if (fep->quirks & FEC_QUIRK_SWAP_FRAME)
swap_buffer(bufaddr, hdr_len);
dmabuf = dma_map_single(&fep->pdev->dev, bufaddr,
@@ -663,7 +655,7 @@ fec_enet_txq_put_hdr_tso(struct fec_enet_priv_tx_q *txq,
bdp->cbd_datlen = hdr_len;
if (fep->bufdesc_ex) {
- if (id_entry->driver_data & FEC_QUIRK_HAS_AVB)
+ if (fep->quirks & FEC_QUIRK_HAS_AVB)
estatus |= FEC_TX_BD_FTYPE(queue);
if (skb->ip_summed == CHECKSUM_PARTIAL)
estatus |= BD_ENET_TX_PINS | BD_ENET_TX_IINS;
@@ -688,8 +680,6 @@ static int fec_enet_txq_submit_tso(struct fec_enet_priv_tx_q *txq,
struct tso_t tso;
unsigned int index = 0;
int ret;
- const struct platform_device_id *id_entry =
- platform_get_device_id(fep->pdev);
if (tso_count_descs(skb) >= fec_enet_get_free_txdesc_num(fep, txq)) {
dev_kfree_skb_any(skb);
@@ -751,7 +741,7 @@ static int fec_enet_txq_submit_tso(struct fec_enet_priv_tx_q *txq,
txq->cur_tx = bdp;
/* Trigger transmission start */
- if (!(id_entry->driver_data & FEC_QUIRK_ERR007885) ||
+ if (!(fep->quirks & FEC_QUIRK_ERR007885) ||
!readl(fep->hwp + FEC_X_DES_ACTIVE(queue)) ||
!readl(fep->hwp + FEC_X_DES_ACTIVE(queue)) ||
!readl(fep->hwp + FEC_X_DES_ACTIVE(queue)) ||
@@ -914,8 +904,6 @@ static void
fec_restart(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
- const struct platform_device_id *id_entry =
- platform_get_device_id(fep->pdev);
u32 val;
u32 temp_mac[2];
u32 rcntl = OPT_FRAME_SIZE | 0x04;
@@ -925,7 +913,7 @@ fec_restart(struct net_device *ndev)
* For i.MX6SX SOC, enet use AXI bus, we use disable MAC
* instead of reset MAC itself.
*/
- if (id_entry && id_entry->driver_data & FEC_QUIRK_HAS_AVB) {
+ if (fep->quirks & FEC_QUIRK_HAS_AVB) {
writel(0, fep->hwp + FEC_ECNTRL);
} else {
writel(1, fep->hwp + FEC_ECNTRL);
@@ -936,7 +924,7 @@ fec_restart(struct net_device *ndev)
* enet-mac reset will reset mac address registers too,
* so need to reconfigure it.
*/
- if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
+ if (fep->quirks & FEC_QUIRK_ENET_MAC) {
memcpy(&temp_mac, ndev->dev_addr, ETH_ALEN);
writel(cpu_to_be32(temp_mac[0]), fep->hwp + FEC_ADDR_LOW);
writel(cpu_to_be32(temp_mac[1]), fep->hwp + FEC_ADDR_HIGH);
@@ -982,7 +970,7 @@ fec_restart(struct net_device *ndev)
* The phy interface and speed need to get configured
* differently on enet-mac.
*/
- if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
+ if (fep->quirks & FEC_QUIRK_ENET_MAC) {
/* Enable flow control and length check */
rcntl |= 0x40000000 | 0x00000020;
@@ -1005,7 +993,7 @@ fec_restart(struct net_device *ndev)
}
} else {
#ifdef FEC_MIIGSK_ENR
- if (id_entry->driver_data & FEC_QUIRK_USE_GASKET) {
+ if (fep->quirks & FEC_QUIRK_USE_GASKET) {
u32 cfgr;
/* disable the gasket and wait */
writel(0, fep->hwp + FEC_MIIGSK_ENR);
@@ -1058,7 +1046,7 @@ fec_restart(struct net_device *ndev)
writel(0, fep->hwp + FEC_HASH_TABLE_LOW);
#endif
- if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
+ if (fep->quirks & FEC_QUIRK_ENET_MAC) {
/* enable ENET endian swap */
ecntl |= (1 << 8);
/* enable ENET store and forward mode */
@@ -1092,8 +1080,6 @@ static void
fec_stop(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
- const struct platform_device_id *id_entry =
- platform_get_device_id(fep->pdev);
u32 rmii_mode = readl(fep->hwp + FEC_R_CNTRL) & (1 << 8);
/* We cannot expect a graceful transmit stop without link !!! */
@@ -1108,7 +1094,7 @@ fec_stop(struct net_device *ndev)
* For i.MX6SX SOC, enet use AXI bus, we use disable MAC
* instead of reset MAC itself.
*/
- if (id_entry && id_entry->driver_data & FEC_QUIRK_HAS_AVB) {
+ if (fep->quirks & FEC_QUIRK_HAS_AVB) {
writel(0, fep->hwp + FEC_ECNTRL);
} else {
writel(1, fep->hwp + FEC_ECNTRL);
@@ -1118,7 +1104,7 @@ fec_stop(struct net_device *ndev)
writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
/* We have to keep ENET enabled to have MII interrupt stay working */
- if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
+ if (fep->quirks & FEC_QUIRK_ENET_MAC) {
writel(2, fep->hwp + FEC_ECNTRL);
writel(rmii_mode, fep->hwp + FEC_R_CNTRL);
}
@@ -1337,8 +1323,6 @@ static int
fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
{
struct fec_enet_private *fep = netdev_priv(ndev);
- const struct platform_device_id *id_entry =
- platform_get_device_id(fep->pdev);
struct fec_enet_priv_rx_q *rxq;
struct bufdesc *bdp;
unsigned short status;
@@ -1430,7 +1414,7 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
prefetch(skb->data - NET_IP_ALIGN);
skb_put(skb, pkt_len - 4);
data = skb->data;
- if (id_entry->driver_data & FEC_QUIRK_SWAP_FRAME)
+ if (fep->quirks & FEC_QUIRK_SWAP_FRAME)
swap_buffer(data, pkt_len);
/* Extract the enhanced buffer descriptor */
@@ -1865,8 +1849,6 @@ failed_clk_ipg:
static int fec_enet_mii_probe(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
- const struct platform_device_id *id_entry =
- platform_get_device_id(fep->pdev);
struct phy_device *phy_dev = NULL;
char mdio_bus_id[MII_BUS_ID_SIZE];
char phy_name[MII_BUS_ID_SIZE + 3];
@@ -1912,7 +1894,7 @@ static int fec_enet_mii_probe(struct net_device *ndev)
}
/* mask with MAC supported features */
- if (id_entry->driver_data & FEC_QUIRK_HAS_GBIT) {
+ if (fep->quirks & FEC_QUIRK_HAS_GBIT) {
phy_dev->supported &= PHY_GBIT_FEATURES;
phy_dev->supported &= ~SUPPORTED_1000baseT_Half;
#if !defined(CONFIG_M5272)
@@ -1940,8 +1922,6 @@ static int fec_enet_mii_init(struct platform_device *pdev)
static struct mii_bus *fec0_mii_bus;
struct net_device *ndev = platform_get_drvdata(pdev);
struct fec_enet_private *fep = netdev_priv(ndev);
- const struct platform_device_id *id_entry =
- platform_get_device_id(fep->pdev);
struct device_node *node;
int err = -ENXIO, i;
@@ -1961,7 +1941,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
* mdio interface in board design, and need to be configured by
* fec0 mii_bus.
*/
- if ((id_entry->driver_data & FEC_QUIRK_ENET_MAC) && fep->dev_id > 0) {
+ if ((fep->quirks & FEC_QUIRK_ENET_MAC) && fep->dev_id > 0) {
/* fec1 uses fec0 mii_bus */
if (mii_cnt && fec0_mii_bus) {
fep->mii_bus = fec0_mii_bus;
@@ -1982,7 +1962,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
* document.
*/
fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk_ipg), 5000000);
- if (id_entry->driver_data & FEC_QUIRK_ENET_MAC)
+ if (fep->quirks & FEC_QUIRK_ENET_MAC)
fep->phy_speed--;
fep->phy_speed <<= 1;
writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
@@ -2024,7 +2004,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
mii_cnt++;
/* save fec0 mii_bus */
- if (id_entry->driver_data & FEC_QUIRK_ENET_MAC)
+ if (fep->quirks & FEC_QUIRK_ENET_MAC)
fec0_mii_bus = fep->mii_bus;
return 0;
@@ -2293,11 +2273,9 @@ static int fec_enet_us_to_itr_clock(struct net_device *ndev, int us)
static void fec_enet_itr_coal_set(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
- const struct platform_device_id *id_entry =
- platform_get_device_id(fep->pdev);
int rx_itr, tx_itr;
- if (!(id_entry->driver_data & FEC_QUIRK_HAS_AVB))
+ if (!(fep->quirks & FEC_QUIRK_HAS_AVB))
return;
/* Must be greater than zero to avoid unpredictable behavior */
@@ -2332,10 +2310,8 @@ static int
fec_enet_get_coalesce(struct net_device *ndev, struct ethtool_coalesce *ec)
{
struct fec_enet_private *fep = netdev_priv(ndev);
- const struct platform_device_id *id_entry =
- platform_get_device_id(fep->pdev);
- if (!(id_entry->driver_data & FEC_QUIRK_HAS_AVB))
+ if (!(fep->quirks & FEC_QUIRK_HAS_AVB))
return -EOPNOTSUPP;
ec->rx_coalesce_usecs = fep->rx_time_itr;
@@ -2351,12 +2327,9 @@ static int
fec_enet_set_coalesce(struct net_device *ndev, struct ethtool_coalesce *ec)
{
struct fec_enet_private *fep = netdev_priv(ndev);
- const struct platform_device_id *id_entry =
- platform_get_device_id(fep->pdev);
-
unsigned int cycle;
- if (!(id_entry->driver_data & FEC_QUIRK_HAS_AVB))
+ if (!(fep->quirks & FEC_QUIRK_HAS_AVB))
return -EOPNOTSUPP;
if (ec->rx_max_coalesced_frames > 255) {
@@ -2936,8 +2909,6 @@ static const struct net_device_ops fec_netdev_ops = {
static int fec_enet_init(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
- const struct platform_device_id *id_entry =
- platform_get_device_id(fep->pdev);
struct fec_enet_priv_tx_q *txq;
struct fec_enet_priv_rx_q *rxq;
struct bufdesc *cbd_base;
@@ -3016,11 +2987,11 @@ static int fec_enet_init(struct net_device *ndev)
writel(FEC_RX_DISABLED_IMASK, fep->hwp + FEC_IMASK);
netif_napi_add(ndev, &fep->napi, fec_enet_rx_napi, NAPI_POLL_WEIGHT);
- if (id_entry->driver_data & FEC_QUIRK_HAS_VLAN)
+ if (fep->quirks & FEC_QUIRK_HAS_VLAN)
/* enable hw VLAN support */
ndev->features |= NETIF_F_HW_VLAN_CTAG_RX;
- if (id_entry->driver_data & FEC_QUIRK_HAS_CSUM) {
+ if (fep->quirks & FEC_QUIRK_HAS_CSUM) {
ndev->gso_max_segs = FEC_MAX_TSO_SEGS;
/* enable hw accelerator */
@@ -3029,7 +3000,7 @@ static int fec_enet_init(struct net_device *ndev)
fep->csum_flags |= FLAG_RX_CSUM_ENABLED;
}
- if (id_entry->driver_data & FEC_QUIRK_HAS_AVB) {
+ if (fep->quirks & FEC_QUIRK_HAS_AVB) {
fep->tx_align = 0;
fep->rx_align = 0x3f;
}
@@ -3129,10 +3100,6 @@ fec_probe(struct platform_device *pdev)
int num_tx_qs;
int num_rx_qs;
- of_id = of_match_device(fec_dt_ids, &pdev->dev);
- if (of_id)
- pdev->id_entry = of_id->data;
-
fec_enet_get_queue_num(pdev, &num_tx_qs, &num_rx_qs);
/* Init network device */
@@ -3146,13 +3113,17 @@ fec_probe(struct platform_device *pdev)
/* setup board info structure */
fep = netdev_priv(ndev);
+ of_id = of_match_device(fec_dt_ids, &pdev->dev);
+ if (of_id)
+ pdev->id_entry = of_id->data;
+ fep->quirks = pdev->id_entry->driver_data;
+
fep->num_rx_queues = num_rx_qs;
fep->num_tx_queues = num_tx_qs;
#if !defined(CONFIG_M5272)
/* default enable pause frame auto negotiation */
- if (pdev->id_entry &&
- (pdev->id_entry->driver_data & FEC_QUIRK_HAS_GBIT))
+ if (fep->quirks & FEC_QUIRK_HAS_GBIT)
fep->pause_flag |= FEC_PAUSE_FLAG_AUTONEG;
#endif
@@ -3221,9 +3192,8 @@ fec_probe(struct platform_device *pdev)
if (IS_ERR(fep->clk_ref))
fep->clk_ref = NULL;
+ fep->bufdesc_ex = fep->quirks & FEC_QUIRK_HAS_BUFDESC_EX;
fep->clk_ptp = devm_clk_get(&pdev->dev, "ptp");
- fep->bufdesc_ex =
- pdev->id_entry->driver_data & FEC_QUIRK_HAS_BUFDESC_EX;
if (IS_ERR(fep->clk_ptp)) {
fep->clk_ptp = NULL;
fep->bufdesc_ex = false;
--
1.7.10.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv3 6/9] net: fec: use swab32s() instead of cpu_to_be32()
From: Lothar Waßmann @ 2014-10-28 13:23 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Russell King, Frank Li, Fabio Estevam,
linux-kernel, Lothar Waßmann, linux-arm-kernel
In-Reply-To: <1414502584-10583-1-git-send-email-LW@KARO-electronics.de>
when swap_buffer() is being called, we know for sure, that we need to
byte swap the data. Also this function is called for swapping data in
both directions. Thus cpu_to_be32() is semantically not correct for
all use cases. Use swab32s() to reflect this.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
---
drivers/net/ethernet/freescale/fec_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 5c1d517..5b76cdc 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -293,7 +293,7 @@ static void *swap_buffer(void *bufaddr, int len)
unsigned int *buf = bufaddr;
for (i = 0; i < DIV_ROUND_UP(len, 4); i++, buf++)
- *buf = cpu_to_be32(*buf);
+ swab32s(buf);
return bufaddr;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCHv3 7/9] net: fec: simplify loop counter handling in swap_buffer()
From: Lothar Waßmann @ 2014-10-28 13:23 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Russell King, Frank Li, Fabio Estevam,
linux-kernel, Lothar Waßmann, linux-arm-kernel
In-Reply-To: <1414502584-10583-1-git-send-email-LW@KARO-electronics.de>
Eliminate the DIV_ROUND_UP() and change the loop counter increment to
4 instead. This results in saving 6 instructions in the functions
assembly code.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
---
drivers/net/ethernet/freescale/fec_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 5b76cdc..ddfc57d 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -292,7 +292,7 @@ static void *swap_buffer(void *bufaddr, int len)
int i;
unsigned int *buf = bufaddr;
- for (i = 0; i < DIV_ROUND_UP(len, 4); i++, buf++)
+ for (i = 0; i < len; i += 4, buf++)
swab32s(buf);
return bufaddr;
--
1.7.10.4
^ permalink raw reply related
* [PATCHv3 8/9] net: fec: remove unused return value from swap_buffer()
From: Lothar Waßmann @ 2014-10-28 13:23 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Russell King, Frank Li, Fabio Estevam,
linux-kernel, Lothar Waßmann, linux-arm-kernel
In-Reply-To: <1414502584-10583-1-git-send-email-LW@KARO-electronics.de>
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
---
drivers/net/ethernet/freescale/fec_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index ddfc57d..e52864c 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -287,7 +287,7 @@ static int fec_enet_get_free_txdesc_num(struct fec_enet_private *fep,
return entries > 0 ? entries : entries + txq->tx_ring_size;
}
-static void *swap_buffer(void *bufaddr, int len)
+static void swap_buffer(void *bufaddr, int len)
{
int i;
unsigned int *buf = bufaddr;
@@ -295,7 +295,6 @@ static void *swap_buffer(void *bufaddr, int len)
for (i = 0; i < len; i += 4, buf++)
swab32s(buf);
- return bufaddr;
}
static void fec_dump(struct net_device *ndev)
--
1.7.10.4
^ permalink raw reply related
* [PATCHv3 9/9] net: fec: fix regression on i.MX28 introduced by rx_copybreak support
From: Lothar Waßmann @ 2014-10-28 13:23 UTC (permalink / raw)
To: netdev
Cc: Fabio Estevam, Frank Li, linux-kernel, Russell King,
David S. Miller, linux-arm-kernel, Lothar Waßmann
In-Reply-To: <1414502584-10583-1-git-send-email-LW@KARO-electronics.de>
commit 1b7bde6d659d ("net: fec: implement rx_copybreak to improve rx performance")
introduced a regression for i.MX28. The swap_buffer() function doing
the endian conversion of the received data on i.MX28 may access memory
beyond the actual packet size in the DMA buffer. fec_enet_copybreak()
does not copy those bytes, so that the last bytes of a packet may be
filled with invalid data after swapping.
This will likely lead to checksum errors on received packets.
E.g. when trying to mount an NFS rootfs:
UDP: bad checksum. From 192.168.1.225:111 to 192.168.100.73:44662 ulen 36
Do the byte swapping and copying to the new skb in one go if
necessary.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
---
drivers/net/ethernet/freescale/fec_main.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index e52864c..5ee4912 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -294,7 +294,16 @@ static void swap_buffer(void *bufaddr, int len)
for (i = 0; i < len; i += 4, buf++)
swab32s(buf);
+}
+
+static void swap_buffer2(void *dst_buf, void *src_buf, int len)
+{
+ int i;
+ unsigned int *src = src_buf;
+ unsigned int *dst = dst_buf;
+ for (i = 0; i < len; i += 4, src++, dst++)
+ *dst = swab32p(src);
}
static void fec_dump(struct net_device *ndev)
@@ -1292,7 +1301,7 @@ fec_enet_new_rxbdp(struct net_device *ndev, struct bufdesc *bdp, struct sk_buff
}
static bool fec_enet_copybreak(struct net_device *ndev, struct sk_buff **skb,
- struct bufdesc *bdp, u32 length)
+ struct bufdesc *bdp, u32 length, bool swap)
{
struct fec_enet_private *fep = netdev_priv(ndev);
struct sk_buff *new_skb;
@@ -1307,7 +1316,10 @@ static bool fec_enet_copybreak(struct net_device *ndev, struct sk_buff **skb,
dma_sync_single_for_cpu(&fep->pdev->dev, bdp->cbd_bufaddr,
FEC_ENET_RX_FRSIZE - fep->rx_align,
DMA_FROM_DEVICE);
- memcpy(new_skb->data, (*skb)->data, length);
+ if (!swap)
+ memcpy(new_skb->data, (*skb)->data, length);
+ else
+ swap_buffer2(new_skb->data, (*skb)->data, length);
*skb = new_skb;
return true;
@@ -1335,6 +1347,7 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
u16 vlan_tag;
int index = 0;
bool is_copybreak;
+ bool need_swap = fep->quirks & FEC_QUIRK_SWAP_FRAME;
#ifdef CONFIG_M532x
flush_cache_all();
@@ -1398,7 +1411,8 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
* include that when passing upstream as it messes up
* bridging applications.
*/
- is_copybreak = fec_enet_copybreak(ndev, &skb, bdp, pkt_len - 4);
+ is_copybreak = fec_enet_copybreak(ndev, &skb, bdp, pkt_len - 4,
+ need_swap);
if (!is_copybreak) {
skb_new = netdev_alloc_skb(ndev, FEC_ENET_RX_FRSIZE);
if (unlikely(!skb_new)) {
@@ -1413,7 +1427,7 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
prefetch(skb->data - NET_IP_ALIGN);
skb_put(skb, pkt_len - 4);
data = skb->data;
- if (fep->quirks & FEC_QUIRK_SWAP_FRAME)
+ if (!is_copybreak && need_swap)
swap_buffer(data, pkt_len);
/* Extract the enhanced buffer descriptor */
--
1.7.10.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCHv2 6/6] net: fec: fix regression on i.MX28 introduced by rx_copybreak support
From: Lothar Waßmann @ 2014-10-28 13:30 UTC (permalink / raw)
To: David Laight
Cc: netdev@vger.kernel.org, David S. Miller, Russell King, Frank Li,
Fabio Estevam, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1C9E06B0@AcuExch.aculab.com>
Hi,
David Laight wrote:
> From: Lothar Waßmann
> > David Laight wrote:
> > > From: Lothar Waßmann
> > > > commit 1b7bde6d659d ("net: fec: implement rx_copybreak to improve rx performance")
> > > > introduced a regression for i.MX28. The swap_buffer() function doing
> > > > the endian conversion of the received data on i.MX28 may access memory
> > > > beyond the actual packet size in the DMA buffer. fec_enet_copybreak()
> > > > does not copy those bytes, so that the last bytes of a packet may be
> > > > filled with invalid data after swapping.
> > > > This will likely lead to checksum errors on received packets.
> > > > E.g. when trying to mount an NFS rootfs:
> > > > UDP: bad checksum. From 192.168.1.225:111 to 192.168.100.73:44662 ulen 36
> > > >
> > > > Do the byte swapping and copying to the new skb in one go if
> > > > necessary.
> > > >
> > > > Signed-off-by: Lothar Wamann <LW@KARO-electronics.de>
> > > > ---
> > > > drivers/net/ethernet/freescale/fec_main.c | 25 +++++++++++++++++++++----
> > > > 1 file changed, 21 insertions(+), 4 deletions(-)
> > > >
> > > > @@ -1455,7 +1472,7 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
> > > > prefetch(skb->data - NET_IP_ALIGN);
> > > > skb_put(skb, pkt_len - 4);
> > > > data = skb->data;
> > > > - if (fep->quirks & FEC_QUIRK_SWAP_FRAME)
> > > > + if (!is_copybreak && need_swap)
> > > > swap_buffer(data, pkt_len);
> > >
> > > It has to be better to set the 'copybreak' limit to be larger than the
> > > maximum frame size and so always go through the 'copybreak' paths.
> > >
> > Since the copybreak support is all about performance optimistation, we
> > should IMO buy the additional advantage for i.MX28 by not having to
> > access the buffer twice (once for copying and once again for swapping).
>
> You definitely want to do the byteswap at the same time as the copy.
>
> The point I'm trying to make that if you need to do the byteswap you
> probably might as well copy the data to an skb of the correct size at
> the same time.
> Certainly I'd expect the 'break even' length will be much higher.
>
I didn't implement the copybreak support. I'm only trying to fix a bug
it introduced for i.MX28. So, I won't mess with the copybreak
parameters.
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
^ permalink raw reply
* Re: [PATCH v2 09/15] net: dsa: Add support for switch EEPROM access
From: Guenter Roeck @ 2014-10-28 13:31 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Florian Fainelli, Andrew Lunn, linux-kernel
In-Reply-To: <1414342365-27191-10-git-send-email-linux@roeck-us.net>
On 10/26/2014 09:52 AM, Guenter Roeck wrote:
> On some chips it is possible to access the switch eeprom.
> Add infrastructure support for it.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
[ ... ]
> @@ -603,6 +604,9 @@ static int dsa_of_probe(struct platform_device *pdev)
> if (pd->nr_chips > DSA_MAX_SWITCHES)
> pd->nr_chips = DSA_MAX_SWITCHES;
>
> + if (!of_property_read_u32(np, "eeprom-length", &eeprom_length))
> + pd->eeprom_length = eeprom_length;
This is buggy; please don't apply. Variable is named eeprom_len, and it is
per switch.
Lesson to self: When writing devicetree code, compile it with devicetree enabled.
Guenter
^ permalink raw reply
* Re: Problem with 10Gbit Broadcom NetXtreme II 5771x/578xx 10/20-Gigabit Ethernet Driver
From: Stefan Bottelier | Ocius.nl @ 2014-10-28 14:07 UTC (permalink / raw)
To: netdev@vger.kernel.org >> netdev
In-Reply-To: <B5657A6538887040AD3A81F1008BEC63B87612@avmb3.qlogic.org>
Hello,
We have fix some problems, but now i get the interface firmware not
working, are the some tips of tricks for this ? Its for a Blade Servers,
and this working the best with the kernel 3.2.0 branch. So i hope
somebody can help me whit this.
[ 76.803495] bnx2x: [bnx2x_init_firmware:10573(eth0)]Can't load
firmware file bnx2x/bnx2x-e2-7.0.29.0.fw
[ 76.803508] bnx2x: [bnx2x_func_hw_init:5382(eth0)]Error loading firmware
[ 76.803523] bnx2x: [bnx2x_nic_load:1847(eth0)]HW init failed, aborting
> You can try netdev again, or you should try with the distro bugzillas
> [I'm not sure if request_firmware() is contained entirely in kernel or is dependent on some tools in the filesystem provided by the distro]
>
>> -----Original Message-----
>> From: Stefan Bottelier | Ocius.nl [mailto:stefan@ocius.nl]
>> Sent: Tuesday, October 28, 2014 2:40 PM
>> To: Yuval Mintz
>> Subject: Re: Problem with 10Gbit Broadcom NetXtreme II 5771x/578xx 10/20-
>> Gigabit Ethernet Driver
>>
>> Are the some places where i get drop this question ? I hope so that i get it
>> working on this Dell Server.
>>
>>> Sounds like a small technicality, but sadly I cannot help you from afar.
>>>
>>>> -----Original Message-----
>>>> From: Stefan Bottelier | Ocius.nl [mailto:stefan@ocius.nl]
>>>> Sent: Tuesday, October 28, 2014 2:29 PM
>>>> To: Yuval Mintz
>>>> Subject: Re: Problem with 10Gbit Broadcom NetXtreme II 5771x/578xx
>>>> 10/20- Gigabit Ethernet Driver
>>>>
>>>> Any ideas?
>>>>
>>>> why this message will be coming up.
>>>>
>>>> [ 76.074999] bnx2x: [bnx2x_init_firmware:10573(eth0)]Can't load
>>>> firmware file bnx2x/bnx2x-e2-7.0.29.0.fw
>>>> [ 76.075011] bnx2x: [bnx2x_func_hw_init:5382(eth0)]Error loading firmware
>>>> [ 76.075032] bnx2x: [bnx2x_nic_load:1847(eth0)]HW init failed, aborting
>>>>
>>>> I have change the firmware in
>>>>
>>>> bnx2x_main.c and i have set the firmware images in
>>>> /lib/firmware/bnx2x
>>>>
>>>>
>>>>> You can get it from by cloning the linux-firmware git repository at
>>>>> - git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.
>>>>> git
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Stefan Bottelier | Ocius.nl [mailto:stefan@ocius.nl]
>>>>>> Sent: Tuesday, October 28, 2014 1:17 PM
>>>>>> To: Yuval Mintz
>>>>>> Subject: Re: Problem with 10Gbit Broadcom NetXtreme II 5771x/578xx
>>>>>> 10/20- Gigabit Ethernet Driver
>>>>>>
>>>>>> Hello Yuval,
>>>>>>
>>>>>> Now i get no erro's only the follwing imforation
>>>>>> [ 18.340531] bnx2x 0000:01:00.0: Bad FW version:6.2.9.0. Should be
>>>>>> 7.0.29.0
>>>>>> [ 18.340542] bnx2x: [bnx2x_init_firmware:10579(eth0)]Corrupt firmware
>>>>>> file bnx2x/bnx2x-e2-6.2.9.0.fw
>>>>>> [ 18.340550] bnx2x: [bnx2x_func_hw_init:5382(eth0)]Error loading
>> firmware
>>>>>> [ 18.340562] bnx2x: [bnx2x_nic_load:1847(eth0)]HW init failed, aborting
>>>>>>
>>>>>> If are a location where i can download the 7.0.29.0 firmware, i
>>>>>> change to the kernel firmware but this don't work. So i a searching
>>>>>> for the
>>>>>> 7.0.29.0 firmware.
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> The change might affect you - you're using a new board.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Yuval
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Stefan Bottelier | Ocius.nl [mailto:stefan@ocius.nl]
>>>>>>>> Sent: Tuesday, October 28, 2014 12:15 PM
>>>>>>>> To: Yuval Mintz
>>>>>>>> Subject: Re: Problem with 10Gbit Broadcom NetXtreme II
>>>>>>>> 5771x/578xx
>>>>>>>> 10/20- Gigabit Ethernet Driver
>>>>>>>>
>>>>>>>> Hello Yuval,
>>>>>>>>
>>>>>>>> Whithout code change i see.
>>>>>>>>
>>>>>>>> bash-4.3# ethtool -i eth0
>>>>>>>> driver: bnx2x
>>>>>>>> version: 1.70.30-0
>>>>>>>> firmware-version: bc 7.10.11
>>>>>>>> bus-info: 0000:01:00.0
>>>>>>>>
>>>>>>>>> Btw,
>>>>>>>>>
>>>>>>>>> You can supply `ethtool -i' output on one of the interfaces to
>>>>>>>>> see whether the
>>>>>>>> warning would actually apply.
>>>>>>>>> Thanks,
>>>>>>>>> Yuval
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Yuval Mintz
>>>>>>>>>> Sent: Tuesday, October 28, 2014 12:07 PM
>>>>>>>>>> To: 'Stefan Bottelier | Ocius.nl'
>>>>>>>>>> Subject: RE: Problem with 10Gbit Broadcom NetXtreme II
>>>>>>>>>> 5771x/578xx
>>>>>>>>>> 10/20- Gigabit Ethernet Driver
>>>>>>>>>>
>>>>>>>>>> Well,
>>>>>>>>>>
>>>>>>>>>> There is actually a WARN_ON in line 8886, and that warning was
>>>>>>>>>> later removed for newer boards.
>>>>>>>>>>
>>>>>>>>>> Please try removing it and changing to the code in
>>>>>>>>>> bnx2x_get_igu_cam_info() from upstream kernel, and see what's
>> next.
>>>>>>>>>> Cheers,
>>>>>>>>>> Yuval
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Stefan Bottelier | Ocius.nl [mailto:stefan@ocius.nl]
>>>>>>>>>>> Sent: Tuesday, October 28, 2014 11:59 AM
>>>>>>>>>>> To: Yuval Mintz
>>>>>>>>>>> Subject: Re: Problem with 10Gbit Broadcom NetXtreme II
>>>>>>>>>>> 5771x/578xx
>>>>>>>>>>> 10/20- Gigabit Ethernet Driver
>>>>>>>>>>>
>>>>>>>>>>> Hello Yuval,
>>>>>>>>>>>
>>>>>>>>>>> I have change this in the
>>>>>>>>>>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
>>>>>>>>>>>
>>>>>>>>>>> With new code from the 3.10 kernel
>>>>>>>>>>>
>>>>>>>>>>> static void bnx2x_set_mac_buf(u8 *mac_buf, u32 mac_lo, u16
>>>>>>>>>>> mac_hi)
>>>> {
>>>>>>>>>>> __be16 mac_hi_be = cpu_to_be16(mac_hi);
>>>>>>>>>>> __be32 mac_lo_be = cpu_to_be32(mac_lo);
>>>>>>>>>>> memcpy(mac_buf, &mac_hi_be, sizeof(mac_hi_be));
>>>>>>>>>>> memcpy(mac_buf + sizeof(mac_hi_be), &mac_lo_be,
>>>>>>>>>>> sizeof(mac_lo_be)); }
>>>>>>>>>>>
>>>>>>>>>>> Now i get the following message back
>>>>>>>>>>>
>>>>>>>>>>> [ 5.748765] WARNING: at
>>>>>>>>>>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:8886
>>>>>>>>>>> bnx2x_init_one+0xd04/0x2786()
>>>>>>>>>>> [ 5.748767] Hardware name: PowerEdge M620
>>>>>>>>>>> [ 5.748769] Modules linked in:
>>>>>>>>>>> [ 5.748773] Pid: 1, comm: swapper/0 Tainted: G W 3.2.63 #1
>>>>>>>>>>>
>>>>>>>>>>> Are this correct my change in this code ?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi Stefan,
>>>>>>>>>>>>
>>>>>>>>>>>> Are you using a Big-Endian machine?
>>>>>>>>>>>>
>>>>>>>>>>>> Regardless, I don't really have anything 'good' to tell you -
>>>>>>>>>>>> the code you've given me is the same as the one I've looked
>>>>>>>>>>>> at, and line
>>>>>>>>>>>> 9410 doesn't
>>>>>>>>>>> really include anything that should produce a warn [at most, a
>>>>>>>>>>> NULL pointer dereference].
>>>>>>>>>>>> Regardless, if you can - you can try to replace the
>>>>>>>>>>>> implementation of
>>>>>>>>>>>> bnx2x_set_mac_buf() in your kernel in bnx2x_main.c with the
>>>>>>>>>>>> one from more
>>>>>>>>>>> modern kernels; [It doesn't pass address of parameters to the
>>>>>>>>>>> function] and see if it solves your issue.
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Yuval
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Stefan Bottelier | Ocius.nl [mailto:stefan@ocius.nl]
>>>>>>>>>>>>> Sent: Tuesday, October 28, 2014 10:31 AM
>>>>>>>>>>>>> To: Yuval Mintz
>>>>>>>>>>>>> Subject: Re: Problem with 10Gbit Broadcom NetXtreme II
>>>>>>>>>>>>> 5771x/578xx
>>>>>>>>>>>>> 10/20- Gigabit Ethernet Driver
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hello Yuval,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Correct i use 32bits machine
>>>>>>>>>>>>>
>>>>>>>>>>>>> 3.2.63 #1 SMP Mon Oct 27 11:22:59 CET 2014 i686 i686 i386
>>>>>>>>>>>>> GNU/Linux
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have added new files. objdump i have run this command in
>>>>>>>>>>>>> the bnx2x dir from the kernel source, i hope thats is oke ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Stefan
>>>>>>>>>>>>>> Hi Stefan,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2 things:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. For some reason the source files I'm looking at don't
>>>>>>>>>>>>>> look the same as
>>>>>>>>>>>>> yours.
>>>>>>>>>>>>>> If you can, please tarball me the bnx2x directory from the
>>>>>>>>>>>>>> kernel sources
>>>>>>>>>>>>> you've compile and send it to me.
>>>>>>>>>>>>>> 2. objdump doesn't contain the source code; Are you sure
>>>>>>>>>>>>>> you've used
>>>>>>>>>>>>> `objdump -S' as opposed to simple `objdump' when generating it?
>>>>>>>>>>>>>> 3. Just to be certain, you're using a 32-bit machine, right?
>>>>>>>>>>>>>> [Don't know if it's related, but it's rare enough that I
>>>>>>>>>>>>>> should consider it when I look at the issue]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Yuval
>>>>>>>>>>>>>> ________________________________________
>>>>>>>>>>>>>> From: Yuval Mintz
>>>>>>>>>>>>>> Sent: Monday, October 27, 2014 8:38 AM
>>>>>>>>>>>>>> To: Stefan Bottelier | Ocius.nl
>>>>>>>>>>>>>> Subject: RE: Problem with 10Gbit Broadcom NetXtreme II
>>>>>>>>>>>>>> 5771x/578xx 10/20-Gigabit Ethernet Driver
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Stefan - I have, but I still haven't been able to look into it.
>>>>>>>>>>>>>> ________________________________________
>>>>>>>>>>>>>> From: Stefan Bottelier | Ocius.nl [stefan@ocius.nl]
>>>>>>>>>>>>>> Sent: Monday, October 27, 2014 8:32 AM
>>>>>>>>>>>>>> To: Yuval Mintz
>>>>>>>>>>>>>> Subject: Re: Problem with 10Gbit Broadcom NetXtreme II
>>>>>>>>>>>>>> 5771x/578xx 10/20-Gigabit Ethernet Driver
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello Yuval,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Do you have received my file's good ? I am not sure..
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Stefan,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Just looked into 3.2.63 [Saber-toothed Squirrel] sources,
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> bnx2x_main:9410 doesn't look as if it contains any code
>>>>>>>>>>>>>>> that can throw a
>>>>>>>>>>>>> stack trace, Nor is it a [direct] part of bnx2x_init_one.
>>>>>>>>>>>>>>> Perhaps you can send the output of `objdump -S bnx2x.ko',
>>>>>>>>>>>>>>> so I could take a
>>>>>>>>>>>>> look at the place the stack trace points as the source of the issue?
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>> Yuval
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>> From: Stefan Bottelier | Ocius.nl
>>>>>>>>>>>>>>>> [mailto:stefan@ocius.nl]
>>>>>>>>>>>>>>>> Sent: Monday, October 27, 2014 10:43 AM
>>>>>>>>>>>>>>>> To: Yuval Mintz
>>>>>>>>>>>>>>>> Cc: netdev
>>>>>>>>>>>>>>>> Subject: Re: Problem with 10Gbit Broadcom NetXtreme II
>>>>>>>>>>>>>>>> 5771x/578xx
>>>>>>>>>>>>>>>> 10/20- Gigabit Ethernet Driver
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hello Yuval,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks for this messages.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We use now the kernel 3.10.57 and then the interface
>>>>>>>>>>>>>>>> working, only we must back to the kernel we always use
>>>>>>>>>>>>>>>> 3.2.63 , its work better with use
>>>>>>>>>>>>> systems.
>>>>>>>>>>>>>>>> I have compiler the kernel by my self on a Suse system.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I hope we can fix it, that this working with the kernel 3.2.63.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> We are using Dell Blade Centers, but we get a error on
>>>>>>>>>>>>>>>>>> the 10Gbit Broadcom adapter bnx2x bnx2x 0000:01:00.0:
>>>>>>>>>>>>>>>>>> part number
>>>>>>>>>>>>>>>>>> 394D4342-31383735-30315430-473030
>>>>>>>>>>>>>>>>>> WARNING: at
>>>>>>>>>>>>>>>>>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:9410
>>>>>>>>>>>>>>>>> Hi Stefan,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Which distro & linux kernel are you using?
>>>>>>>>>>>>>>>>> [Obviously not net-next]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> Yuval
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ________________________________
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This message and any attached documents contain
>>>>>>>>>>>>>>>>> information from the
>>>>>>>>>>>>>>>> sending company or its parent company(s), subsidiaries,
>>>>>>>>>>>>>>>> divisions or branch offices that may be confidential. If
>>>>>>>>>>>>>>>> you are not the intended recipient, you may not read,
>>>>>>>>>>>>>>>> copy, distribute, or use this information. If you have
>>>>>>>>>>>>>>>> received this transmission in error, please notify the
>>>>>>>>>>>>>>>> sender immediately by reply e-mail and then delete this
>>>>>>>>>>> message.
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Met vriendelijke groet,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Stefan Bottelier
>>>>>>>>>>>>>>>> Ocius Internet Services
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> E: Stefan.Bottelier@ocius.nl
>>>>>>>>>>>>>>>> T: +31 (0)20 716 39 09
>>>>>>>>>>>>>>>> W: http://www.ocius.nl
>>>>>>>>>>>>>>> ________________________________
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This message and any attached documents contain
>>>>>>>>>>>>>>> information from the
>>>>>>>>>>>>> sending company or its parent company(s), subsidiaries,
>>>>>>>>>>>>> divisions or branch offices that may be confidential. If you
>>>>>>>>>>>>> are not the intended recipient, you may not read, copy,
>>>>>>>>>>>>> distribute, or use this information. If you have received
>>>>>>>>>>>>> this transmission in error, please notify the sender
>>>>>>>>>>>>> immediately by reply e-mail and then delete this
>>>>>>>>>> message.
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Met vriendelijke groet,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Stefan Bottelier
>>>>>>>>>>>>>> Ocius Internet Services
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> E: Stefan.Bottelier@ocius.nl
>>>>>>>>>>>>>> T: +31 (0)20 716 39 09
>>>>>>>>>>>>>> W: http://www.ocius.nl
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ________________________________
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This message and any attached documents contain information
>>>>>>>>>>>>>> from the
>>>>>>>>>>>>> sending company or its parent company(s), subsidiaries,
>>>>>>>>>>>>> divisions or branch offices that may be confidential. If you
>>>>>>>>>>>>> are not the intended recipient, you may not read, copy,
>>>>>>>>>>>>> distribute, or use this information. If you have received
>>>>>>>>>>>>> this transmission in error, please notify the sender
>>>>>>>>>>>>> immediately by reply e-mail and then delete this
>>>>>>>>>> message.
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Met vriendelijke groet,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Stefan Bottelier
>>>>>>>>>>>>> Ocius Internet Services
>>>>>>>>>>>>>
>>>>>>>>>>>>> E: Stefan.Bottelier@ocius.nl
>>>>>>>>>>>>> T: +31 (0)20 716 39 09
>>>>>>>>>>>>> W: http://www.ocius.nl
>>>>>>>>>>>> ________________________________
>>>>>>>>>>>>
>>>>>>>>>>>> This message and any attached documents contain information
>>>>>>>>>>>> from the
>>>>>>>>>>> sending company or its parent company(s), subsidiaries,
>>>>>>>>>>> divisions or branch offices that may be confidential. If you
>>>>>>>>>>> are not the intended recipient, you may not read, copy,
>>>>>>>>>>> distribute, or use this information. If you have received this
>>>>>>>>>>> transmission in error, please notify the sender immediately by
>>>>>>>>>>> reply e-mail and then delete this
>>>>>> message.
>>>>>>>>>>> --
>>>>>>>>>>> Met vriendelijke groet,
>>>>>>>>>>>
>>>>>>>>>>> Stefan Bottelier
>>>>>>>>>>> Ocius Internet Services
>>>>>>>>>>>
>>>>>>>>>>> E: Stefan.Bottelier@ocius.nl
>>>>>>>>>>> T: +31 (0)20 716 39 09
>>>>>>>>>>> W: http://www.ocius.nl
>>>>>>>>> ________________________________
>>>>>>>>>
>>>>>>>>> This message and any attached documents contain information from
>>>>>>>>> the
>>>>>>>> sending company or its parent company(s), subsidiaries, divisions
>>>>>>>> or branch offices that may be confidential. If you are not the
>>>>>>>> intended recipient, you may not read, copy, distribute, or use
>>>>>>>> this information. If you have received this transmission in
>>>>>>>> error, please notify the sender immediately by reply e-mail and
>>>>>>>> then delete this
>>>> message.
>>>>>>>> --
>>>>>>>> Met vriendelijke groet,
>>>>>>>>
>>>>>>>> Stefan Bottelier
>>>>>>>> Ocius Internet Services
>>>>>>>>
>>>>>>>> E: Stefan.Bottelier@ocius.nl
>>>>>>>> T: +31 (0)20 716 39 09
>>>>>>>> W: http://www.ocius.nl
>>>>>>> ________________________________
>>>>>>>
>>>>>>> This message and any attached documents contain information from
>>>>>>> the
>>>>>> sending company or its parent company(s), subsidiaries, divisions
>>>>>> or branch offices that may be confidential. If you are not the
>>>>>> intended recipient, you may not read, copy, distribute, or use this
>>>>>> information. If you have received this transmission in error,
>>>>>> please notify the sender immediately by reply e-mail and then delete this
>> message.
>>>>>>
>>>>>> --
>>>>>> Met vriendelijke groet,
>>>>>>
>>>>>> Stefan Bottelier
>>>>>> Ocius Internet Services
>>>>>>
>>>>>> E: Stefan.Bottelier@ocius.nl
>>>>>> T: +31 (0)20 716 39 09
>>>>>> W: http://www.ocius.nl
>>>>> ________________________________
>>>>>
>>>>> This message and any attached documents contain information from the
>>>> sending company or its parent company(s), subsidiaries, divisions or
>>>> branch offices that may be confidential. If you are not the intended
>>>> recipient, you may not read, copy, distribute, or use this
>>>> information. If you have received this transmission in error, please
>>>> notify the sender immediately by reply e-mail and then delete this message.
>>>>
>>>>
>>>> --
>>>> Met vriendelijke groet,
>>>>
>>>> Stefan Bottelier
>>>> Ocius Internet Services
>>>>
>>>> E: Stefan.Bottelier@ocius.nl
>>>> T: +31 (0)20 716 39 09
>>>> W: http://www.ocius.nl
>>> ________________________________
>>>
>>> This message and any attached documents contain information from the
>> sending company or its parent company(s), subsidiaries, divisions or branch
>> offices that may be confidential. If you are not the intended recipient, you may
>> not read, copy, distribute, or use this information. If you have received this
>> transmission in error, please notify the sender immediately by reply e-mail and
>> then delete this message.
>>
>>
>> --
>> Met vriendelijke groet,
>>
>> Stefan Bottelier
>> Ocius Internet Services
>>
>> E: Stefan.Bottelier@ocius.nl
>> T: +31 (0)20 716 39 09
>> W: http://www.ocius.nl
>
> ________________________________
>
> This message and any attached documents contain information from the sending company or its parent company(s), subsidiaries, divisions or branch offices that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
--
Met vriendelijke groet,
Stefan Bottelier
Ocius Internet Services
E: Stefan.Bottelier@ocius.nl
T: +31 (0)20 716 39 09
W: http://www.ocius.nl
^ permalink raw reply
* Re: [PATCH 5/7] fs: Convert show_fdinfo functions to void
From: Steven Rostedt @ 2014-10-28 14:11 UTC (permalink / raw)
To: Joe Perches
Cc: Al Viro, Petr Mladek, Andrew Morton, Linus Torvalds, Jiri Kosina,
Thomas Gleixner, Jeff Layton, J. Bruce Fields, linux-doc,
linux-kernel, netdev, linux-fsdevel
In-Reply-To: <e37e6e7b76acbdcc3bb4ab2a57c8f8ca1ae11b9a.1412031505.git.joe@perches.com>
On Mon, 29 Sep 2014 16:08:25 -0700
Joe Perches <joe@perches.com> wrote:
> seq_printf functions shouldn't really check the return value.
> Checking seq_is_full occasionally is used instead.
>
> Update vfs documentation.
>
> Signed-off-by: Joe Perches <joe@perches.com>
>
> -#ifdef CONFIG_PROC_FS
> -static int eventfd_show_fdinfo(struct seq_file *m, struct file *f)
> +static void eventfd_show_fdinfo(struct seq_file *m, struct file *f)
> {
> +#ifdef CONFIG_PROC_FS
> struct eventfd_ctx *ctx = f->private_data;
> - int ret;
>
> spin_lock_irq(&ctx->wqh.lock);
> - ret = seq_printf(m, "eventfd-count: %16llx\n",
> - (unsigned long long)ctx->count);
> + seq_printf(m, "eventfd-count: %16llx\n",
> + (unsigned long long)ctx->count);
> spin_unlock_irq(&ctx->wqh.lock);
> -
> - return ret;
> -}
> #endif
> +}
>
> static const struct file_operations eventfd_fops = {
> -#ifdef CONFIG_PROC_FS
> .show_fdinfo = eventfd_show_fdinfo,
> -#endif
I wouldn't change logic on this. There's no reason to call this
function if it isn't doing anything.
I'll change this to just do the update and not change logic like this.
-- Steve
> .release = eventfd_release,
> .poll = eventfd_poll,
> .read = eventfd_read,
> diff --git a/fs/proc/fd.c b/fs/proc/fd.c
> index e11d7c5..4c3c253 100644
> --- a/fs/proc/fd.c
> +++ b/fs/proc/fd.c
> @@ -53,7 +53,7 @@ static int seq_show(struct seq_file *m, void *v)
> (long long)file->f_pos, f_flags,
> real_mount(file->f_path.mnt)->mnt_id);
> if (file->f_op->show_fdinfo)
> - ret = file->f_op->show_fdinfo(m, file);
> + file->f_op->show_fdinfo(m, file);
> fput(file);
> }
>
^ permalink raw reply
* Re: [PATCH 5/7] fs: Convert show_fdinfo functions to void
From: Joe Perches @ 2014-10-28 14:31 UTC (permalink / raw)
To: Steven Rostedt
Cc: Al Viro, Petr Mladek, Andrew Morton, Linus Torvalds, Jiri Kosina,
Thomas Gleixner, Jeff Layton, J. Bruce Fields, linux-doc,
linux-kernel, netdev, linux-fsdevel
In-Reply-To: <20141028101158.3dde9880@gandalf.local.home>
On Tue, 2014-10-28 at 10:11 -0400, Steven Rostedt wrote:
> On Mon, 29 Sep 2014 16:08:25 -0700
> Joe Perches <joe@perches.com> wrote:
>
> > seq_printf functions shouldn't really check the return value.
> > Checking seq_is_full occasionally is used instead.
> >
> > Update vfs documentation.
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
>
>
> >
> > -#ifdef CONFIG_PROC_FS
> > -static int eventfd_show_fdinfo(struct seq_file *m, struct file *f)
> > +static void eventfd_show_fdinfo(struct seq_file *m, struct file *f)
> > {
> > +#ifdef CONFIG_PROC_FS
> > struct eventfd_ctx *ctx = f->private_data;
> > - int ret;
> >
> > spin_lock_irq(&ctx->wqh.lock);
> > - ret = seq_printf(m, "eventfd-count: %16llx\n",
> > - (unsigned long long)ctx->count);
> > + seq_printf(m, "eventfd-count: %16llx\n",
> > + (unsigned long long)ctx->count);
> > spin_unlock_irq(&ctx->wqh.lock);
> > -
> > - return ret;
> > -}
> > #endif
> > +}
> >
> > static const struct file_operations eventfd_fops = {
> > -#ifdef CONFIG_PROC_FS
> > .show_fdinfo = eventfd_show_fdinfo,
> > -#endif
>
> I wouldn't change logic on this. There's no reason to call this
> function if it isn't doing anything.
>
> I'll change this to just do the update and not change logic like this.
Fewer #ifdefs
^ permalink raw reply
* Re: [PATCH 5/7] fs: Convert show_fdinfo functions to void
From: Steven Rostedt @ 2014-10-28 14:43 UTC (permalink / raw)
To: Joe Perches
Cc: Al Viro, Petr Mladek, Andrew Morton, Linus Torvalds, Jiri Kosina,
Thomas Gleixner, Jeff Layton, J. Bruce Fields, linux-doc,
linux-kernel, netdev, linux-fsdevel
In-Reply-To: <1414506692.6643.2.camel@perches.com>
On Tue, 28 Oct 2014 07:31:32 -0700
Joe Perches <joe@perches.com> wrote:
> > I wouldn't change logic on this. There's no reason to call this
> > function if it isn't doing anything.
> >
> > I'll change this to just do the update and not change logic like this.
>
> Fewer #ifdefs
>
And there's other ways to fix it (like using an #else), but that is
off-topic to the current change set. In other words, that change should
be separate, as I don't want discussions on what's the best use of
#ifdefs distracting from getting in the "void seq_printf()" changes.
-- Steve
^ permalink raw reply
* Re: [PATCH] [trivial] treewide: Fix company name in module descriptions
From: Linus Walleij @ 2014-10-28 14:44 UTC (permalink / raw)
To: Masanari Iida
Cc: linux-kernel@vger.kernel.org, Mike Turquette, Jiri Kosina,
Alexandre Courbot, jcliburn, chris.snook, Viresh Kumar, inki.dae,
leedonghwa, Kukjin Kim, Randy Dunlap, netdev@vger.kernel.org
In-Reply-To: <1413472164-22366-1-git-send-email-standby24x7@gmail.com>
On Thu, Oct 16, 2014 at 5:09 PM, Masanari Iida <standby24x7@gmail.com> wrote:
> This patch fix company name's spelling typo in module descriptions
> and a Kconfig.
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 net-next] net: ipv6: Add a sysctl to make optimistic addresses useful candidates
From: Lorenzo Colitti @ 2014-10-28 15:15 UTC (permalink / raw)
To: Erik Kline
Cc: netdev@vger.kernel.org, David Miller, Ben Hutchings,
Hannes Frederic Sowa
In-Reply-To: <1414487474-18201-1-git-send-email-ek@google.com>
On Tue, Oct 28, 2014 at 6:11 PM, Erik Kline <ek@google.com> wrote:
> Add a sysctl that causes an interface's optimistic addresses
> to be considered equivalent to other non-deprecated addresses
> for source address selection purposes. Preferred addresses
> will still take precedence over optimistic addresses, subject
> to other ranking in the source address selection algorithm.
> ...
> Signed-off-by: Erik Kline <ek@google.com>
Acked-by: Lorenzo Colitti <lorenzo@google.com>
^ permalink raw reply
* Re: [PATCH net-next 2/2] udp: Reset flow table for flows over unconnected sockets
From: Tom Herbert @ 2014-10-28 15:18 UTC (permalink / raw)
To: David Miller; +Cc: Eric Dumazet, Linux Netdev List
In-Reply-To: <20141028.005121.1715627351754245965.davem@davemloft.net>
On Mon, Oct 27, 2014 at 9:51 PM, David Miller <davem@davemloft.net> wrote:
> From: Tom Herbert <therbert@google.com>
> Date: Mon, 27 Oct 2014 18:09:25 -0700
>
>> This indicates nothing about the merits of this patch. Nevertheless,
>> in order to avoid further rat-holing and since this patch does change
>> a long standing behavior I'll will respin to make it enabled only by
>> sysctl.
>
> Kind of disappointed on my end that you haven't addressed Eric's
> main point, which is that:
>
> 1) A hash table shared between protocols will perform poorly for
> mixed workloads which are becomming increasingly common.
>
The major design point of RFS is that it steers L4 flows based on a
hash for the each flow. Preferably, this hash is based on the 5-tuple
of the (innermost) UDP, TCP, SCTP, etc. packet. It is a probabilistic
algorithm whose effectiveness depends on hit rate in the table, hence
the table should be sized to the working set. In RFS, the working set
is defined by the number of simultaneously active flows not by the
number of established flows which could be much greater. We've known
from the beginning that for some servers with large amounts of
non-flow based traffic (particularly DNS servers) RFS may not be
useful. If it's not feasible to size the table to the working set,
then RFS shouldn't be used.
> 2) UDP is fundamentally different from TCP in that the issue of
> 'flow' vs. 'non-flow' packets
>
We are seeing many instances where UDP packets carry flows, and
conversely there are important cases where TCP packets do not
correspond to flows.
UDP tunnels are becoming increasingly common. VXLAN, FOU, GUE, geneve,
l2tp, esp/UDP, GRE/UDP, nvgre, etc. all rely on steering based on the
outer header without deep inspection. When the source port is set to
inner hash RFS works as is and steering is effectively done based
inner TCP connections. If aRFS supports UDP, then this should just
work also for UDP tunnels (another instance where we don't need
protocol specific support in devices for tunneling).
QUIC itself is flow based. It is a transport protocol about as
sophisticated as TCP that is encapsulated in UDP to facilitate
transport. The fact that QUIC might have millions of simultaneously
active connections is a problem of scale, not of the algorithm. If we
have a server with millions of active TCP connections we'd have the
exact same scaling problem.
Under several DOS attacks TCP packets are not flow based. For instance
in a SYN attack once we get into syn cookies, SYNs are steered based
on whatever is in the table and the table is not updated for these
packets. This case exhibits the same characteristics as non-flow UDP.
In fact makes me think we should also be clearing the flow table in
this case.
> I personally do not see you avoiding this conversation by simply
> hiding the new behavior behind a sysctl, I still want you to address
> it before I apply anything.
^ permalink raw reply
* Re: some failures with vxlan offloads..
From: Or Gerlitz @ 2014-10-28 15:27 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev@vger.kernel.org, John Fastabend, Jeff Kirsher
In-Reply-To: <CA+mtBx9g6MYpFv83av1YdRpZRBcBKvsqzSnhs5C7iV+kP8cWDA@mail.gmail.com>
On 10/27/2014 3:23 AM, Tom Herbert wrote:
> On Sun, Oct 26, 2014 at 3:23 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>> On Sun, Oct 26, 2014 at 5:29 PM, Tom Herbert <therbert@google.com> wrote:
>>> Can you determine what the TSO HW engine is setting in UDP checksum
>>> field? tcpdump -vv might be able to show this. The symptoms seem to
>>> indicate that it may not be zero.
>> Thanks for the quick response. I'll check what is placed in the UDP
>> checksum field for packets that went through the offloading HW and let
>> you know.
>>
>> BTW, if following the direction you proposed, I wonder why this works
>> (e.g the kernel doesn't drops the encapsulated TCP packets) when both
>> sides are offloaded?
>>
> I'm just speculating, but the device may be returning checksum unnecessary for the UDP checksum without actually checking it. Technically, VXLAN RFC7348 allows an implementation to ignore the UDP checksum, although this clearly violates RFC1122 UDP checksum
> requirements. In the stack we now checksum all non-zero checksums including UDP checksum in VXLAN if it's not marked checksum-unnecessary.
OK, I found something (it's always bad habit to try and potentially
blame someone else for your bugs...) -- as I wrote here earlier, the
current HW doesn't support checksum generation for both the inner (say
TCP) and outer (UDP) packet (and indeed we don't advertize
SKB_GSO_UDP_TUNNEL_CSUM).
So if we tell them to offload the inner TCP checksum we must **not**
tell them to attempt and offload the outer checksum too, and I wrongly
did that... once I stopped doing so, I get mixed configurations (one
side offloaded the peer not offloaded) to work. I will submit mlx4 fix
for that.
I wonder if we have another bug somewhere... when both sides were
offloaded, it works even with the mlx4 bug, canyou explain that?is it
possible that the GRO stack somehow covers on the bug when both sides
are offloaded and GRO/VXLAN comes into play?
Or.
after the fix, packets sent by the offloaded side (192.168.31.17) carry
zero udpchecksum
17:20:44.445866 IP (tos 0x0, ttl 64, id 61275, offset 0, flags [DF],
proto UDP (17), length 1500)
192.168.31.17.45387 > 192.168.31.18.4789: [no cksum] UDP, length 1472
0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
0x0010: 05dc ef5b 4000 4011 8641 c0a8 1f11 c0a8
0x0020: 1f12 b14b 12b5 05c8 0000 0800 0000 0000
0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
0x0040: 4500 05aa bb84 4000 4006 9055 c0a8 3411
0x0050: c0a8 3412 e479 9116 553a e008 f28e 6268
0x0060: 5010 0038 88e3 0000 6600 6e65 7470 6572
0x0070: 6600 6e65 7470 6572 6600
17:20:44.445871 IP (tos 0x0, ttl 64, id 61276, offset 0, flags [DF],
proto UDP (17), length 1500)
192.168.31.17.45387 > 192.168.31.18.4789: [no cksum] UDP, length 1472
0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
0x0010: 05dc ef5c 4000 4011 8640 c0a8 1f11 c0a8
0x0020: 1f12 b14b 12b5 05c8 0000 0800 0000 0000
0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
0x0040: 4500 05aa bb85 4000 4006 9054 c0a8 3411
0x0050: c0a8 3412 e479 9116 553a e58a f28e 6268
0x0060: 5010 0038 7afc 0000 6e65 7470 6572 6600
0x0070: 6e65 7470 6572 6600 6e65
before the fix, packets sent by the offloaded side (192.168.31.17) carry
junkudpchecksum
Also note that on one of the packets sent by the offloaded part, we
don't see the "bad udp cksum" scream from tcpdump, which is weird...
17:03:08.765845 IP (tos 0x0, ttl 64, id 52396, offset 0, flags [DF],
proto UDP (17), length 746)
192.168.31.17.56686 > 192.168.31.18.4789: UDP, length 718
0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
0x0010: 02ea ccac 4000 4011 abe2 c0a8 1f11 c0a8
0x0020: 1f12 dd6e 12b5 02d6 0c1b 0800 0000 0000
0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
0x0040: 4500 02b8 6357 4000 4006 eb74 c0a8 3411
0x0050: c0a8 3412 86f2 3241 d67e f47d e5a9 d041
0x0060: 5018 0038 871c 0000 0000 0258 ffff ffff
0x0070: 0000 0000 0000 0000 0000
17:03:09.336285 IP (tos 0x0, ttl 64, id 52536, offset 0, flags [DF],
proto UDP (17), length 90)
192.168.31.17.56686 > 192.168.31.18.4789: [bad udp cksum 1360!]
UDP, length 62
0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
0x0010: 005a cd38 4000 4011 ade6 c0a8 1f11 c0a8
0x0020: 1f12 dd6e 12b5 0046 139a 0800 0000 0000
0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
0x0040: 4500 0028 6358 4000 4006 ee03 c0a8 3411
0x0050: c0a8 3412 86f2 3241 d67e f70d e5a9 d041
0x0060: 5011 0038 897b 0000
17:03:10.335074 IP (tos 0x0, ttl 64, id 40045, offset 0, flags [DF],
proto UDP (17), length 98)
192.168.31.18.48861 > 192.168.31.17.4789: [no cksum] UDP, length 70
0x0000: 0002 c9e9 bf32 f452 1401 da82 0800 4500
0x0010: 0062 9c6d 4000 4011 dea9 c0a8 1f12 c0a8
0x0020: 1f11 bedd 12b5 004e 0000 0800 0000 0000
0x0030: 6300 7a83 2ecb 8c68 b2c7 81db e850 0800
0x0040: 4500 0030 0000 4000 4006 5154 c0a8 3412
0x0050: c0a8 3411 3241 86f2 e5a9 d040 d67e f47d
0x0060: 7012 6e28 f282 0000 0204 0582 0103 0307
17:03:10.335110 IP (tos 0x0, ttl 64, id 52764, offset 0, flags [DF],
proto UDP (17), length 90)
192.168.31.17.56686 > 192.168.31.18.4789: [bad udp cksum 1360!]
UDP, length 62
0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
0x0010: 005a ce1c 4000 4011 ad02 c0a8 1f11 c0a8
0x0020: 1f12 dd6e 12b5 0046 139a 0800 0000 0000
0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
0x0040: 4500 0028 6359 4000 4006 ee02 c0a8 3411
0x0050: c0a8 3412 86f2 3241 d67e f70e e5a9 d041
0x0060: 5010 0038 897b 0000
^ permalink raw reply
* [PATCHv1 0/2 net-next] xen-netback: minor cleanups
From: David Vrabel @ 2014-10-28 15:29 UTC (permalink / raw)
To: netdev; +Cc: David Vrabel, xen-devel, Ian Campbell, Wei Liu
Two minor xen-netback cleanups originally from Zoltan.
David
^ permalink raw reply
* [PATCH 2/2] xen-netback: Remove __GFP_COLD
From: David Vrabel @ 2014-10-28 15:29 UTC (permalink / raw)
To: netdev; +Cc: David Vrabel, xen-devel, Ian Campbell, Wei Liu, Zoltan Kiss
In-Reply-To: <1414510171-12853-1-git-send-email-david.vrabel@citrix.com>
From: Zoltan Kiss <zoltan.kiss@linaro.org>
This flag is unnecessary, it came from some old code.
Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@linaro.org>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
drivers/net/xen-netback/netback.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 25f4c06..730252c 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1550,7 +1550,7 @@ static int xenvif_handle_frag_list(struct xenvif_queue *queue, struct sk_buff *s
unsigned int len;
BUG_ON(i >= MAX_SKB_FRAGS);
- page = alloc_page(GFP_ATOMIC|__GFP_COLD);
+ page = alloc_page(GFP_ATOMIC);
if (!page) {
int j;
skb->truesize += skb->data_len;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] xen-netback: Disable NAPI after disabling interrupts
From: David Vrabel @ 2014-10-28 15:29 UTC (permalink / raw)
To: netdev; +Cc: David Vrabel, xen-devel, Ian Campbell, Wei Liu, Zoltan Kiss
In-Reply-To: <1414510171-12853-1-git-send-email-david.vrabel@citrix.com>
From: Zoltan Kiss <zoltan.kiss@linaro.org>
Otherwise the interrupt handler still calls napi_complete. Although it
won't schedule NAPI again as either NAPI_STATE_DISABLE or
NAPI_STATE_SCHED is set, it is just unnecessary, and it makes more
sense to do this way.
Signed-off-by: Zoltan Kiss <zoltan.kiss@linaro.org>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
drivers/net/xen-netback/interface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 895fe84..a6a32d3 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -235,10 +235,10 @@ static void xenvif_down(struct xenvif *vif)
for (queue_index = 0; queue_index < num_queues; ++queue_index) {
queue = &vif->queues[queue_index];
- napi_disable(&queue->napi);
disable_irq(queue->tx_irq);
if (queue->tx_irq != queue->rx_irq)
disable_irq(queue->rx_irq);
+ napi_disable(&queue->napi);
del_timer_sync(&queue->credit_timeout);
}
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 0/7] seq_printf cleanups
From: Steven Rostedt @ 2014-10-28 15:32 UTC (permalink / raw)
To: Joe Perches
Cc: Al Viro, Petr Mladek, Andrew Morton, Linus Torvalds, linux-doc,
linux-kernel, linux-mtd, netdev, cluster-devel, linux-fsdevel,
netfilter-devel, coreteam
In-Reply-To: <cover.1412031505.git.joe@perches.com>
Joe,
If you haven't already done so, can you update checkpatch.pl to
complain if someone checks the return value of seq_printf(),
seq_puts(), or seq_putc().
It should state that those functions will soon be returning void.
Thanks!
-- Steve
^ permalink raw reply
* Re: some failures with vxlan offloads..
From: Tom Herbert @ 2014-10-28 15:36 UTC (permalink / raw)
To: Or Gerlitz; +Cc: netdev@vger.kernel.org, John Fastabend, Jeff Kirsher
In-Reply-To: <544FB5CA.2060003@mellanox.com>
On Tue, Oct 28, 2014 at 8:27 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
> On 10/27/2014 3:23 AM, Tom Herbert wrote:
>>
>> On Sun, Oct 26, 2014 at 3:23 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>>>
>>> On Sun, Oct 26, 2014 at 5:29 PM, Tom Herbert <therbert@google.com> wrote:
>>>>
>>>> Can you determine what the TSO HW engine is setting in UDP checksum
>>>> field? tcpdump -vv might be able to show this. The symptoms seem to
>>>> indicate that it may not be zero.
>>>
>>> Thanks for the quick response. I'll check what is placed in the UDP
>>> checksum field for packets that went through the offloading HW and let
>>> you know.
>>>
>>> BTW, if following the direction you proposed, I wonder why this works
>>> (e.g the kernel doesn't drops the encapsulated TCP packets) when both
>>> sides are offloaded?
>>>
>> I'm just speculating, but the device may be returning checksum unnecessary
>> for the UDP checksum without actually checking it. Technically, VXLAN
>> RFC7348 allows an implementation to ignore the UDP checksum, although this
>> clearly violates RFC1122 UDP checksum
>> requirements. In the stack we now checksum all non-zero checksums
>> including UDP checksum in VXLAN if it's not marked checksum-unnecessary.
>
>
> OK, I found something (it's always bad habit to try and potentially blame
> someone else for your bugs...) -- as I wrote here earlier, the current HW
> doesn't support checksum generation for both the inner (say TCP) and outer
> (UDP) packet (and indeed we don't advertize SKB_GSO_UDP_TUNNEL_CSUM).
>
> So if we tell them to offload the inner TCP checksum we must **not** tell
> them to attempt and offload the outer checksum too, and I wrongly did
> that... once I stopped doing so, I get mixed configurations (one side
> offloaded the peer not offloaded) to work. I will submit mlx4 fix for that.
>
> I wonder if we have another bug somewhere... when both sides were offloaded,
> it works even with the mlx4 bug, canyou explain that?is it possible that the
> GRO stack somehow covers on the bug when both sides are offloaded and
> GRO/VXLAN comes into play?
>
Look at the receive side. As I mentioned, if the device is returning
checksum-unnecessary and setting csum_level to 1 (inner checksum was
validated) then stack won't try to verify the outer checksum. So in
this case if outer checksum is incorrect nobody complains about it.
> Or.
>
> after the fix, packets sent by the offloaded side (192.168.31.17) carry zero
> udpchecksum
>
> 17:20:44.445866 IP (tos 0x0, ttl 64, id 61275, offset 0, flags [DF], proto
> UDP (17), length 1500)
> 192.168.31.17.45387 > 192.168.31.18.4789: [no cksum] UDP, length 1472
> 0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
> 0x0010: 05dc ef5b 4000 4011 8641 c0a8 1f11 c0a8
> 0x0020: 1f12 b14b 12b5 05c8 0000 0800 0000 0000
> 0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
> 0x0040: 4500 05aa bb84 4000 4006 9055 c0a8 3411
> 0x0050: c0a8 3412 e479 9116 553a e008 f28e 6268
> 0x0060: 5010 0038 88e3 0000 6600 6e65 7470 6572
> 0x0070: 6600 6e65 7470 6572 6600
> 17:20:44.445871 IP (tos 0x0, ttl 64, id 61276, offset 0, flags [DF], proto
> UDP (17), length 1500)
> 192.168.31.17.45387 > 192.168.31.18.4789: [no cksum] UDP, length 1472
> 0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
> 0x0010: 05dc ef5c 4000 4011 8640 c0a8 1f11 c0a8
> 0x0020: 1f12 b14b 12b5 05c8 0000 0800 0000 0000
> 0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
> 0x0040: 4500 05aa bb85 4000 4006 9054 c0a8 3411
> 0x0050: c0a8 3412 e479 9116 553a e58a f28e 6268
> 0x0060: 5010 0038 7afc 0000 6e65 7470 6572 6600
> 0x0070: 6e65 7470 6572 6600 6e65
>
>
> before the fix, packets sent by the offloaded side (192.168.31.17) carry
> junkudpchecksum
>
> Also note that on one of the packets sent by the offloaded part, we don't
> see the "bad udp cksum" scream from tcpdump, which is weird...
>
> 17:03:08.765845 IP (tos 0x0, ttl 64, id 52396, offset 0, flags [DF], proto
> UDP (17), length 746)
> 192.168.31.17.56686 > 192.168.31.18.4789: UDP, length 718
> 0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
> 0x0010: 02ea ccac 4000 4011 abe2 c0a8 1f11 c0a8
> 0x0020: 1f12 dd6e 12b5 02d6 0c1b 0800 0000 0000
> 0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
> 0x0040: 4500 02b8 6357 4000 4006 eb74 c0a8 3411
> 0x0050: c0a8 3412 86f2 3241 d67e f47d e5a9 d041
> 0x0060: 5018 0038 871c 0000 0000 0258 ffff ffff
> 0x0070: 0000 0000 0000 0000 0000
> 17:03:09.336285 IP (tos 0x0, ttl 64, id 52536, offset 0, flags [DF], proto
> UDP (17), length 90)
> 192.168.31.17.56686 > 192.168.31.18.4789: [bad udp cksum 1360!] UDP,
> length 62
> 0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
> 0x0010: 005a cd38 4000 4011 ade6 c0a8 1f11 c0a8
> 0x0020: 1f12 dd6e 12b5 0046 139a 0800 0000 0000
> 0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
> 0x0040: 4500 0028 6358 4000 4006 ee03 c0a8 3411
> 0x0050: c0a8 3412 86f2 3241 d67e f70d e5a9 d041
> 0x0060: 5011 0038 897b 0000
> 17:03:10.335074 IP (tos 0x0, ttl 64, id 40045, offset 0, flags [DF], proto
> UDP (17), length 98)
> 192.168.31.18.48861 > 192.168.31.17.4789: [no cksum] UDP, length 70
> 0x0000: 0002 c9e9 bf32 f452 1401 da82 0800 4500
> 0x0010: 0062 9c6d 4000 4011 dea9 c0a8 1f12 c0a8
> 0x0020: 1f11 bedd 12b5 004e 0000 0800 0000 0000
> 0x0030: 6300 7a83 2ecb 8c68 b2c7 81db e850 0800
> 0x0040: 4500 0030 0000 4000 4006 5154 c0a8 3412
> 0x0050: c0a8 3411 3241 86f2 e5a9 d040 d67e f47d
> 0x0060: 7012 6e28 f282 0000 0204 0582 0103 0307
> 17:03:10.335110 IP (tos 0x0, ttl 64, id 52764, offset 0, flags [DF], proto
> UDP (17), length 90)
> 192.168.31.17.56686 > 192.168.31.18.4789: [bad udp cksum 1360!] UDP,
> length 62
> 0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
> 0x0010: 005a ce1c 4000 4011 ad02 c0a8 1f11 c0a8
> 0x0020: 1f12 dd6e 12b5 0046 139a 0800 0000 0000
> 0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
> 0x0040: 4500 0028 6359 4000 4006 ee02 c0a8 3411
> 0x0050: c0a8 3412 86f2 3241 d67e f70e e5a9 d041
> 0x0060: 5010 0038 897b 0000
>
>
^ permalink raw reply
* [PATCH] wireless: rt2x00: add new rt2800usb device
From: Cyril Brulebois @ 2014-10-28 15:42 UTC (permalink / raw)
To: Stanislaw Gruszka, Helmut Schaa, John W. Linville
Cc: linux-wireless, users, netdev, linux-kernel, Cyril Brulebois,
stable
0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle
References: https://bugs.debian.org/766802
Reported-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
Cc: stable@vger.kernel.org
Signed-off-by: Cyril Brulebois <kibi@debian.org>
---
drivers/net/wireless/rt2x00/rt2800usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 573897b..8444313 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -1111,6 +1111,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
/* Ovislink */
{ USB_DEVICE(0x1b75, 0x3071) },
{ USB_DEVICE(0x1b75, 0x3072) },
+ { USB_DEVICE(0x1b75, 0xa200) },
/* Para */
{ USB_DEVICE(0x20b8, 0x8888) },
/* Pegatron */
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 0/7] seq_printf cleanups
From: Joe Perches @ 2014-10-28 15:51 UTC (permalink / raw)
To: Steven Rostedt
Cc: Al Viro, Petr Mladek, Andrew Morton, Linus Torvalds, linux-doc,
linux-kernel, linux-mtd, netdev, cluster-devel, linux-fsdevel,
netfilter-devel, coreteam
In-Reply-To: <20141028113240.74dbe5c5@gandalf.local.home>
On Tue, 2014-10-28 at 11:32 -0400, Steven Rostedt wrote:
> If you haven't already done so, can you update checkpatch.pl to
> complain if someone checks the return value of seq_printf(),
> seq_puts(), or seq_putc().
I'm not sure that matters much as a rule because I
hope soon the compiler will bleat when that happens.
There are several more too:
seq_vprintf
seq_escape
seq_write
seq_bitmap
seq_cpumask/seq_nodemask (and _list variants),
seq_put_decimal_xxx
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Kevin Fenzi @ 2014-10-28 15:54 UTC (permalink / raw)
To: Yanko Kaneti
Cc: Paul E. McKenney, Jay Vosburgh, Josh Boyer, Eric W. Biederman,
Cong Wang, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj
In-Reply-To: <20141028130002.GA1682@declera.com>
[-- Attachment #1: Type: text/plain, Size: 166 bytes --]
Just FYI, this solves the orig issue for me as well. ;)
Thanks for all the work in tracking it down...
Tested-by: Kevin Fenzi <kevin@scrye.com>
kevin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Paul E. McKenney @ 2014-10-28 16:15 UTC (permalink / raw)
To: Kevin Fenzi
Cc: Yanko Kaneti, Jay Vosburgh, Josh Boyer, Eric W. Biederman,
Cong Wang, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj
In-Reply-To: <20141028095428.15cadd01@voldemort.scrye.com>
On Tue, Oct 28, 2014 at 09:54:28AM -0600, Kevin Fenzi wrote:
> Just FYI, this solves the orig issue for me as well. ;)
>
> Thanks for all the work in tracking it down...
>
> Tested-by: Kevin Fenzi <kevin@scrye.com>
And thank you for testing as well!
Thanx, Paul
^ permalink raw reply
* Re: [PATCH v2] ssb: Fix Sparse error in main
From: Pramod Gurav @ 2014-10-28 16:33 UTC (permalink / raw)
To: Pramod Gurav; +Cc: linux-kernel@vger.kernel.org, Michael Buesch, netdev
In-Reply-To: <1412184482-2603-1-git-send-email-pramod.gurav@smartplayin.com>
Michael had suggested to do away with this function if not being used.
Good to go?
Michale can you provide acked-by?
On Wed, Oct 1, 2014 at 10:58 PM, Pramod Gurav
<pramod.gurav@smartplayin.com> wrote:
> This change fixes below sparse error:
> drivers/ssb/main.c:94:16: warning: symbol 'ssb_sdio_func_to_bus'
> was not declared. Should it be static?
>
> Cc: Michael Buesch <m@bues.ch>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Pramod Gurav <pramod.gurav@smartplayin.com>
> ---
> Changes since v1:
> Removed the function as it is not called anywhere in the kernel
> as per suggestion from Michael Buesch.
>
> drivers/ssb/main.c | 19 -------------------
> 1 file changed, 19 deletions(-)
>
> diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
> index 2fead38..1e180c4 100644
> --- a/drivers/ssb/main.c
> +++ b/drivers/ssb/main.c
> @@ -90,25 +90,6 @@ found:
> }
> #endif /* CONFIG_SSB_PCMCIAHOST */
>
> -#ifdef CONFIG_SSB_SDIOHOST
> -struct ssb_bus *ssb_sdio_func_to_bus(struct sdio_func *func)
> -{
> - struct ssb_bus *bus;
> -
> - ssb_buses_lock();
> - list_for_each_entry(bus, &buses, list) {
> - if (bus->bustype == SSB_BUSTYPE_SDIO &&
> - bus->host_sdio == func)
> - goto found;
> - }
> - bus = NULL;
> -found:
> - ssb_buses_unlock();
> -
> - return bus;
> -}
> -#endif /* CONFIG_SSB_SDIOHOST */
> -
> int ssb_for_each_bus_call(unsigned long data,
> int (*func)(struct ssb_bus *bus, unsigned long data))
> {
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Thanks and Regards
Pramod
^ 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