* [PATCH 3/6] bna: Remove Obsolete File bfi_ctreg.h
From: Rasesh Mody @ 2011-08-01 20:42 UTC (permalink / raw)
To: davem, netdev; +Cc: adapter_linux_open_src_team, Rasesh Mody
In-Reply-To: <1312231375-14398-1-git-send-email-rmody@brocade.com>
Change detail:
- Remove obsolete file bfi_ctreg.h as we added new file bfi_reg.h
consolidating HW reg definitions including the ones for new HW.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
---
drivers/net/bna/bfi_ctreg.h | 646 -------------------------------------------
1 files changed, 0 insertions(+), 646 deletions(-)
delete mode 100644 drivers/net/bna/bfi_ctreg.h
diff --git a/drivers/net/bna/bfi_ctreg.h b/drivers/net/bna/bfi_ctreg.h
deleted file mode 100644
index 5130d79..0000000
--- a/drivers/net/bna/bfi_ctreg.h
+++ /dev/null
@@ -1,646 +0,0 @@
-/*
- * Linux network driver for Brocade Converged Network Adapter.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License (GPL) Version 2 as
- * published by the Free Software Foundation
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- */
-/*
- * Copyright (c) 2005-2010 Brocade Communications Systems, Inc.
- * All rights reserved
- * www.brocade.com
- */
-
-/*
- * bfi_ctreg.h catapult host block register definitions
- *
- * !!! Do not edit. Auto generated. !!!
- */
-
-#ifndef __BFI_CTREG_H__
-#define __BFI_CTREG_H__
-
-#define HOSTFN0_LPU_MBOX0_0 0x00019200
-#define HOSTFN1_LPU_MBOX0_8 0x00019260
-#define LPU_HOSTFN0_MBOX0_0 0x00019280
-#define LPU_HOSTFN1_MBOX0_8 0x000192e0
-#define HOSTFN2_LPU_MBOX0_0 0x00019400
-#define HOSTFN3_LPU_MBOX0_8 0x00019460
-#define LPU_HOSTFN2_MBOX0_0 0x00019480
-#define LPU_HOSTFN3_MBOX0_8 0x000194e0
-#define HOSTFN0_INT_STATUS 0x00014000
-#define __HOSTFN0_HALT_OCCURRED 0x01000000
-#define __HOSTFN0_INT_STATUS_LVL_MK 0x00f00000
-#define __HOSTFN0_INT_STATUS_LVL_SH 20
-#define __HOSTFN0_INT_STATUS_LVL(_v) ((_v) << __HOSTFN0_INT_STATUS_LVL_SH)
-#define __HOSTFN0_INT_STATUS_P_MK 0x000f0000
-#define __HOSTFN0_INT_STATUS_P_SH 16
-#define __HOSTFN0_INT_STATUS_P(_v) ((_v) << __HOSTFN0_INT_STATUS_P_SH)
-#define __HOSTFN0_INT_STATUS_F 0x0000ffff
-#define HOSTFN0_INT_MSK 0x00014004
-#define HOST_PAGE_NUM_FN0 0x00014008
-#define __HOST_PAGE_NUM_FN 0x000001ff
-#define HOST_MSIX_ERR_INDEX_FN0 0x0001400c
-#define __MSIX_ERR_INDEX_FN 0x000001ff
-#define HOSTFN1_INT_STATUS 0x00014100
-#define __HOSTFN1_HALT_OCCURRED 0x01000000
-#define __HOSTFN1_INT_STATUS_LVL_MK 0x00f00000
-#define __HOSTFN1_INT_STATUS_LVL_SH 20
-#define __HOSTFN1_INT_STATUS_LVL(_v) ((_v) << __HOSTFN1_INT_STATUS_LVL_SH)
-#define __HOSTFN1_INT_STATUS_P_MK 0x000f0000
-#define __HOSTFN1_INT_STATUS_P_SH 16
-#define __HOSTFN1_INT_STATUS_P(_v) ((_v) << __HOSTFN1_INT_STATUS_P_SH)
-#define __HOSTFN1_INT_STATUS_F 0x0000ffff
-#define HOSTFN1_INT_MSK 0x00014104
-#define HOST_PAGE_NUM_FN1 0x00014108
-#define HOST_MSIX_ERR_INDEX_FN1 0x0001410c
-#define APP_PLL_425_CTL_REG 0x00014204
-#define __P_425_PLL_LOCK 0x80000000
-#define __APP_PLL_425_SRAM_USE_100MHZ 0x00100000
-#define __APP_PLL_425_RESET_TIMER_MK 0x000e0000
-#define __APP_PLL_425_RESET_TIMER_SH 17
-#define __APP_PLL_425_RESET_TIMER(_v) ((_v) << __APP_PLL_425_RESET_TIMER_SH)
-#define __APP_PLL_425_LOGIC_SOFT_RESET 0x00010000
-#define __APP_PLL_425_CNTLMT0_1_MK 0x0000c000
-#define __APP_PLL_425_CNTLMT0_1_SH 14
-#define __APP_PLL_425_CNTLMT0_1(_v) ((_v) << __APP_PLL_425_CNTLMT0_1_SH)
-#define __APP_PLL_425_JITLMT0_1_MK 0x00003000
-#define __APP_PLL_425_JITLMT0_1_SH 12
-#define __APP_PLL_425_JITLMT0_1(_v) ((_v) << __APP_PLL_425_JITLMT0_1_SH)
-#define __APP_PLL_425_HREF 0x00000800
-#define __APP_PLL_425_HDIV 0x00000400
-#define __APP_PLL_425_P0_1_MK 0x00000300
-#define __APP_PLL_425_P0_1_SH 8
-#define __APP_PLL_425_P0_1(_v) ((_v) << __APP_PLL_425_P0_1_SH)
-#define __APP_PLL_425_Z0_2_MK 0x000000e0
-#define __APP_PLL_425_Z0_2_SH 5
-#define __APP_PLL_425_Z0_2(_v) ((_v) << __APP_PLL_425_Z0_2_SH)
-#define __APP_PLL_425_RSEL200500 0x00000010
-#define __APP_PLL_425_ENARST 0x00000008
-#define __APP_PLL_425_BYPASS 0x00000004
-#define __APP_PLL_425_LRESETN 0x00000002
-#define __APP_PLL_425_ENABLE 0x00000001
-#define APP_PLL_312_CTL_REG 0x00014208
-#define __P_312_PLL_LOCK 0x80000000
-#define __ENABLE_MAC_AHB_1 0x00800000
-#define __ENABLE_MAC_AHB_0 0x00400000
-#define __ENABLE_MAC_1 0x00200000
-#define __ENABLE_MAC_0 0x00100000
-#define __APP_PLL_312_RESET_TIMER_MK 0x000e0000
-#define __APP_PLL_312_RESET_TIMER_SH 17
-#define __APP_PLL_312_RESET_TIMER(_v) ((_v) << __APP_PLL_312_RESET_TIMER_SH)
-#define __APP_PLL_312_LOGIC_SOFT_RESET 0x00010000
-#define __APP_PLL_312_CNTLMT0_1_MK 0x0000c000
-#define __APP_PLL_312_CNTLMT0_1_SH 14
-#define __APP_PLL_312_CNTLMT0_1(_v) ((_v) << __APP_PLL_312_CNTLMT0_1_SH)
-#define __APP_PLL_312_JITLMT0_1_MK 0x00003000
-#define __APP_PLL_312_JITLMT0_1_SH 12
-#define __APP_PLL_312_JITLMT0_1(_v) ((_v) << __APP_PLL_312_JITLMT0_1_SH)
-#define __APP_PLL_312_HREF 0x00000800
-#define __APP_PLL_312_HDIV 0x00000400
-#define __APP_PLL_312_P0_1_MK 0x00000300
-#define __APP_PLL_312_P0_1_SH 8
-#define __APP_PLL_312_P0_1(_v) ((_v) << __APP_PLL_312_P0_1_SH)
-#define __APP_PLL_312_Z0_2_MK 0x000000e0
-#define __APP_PLL_312_Z0_2_SH 5
-#define __APP_PLL_312_Z0_2(_v) ((_v) << __APP_PLL_312_Z0_2_SH)
-#define __APP_PLL_312_RSEL200500 0x00000010
-#define __APP_PLL_312_ENARST 0x00000008
-#define __APP_PLL_312_BYPASS 0x00000004
-#define __APP_PLL_312_LRESETN 0x00000002
-#define __APP_PLL_312_ENABLE 0x00000001
-#define MBIST_CTL_REG 0x00014220
-#define __EDRAM_BISTR_START 0x00000004
-#define __MBIST_RESET 0x00000002
-#define __MBIST_START 0x00000001
-#define MBIST_STAT_REG 0x00014224
-#define __EDRAM_BISTR_STATUS 0x00000008
-#define __EDRAM_BISTR_DONE 0x00000004
-#define __MEM_BIT_STATUS 0x00000002
-#define __MBIST_DONE 0x00000001
-#define HOST_SEM0_REG 0x00014230
-#define __HOST_SEMAPHORE 0x00000001
-#define HOST_SEM1_REG 0x00014234
-#define HOST_SEM2_REG 0x00014238
-#define HOST_SEM3_REG 0x0001423c
-#define HOST_SEM0_INFO_REG 0x00014240
-#define HOST_SEM1_INFO_REG 0x00014244
-#define HOST_SEM2_INFO_REG 0x00014248
-#define HOST_SEM3_INFO_REG 0x0001424c
-#define ETH_MAC_SER_REG 0x00014288
-#define __APP_EMS_CKBUFAMPIN 0x00000020
-#define __APP_EMS_REFCLKSEL 0x00000010
-#define __APP_EMS_CMLCKSEL 0x00000008
-#define __APP_EMS_REFCKBUFEN2 0x00000004
-#define __APP_EMS_REFCKBUFEN1 0x00000002
-#define __APP_EMS_CHANNEL_SEL 0x00000001
-#define HOSTFN2_INT_STATUS 0x00014300
-#define __HOSTFN2_HALT_OCCURRED 0x01000000
-#define __HOSTFN2_INT_STATUS_LVL_MK 0x00f00000
-#define __HOSTFN2_INT_STATUS_LVL_SH 20
-#define __HOSTFN2_INT_STATUS_LVL(_v) ((_v) << __HOSTFN2_INT_STATUS_LVL_SH)
-#define __HOSTFN2_INT_STATUS_P_MK 0x000f0000
-#define __HOSTFN2_INT_STATUS_P_SH 16
-#define __HOSTFN2_INT_STATUS_P(_v) ((_v) << __HOSTFN2_INT_STATUS_P_SH)
-#define __HOSTFN2_INT_STATUS_F 0x0000ffff
-#define HOSTFN2_INT_MSK 0x00014304
-#define HOST_PAGE_NUM_FN2 0x00014308
-#define HOST_MSIX_ERR_INDEX_FN2 0x0001430c
-#define HOSTFN3_INT_STATUS 0x00014400
-#define __HALT_OCCURRED 0x01000000
-#define __HOSTFN3_INT_STATUS_LVL_MK 0x00f00000
-#define __HOSTFN3_INT_STATUS_LVL_SH 20
-#define __HOSTFN3_INT_STATUS_LVL(_v) ((_v) << __HOSTFN3_INT_STATUS_LVL_SH)
-#define __HOSTFN3_INT_STATUS_P_MK 0x000f0000
-#define __HOSTFN3_INT_STATUS_P_SH 16
-#define __HOSTFN3_INT_STATUS_P(_v) ((_v) << __HOSTFN3_INT_STATUS_P_SH)
-#define __HOSTFN3_INT_STATUS_F 0x0000ffff
-#define HOSTFN3_INT_MSK 0x00014404
-#define HOST_PAGE_NUM_FN3 0x00014408
-#define HOST_MSIX_ERR_INDEX_FN3 0x0001440c
-#define FNC_ID_REG 0x00014600
-#define __FUNCTION_NUMBER 0x00000007
-#define FNC_PERS_REG 0x00014604
-#define __F3_FUNCTION_ACTIVE 0x80000000
-#define __F3_FUNCTION_MODE 0x40000000
-#define __F3_PORT_MAP_MK 0x30000000
-#define __F3_PORT_MAP_SH 28
-#define __F3_PORT_MAP(_v) ((_v) << __F3_PORT_MAP_SH)
-#define __F3_VM_MODE 0x08000000
-#define __F3_INTX_STATUS_MK 0x07000000
-#define __F3_INTX_STATUS_SH 24
-#define __F3_INTX_STATUS(_v) ((_v) << __F3_INTX_STATUS_SH)
-#define __F2_FUNCTION_ACTIVE 0x00800000
-#define __F2_FUNCTION_MODE 0x00400000
-#define __F2_PORT_MAP_MK 0x00300000
-#define __F2_PORT_MAP_SH 20
-#define __F2_PORT_MAP(_v) ((_v) << __F2_PORT_MAP_SH)
-#define __F2_VM_MODE 0x00080000
-#define __F2_INTX_STATUS_MK 0x00070000
-#define __F2_INTX_STATUS_SH 16
-#define __F2_INTX_STATUS(_v) ((_v) << __F2_INTX_STATUS_SH)
-#define __F1_FUNCTION_ACTIVE 0x00008000
-#define __F1_FUNCTION_MODE 0x00004000
-#define __F1_PORT_MAP_MK 0x00003000
-#define __F1_PORT_MAP_SH 12
-#define __F1_PORT_MAP(_v) ((_v) << __F1_PORT_MAP_SH)
-#define __F1_VM_MODE 0x00000800
-#define __F1_INTX_STATUS_MK 0x00000700
-#define __F1_INTX_STATUS_SH 8
-#define __F1_INTX_STATUS(_v) ((_v) << __F1_INTX_STATUS_SH)
-#define __F0_FUNCTION_ACTIVE 0x00000080
-#define __F0_FUNCTION_MODE 0x00000040
-#define __F0_PORT_MAP_MK 0x00000030
-#define __F0_PORT_MAP_SH 4
-#define __F0_PORT_MAP(_v) ((_v) << __F0_PORT_MAP_SH)
-#define __F0_VM_MODE 0x00000008
-#define __F0_INTX_STATUS 0x00000007
-enum {
- __F0_INTX_STATUS_MSIX = 0x0,
- __F0_INTX_STATUS_INTA = 0x1,
- __F0_INTX_STATUS_INTB = 0x2,
- __F0_INTX_STATUS_INTC = 0x3,
- __F0_INTX_STATUS_INTD = 0x4,
-};
-#define OP_MODE 0x0001460c
-#define __APP_ETH_CLK_LOWSPEED 0x00000004
-#define __GLOBAL_CORECLK_HALFSPEED 0x00000002
-#define __GLOBAL_FCOE_MODE 0x00000001
-#define HOST_SEM4_REG 0x00014610
-#define HOST_SEM5_REG 0x00014614
-#define HOST_SEM6_REG 0x00014618
-#define HOST_SEM7_REG 0x0001461c
-#define HOST_SEM4_INFO_REG 0x00014620
-#define HOST_SEM5_INFO_REG 0x00014624
-#define HOST_SEM6_INFO_REG 0x00014628
-#define HOST_SEM7_INFO_REG 0x0001462c
-#define HOSTFN0_LPU0_MBOX0_CMD_STAT 0x00019000
-#define __HOSTFN0_LPU0_MBOX0_INFO_MK 0xfffffffe
-#define __HOSTFN0_LPU0_MBOX0_INFO_SH 1
-#define __HOSTFN0_LPU0_MBOX0_INFO(_v) ((_v) << __HOSTFN0_LPU0_MBOX0_INFO_SH)
-#define __HOSTFN0_LPU0_MBOX0_CMD_STATUS 0x00000001
-#define HOSTFN0_LPU1_MBOX0_CMD_STAT 0x00019004
-#define __HOSTFN0_LPU1_MBOX0_INFO_MK 0xfffffffe
-#define __HOSTFN0_LPU1_MBOX0_INFO_SH 1
-#define __HOSTFN0_LPU1_MBOX0_INFO(_v) ((_v) << __HOSTFN0_LPU1_MBOX0_INFO_SH)
-#define __HOSTFN0_LPU1_MBOX0_CMD_STATUS 0x00000001
-#define LPU0_HOSTFN0_MBOX0_CMD_STAT 0x00019008
-#define __LPU0_HOSTFN0_MBOX0_INFO_MK 0xfffffffe
-#define __LPU0_HOSTFN0_MBOX0_INFO_SH 1
-#define __LPU0_HOSTFN0_MBOX0_INFO(_v) ((_v) << __LPU0_HOSTFN0_MBOX0_INFO_SH)
-#define __LPU0_HOSTFN0_MBOX0_CMD_STATUS 0x00000001
-#define LPU1_HOSTFN0_MBOX0_CMD_STAT 0x0001900c
-#define __LPU1_HOSTFN0_MBOX0_INFO_MK 0xfffffffe
-#define __LPU1_HOSTFN0_MBOX0_INFO_SH 1
-#define __LPU1_HOSTFN0_MBOX0_INFO(_v) ((_v) << __LPU1_HOSTFN0_MBOX0_INFO_SH)
-#define __LPU1_HOSTFN0_MBOX0_CMD_STATUS 0x00000001
-#define HOSTFN1_LPU0_MBOX0_CMD_STAT 0x00019010
-#define __HOSTFN1_LPU0_MBOX0_INFO_MK 0xfffffffe
-#define __HOSTFN1_LPU0_MBOX0_INFO_SH 1
-#define __HOSTFN1_LPU0_MBOX0_INFO(_v) ((_v) << __HOSTFN1_LPU0_MBOX0_INFO_SH)
-#define __HOSTFN1_LPU0_MBOX0_CMD_STATUS 0x00000001
-#define HOSTFN1_LPU1_MBOX0_CMD_STAT 0x00019014
-#define __HOSTFN1_LPU1_MBOX0_INFO_MK 0xfffffffe
-#define __HOSTFN1_LPU1_MBOX0_INFO_SH 1
-#define __HOSTFN1_LPU1_MBOX0_INFO(_v) ((_v) << __HOSTFN1_LPU1_MBOX0_INFO_SH)
-#define __HOSTFN1_LPU1_MBOX0_CMD_STATUS 0x00000001
-#define LPU0_HOSTFN1_MBOX0_CMD_STAT 0x00019018
-#define __LPU0_HOSTFN1_MBOX0_INFO_MK 0xfffffffe
-#define __LPU0_HOSTFN1_MBOX0_INFO_SH 1
-#define __LPU0_HOSTFN1_MBOX0_INFO(_v) ((_v) << __LPU0_HOSTFN1_MBOX0_INFO_SH)
-#define __LPU0_HOSTFN1_MBOX0_CMD_STATUS 0x00000001
-#define LPU1_HOSTFN1_MBOX0_CMD_STAT 0x0001901c
-#define __LPU1_HOSTFN1_MBOX0_INFO_MK 0xfffffffe
-#define __LPU1_HOSTFN1_MBOX0_INFO_SH 1
-#define __LPU1_HOSTFN1_MBOX0_INFO(_v) ((_v) << __LPU1_HOSTFN1_MBOX0_INFO_SH)
-#define __LPU1_HOSTFN1_MBOX0_CMD_STATUS 0x00000001
-#define HOSTFN2_LPU0_MBOX0_CMD_STAT 0x00019150
-#define __HOSTFN2_LPU0_MBOX0_INFO_MK 0xfffffffe
-#define __HOSTFN2_LPU0_MBOX0_INFO_SH 1
-#define __HOSTFN2_LPU0_MBOX0_INFO(_v) ((_v) << __HOSTFN2_LPU0_MBOX0_INFO_SH)
-#define __HOSTFN2_LPU0_MBOX0_CMD_STATUS 0x00000001
-#define HOSTFN2_LPU1_MBOX0_CMD_STAT 0x00019154
-#define __HOSTFN2_LPU1_MBOX0_INFO_MK 0xfffffffe
-#define __HOSTFN2_LPU1_MBOX0_INFO_SH 1
-#define __HOSTFN2_LPU1_MBOX0_INFO(_v) ((_v) << __HOSTFN2_LPU1_MBOX0_INFO_SH)
-#define __HOSTFN2_LPU1_MBOX0BOX0_CMD_STATUS 0x00000001
-#define LPU0_HOSTFN2_MBOX0_CMD_STAT 0x00019158
-#define __LPU0_HOSTFN2_MBOX0_INFO_MK 0xfffffffe
-#define __LPU0_HOSTFN2_MBOX0_INFO_SH 1
-#define __LPU0_HOSTFN2_MBOX0_INFO(_v) ((_v) << __LPU0_HOSTFN2_MBOX0_INFO_SH)
-#define __LPU0_HOSTFN2_MBOX0_CMD_STATUS 0x00000001
-#define LPU1_HOSTFN2_MBOX0_CMD_STAT 0x0001915c
-#define __LPU1_HOSTFN2_MBOX0_INFO_MK 0xfffffffe
-#define __LPU1_HOSTFN2_MBOX0_INFO_SH 1
-#define __LPU1_HOSTFN2_MBOX0_INFO(_v) ((_v) << __LPU1_HOSTFN2_MBOX0_INFO_SH)
-#define __LPU1_HOSTFN2_MBOX0_CMD_STATUS 0x00000001
-#define HOSTFN3_LPU0_MBOX0_CMD_STAT 0x00019160
-#define __HOSTFN3_LPU0_MBOX0_INFO_MK 0xfffffffe
-#define __HOSTFN3_LPU0_MBOX0_INFO_SH 1
-#define __HOSTFN3_LPU0_MBOX0_INFO(_v) ((_v) << __HOSTFN3_LPU0_MBOX0_INFO_SH)
-#define __HOSTFN3_LPU0_MBOX0_CMD_STATUS 0x00000001
-#define HOSTFN3_LPU1_MBOX0_CMD_STAT 0x00019164
-#define __HOSTFN3_LPU1_MBOX0_INFO_MK 0xfffffffe
-#define __HOSTFN3_LPU1_MBOX0_INFO_SH 1
-#define __HOSTFN3_LPU1_MBOX0_INFO(_v) ((_v) << __HOSTFN3_LPU1_MBOX0_INFO_SH)
-#define __HOSTFN3_LPU1_MBOX0_CMD_STATUS 0x00000001
-#define LPU0_HOSTFN3_MBOX0_CMD_STAT 0x00019168
-#define __LPU0_HOSTFN3_MBOX0_INFO_MK 0xfffffffe
-#define __LPU0_HOSTFN3_MBOX0_INFO_SH 1
-#define __LPU0_HOSTFN3_MBOX0_INFO(_v) ((_v) << __LPU0_HOSTFN3_MBOX0_INFO_SH)
-#define __LPU0_HOSTFN3_MBOX0_CMD_STATUS 0x00000001
-#define LPU1_HOSTFN3_MBOX0_CMD_STAT 0x0001916c
-#define __LPU1_HOSTFN3_MBOX0_INFO_MK 0xfffffffe
-#define __LPU1_HOSTFN3_MBOX0_INFO_SH 1
-#define __LPU1_HOSTFN3_MBOX0_INFO(_v) ((_v) << __LPU1_HOSTFN3_MBOX0_INFO_SH)
-#define __LPU1_HOSTFN3_MBOX0_CMD_STATUS 0x00000001
-#define FW_INIT_HALT_P0 0x000191ac
-#define __FW_INIT_HALT_P 0x00000001
-#define FW_INIT_HALT_P1 0x000191bc
-#define CPE_PI_PTR_Q0 0x00038000
-#define __CPE_PI_UNUSED_MK 0xffff0000
-#define __CPE_PI_UNUSED_SH 16
-#define __CPE_PI_UNUSED(_v) ((_v) << __CPE_PI_UNUSED_SH)
-#define __CPE_PI_PTR 0x0000ffff
-#define CPE_PI_PTR_Q1 0x00038040
-#define CPE_CI_PTR_Q0 0x00038004
-#define __CPE_CI_UNUSED_MK 0xffff0000
-#define __CPE_CI_UNUSED_SH 16
-#define __CPE_CI_UNUSED(_v) ((_v) << __CPE_CI_UNUSED_SH)
-#define __CPE_CI_PTR 0x0000ffff
-#define CPE_CI_PTR_Q1 0x00038044
-#define CPE_DEPTH_Q0 0x00038008
-#define __CPE_DEPTH_UNUSED_MK 0xf8000000
-#define __CPE_DEPTH_UNUSED_SH 27
-#define __CPE_DEPTH_UNUSED(_v) ((_v) << __CPE_DEPTH_UNUSED_SH)
-#define __CPE_MSIX_VEC_INDEX_MK 0x07ff0000
-#define __CPE_MSIX_VEC_INDEX_SH 16
-#define __CPE_MSIX_VEC_INDEX(_v) ((_v) << __CPE_MSIX_VEC_INDEX_SH)
-#define __CPE_DEPTH 0x0000ffff
-#define CPE_DEPTH_Q1 0x00038048
-#define CPE_QCTRL_Q0 0x0003800c
-#define __CPE_CTRL_UNUSED30_MK 0xfc000000
-#define __CPE_CTRL_UNUSED30_SH 26
-#define __CPE_CTRL_UNUSED30(_v) ((_v) << __CPE_CTRL_UNUSED30_SH)
-#define __CPE_FUNC_INT_CTRL_MK 0x03000000
-#define __CPE_FUNC_INT_CTRL_SH 24
-#define __CPE_FUNC_INT_CTRL(_v) ((_v) << __CPE_FUNC_INT_CTRL_SH)
-enum {
- __CPE_FUNC_INT_CTRL_DISABLE = 0x0,
- __CPE_FUNC_INT_CTRL_F2NF = 0x1,
- __CPE_FUNC_INT_CTRL_3QUART = 0x2,
- __CPE_FUNC_INT_CTRL_HALF = 0x3,
-};
-#define __CPE_CTRL_UNUSED20_MK 0x00f00000
-#define __CPE_CTRL_UNUSED20_SH 20
-#define __CPE_CTRL_UNUSED20(_v) ((_v) << __CPE_CTRL_UNUSED20_SH)
-#define __CPE_SCI_TH_MK 0x000f0000
-#define __CPE_SCI_TH_SH 16
-#define __CPE_SCI_TH(_v) ((_v) << __CPE_SCI_TH_SH)
-#define __CPE_CTRL_UNUSED10_MK 0x0000c000
-#define __CPE_CTRL_UNUSED10_SH 14
-#define __CPE_CTRL_UNUSED10(_v) ((_v) << __CPE_CTRL_UNUSED10_SH)
-#define __CPE_ACK_PENDING 0x00002000
-#define __CPE_CTRL_UNUSED40_MK 0x00001c00
-#define __CPE_CTRL_UNUSED40_SH 10
-#define __CPE_CTRL_UNUSED40(_v) ((_v) << __CPE_CTRL_UNUSED40_SH)
-#define __CPE_PCIEID_MK 0x00000300
-#define __CPE_PCIEID_SH 8
-#define __CPE_PCIEID(_v) ((_v) << __CPE_PCIEID_SH)
-#define __CPE_CTRL_UNUSED00_MK 0x000000fe
-#define __CPE_CTRL_UNUSED00_SH 1
-#define __CPE_CTRL_UNUSED00(_v) ((_v) << __CPE_CTRL_UNUSED00_SH)
-#define __CPE_ESIZE 0x00000001
-#define CPE_QCTRL_Q1 0x0003804c
-#define __CPE_CTRL_UNUSED31_MK 0xfc000000
-#define __CPE_CTRL_UNUSED31_SH 26
-#define __CPE_CTRL_UNUSED31(_v) ((_v) << __CPE_CTRL_UNUSED31_SH)
-#define __CPE_CTRL_UNUSED21_MK 0x00f00000
-#define __CPE_CTRL_UNUSED21_SH 20
-#define __CPE_CTRL_UNUSED21(_v) ((_v) << __CPE_CTRL_UNUSED21_SH)
-#define __CPE_CTRL_UNUSED11_MK 0x0000c000
-#define __CPE_CTRL_UNUSED11_SH 14
-#define __CPE_CTRL_UNUSED11(_v) ((_v) << __CPE_CTRL_UNUSED11_SH)
-#define __CPE_CTRL_UNUSED41_MK 0x00001c00
-#define __CPE_CTRL_UNUSED41_SH 10
-#define __CPE_CTRL_UNUSED41(_v) ((_v) << __CPE_CTRL_UNUSED41_SH)
-#define __CPE_CTRL_UNUSED01_MK 0x000000fe
-#define __CPE_CTRL_UNUSED01_SH 1
-#define __CPE_CTRL_UNUSED01(_v) ((_v) << __CPE_CTRL_UNUSED01_SH)
-#define RME_PI_PTR_Q0 0x00038020
-#define __LATENCY_TIME_STAMP_MK 0xffff0000
-#define __LATENCY_TIME_STAMP_SH 16
-#define __LATENCY_TIME_STAMP(_v) ((_v) << __LATENCY_TIME_STAMP_SH)
-#define __RME_PI_PTR 0x0000ffff
-#define RME_PI_PTR_Q1 0x00038060
-#define RME_CI_PTR_Q0 0x00038024
-#define __DELAY_TIME_STAMP_MK 0xffff0000
-#define __DELAY_TIME_STAMP_SH 16
-#define __DELAY_TIME_STAMP(_v) ((_v) << __DELAY_TIME_STAMP_SH)
-#define __RME_CI_PTR 0x0000ffff
-#define RME_CI_PTR_Q1 0x00038064
-#define RME_DEPTH_Q0 0x00038028
-#define __RME_DEPTH_UNUSED_MK 0xf8000000
-#define __RME_DEPTH_UNUSED_SH 27
-#define __RME_DEPTH_UNUSED(_v) ((_v) << __RME_DEPTH_UNUSED_SH)
-#define __RME_MSIX_VEC_INDEX_MK 0x07ff0000
-#define __RME_MSIX_VEC_INDEX_SH 16
-#define __RME_MSIX_VEC_INDEX(_v) ((_v) << __RME_MSIX_VEC_INDEX_SH)
-#define __RME_DEPTH 0x0000ffff
-#define RME_DEPTH_Q1 0x00038068
-#define RME_QCTRL_Q0 0x0003802c
-#define __RME_INT_LATENCY_TIMER_MK 0xff000000
-#define __RME_INT_LATENCY_TIMER_SH 24
-#define __RME_INT_LATENCY_TIMER(_v) ((_v) << __RME_INT_LATENCY_TIMER_SH)
-#define __RME_INT_DELAY_TIMER_MK 0x00ff0000
-#define __RME_INT_DELAY_TIMER_SH 16
-#define __RME_INT_DELAY_TIMER(_v) ((_v) << __RME_INT_DELAY_TIMER_SH)
-#define __RME_INT_DELAY_DISABLE 0x00008000
-#define __RME_DLY_DELAY_DISABLE 0x00004000
-#define __RME_ACK_PENDING 0x00002000
-#define __RME_FULL_INTERRUPT_DISABLE 0x00001000
-#define __RME_CTRL_UNUSED10_MK 0x00000c00
-#define __RME_CTRL_UNUSED10_SH 10
-#define __RME_CTRL_UNUSED10(_v) ((_v) << __RME_CTRL_UNUSED10_SH)
-#define __RME_PCIEID_MK 0x00000300
-#define __RME_PCIEID_SH 8
-#define __RME_PCIEID(_v) ((_v) << __RME_PCIEID_SH)
-#define __RME_CTRL_UNUSED00_MK 0x000000fe
-#define __RME_CTRL_UNUSED00_SH 1
-#define __RME_CTRL_UNUSED00(_v) ((_v) << __RME_CTRL_UNUSED00_SH)
-#define __RME_ESIZE 0x00000001
-#define RME_QCTRL_Q1 0x0003806c
-#define __RME_CTRL_UNUSED11_MK 0x00000c00
-#define __RME_CTRL_UNUSED11_SH 10
-#define __RME_CTRL_UNUSED11(_v) ((_v) << __RME_CTRL_UNUSED11_SH)
-#define __RME_CTRL_UNUSED01_MK 0x000000fe
-#define __RME_CTRL_UNUSED01_SH 1
-#define __RME_CTRL_UNUSED01(_v) ((_v) << __RME_CTRL_UNUSED01_SH)
-#define PSS_CTL_REG 0x00018800
-#define __PSS_I2C_CLK_DIV_MK 0x007f0000
-#define __PSS_I2C_CLK_DIV_SH 16
-#define __PSS_I2C_CLK_DIV(_v) ((_v) << __PSS_I2C_CLK_DIV_SH)
-#define __PSS_LMEM_INIT_DONE 0x00001000
-#define __PSS_LMEM_RESET 0x00000200
-#define __PSS_LMEM_INIT_EN 0x00000100
-#define __PSS_LPU1_RESET 0x00000002
-#define __PSS_LPU0_RESET 0x00000001
-#define PSS_ERR_STATUS_REG 0x00018810
-#define __PSS_LPU1_TCM_READ_ERR 0x00200000
-#define __PSS_LPU0_TCM_READ_ERR 0x00100000
-#define __PSS_LMEM5_CORR_ERR 0x00080000
-#define __PSS_LMEM4_CORR_ERR 0x00040000
-#define __PSS_LMEM3_CORR_ERR 0x00020000
-#define __PSS_LMEM2_CORR_ERR 0x00010000
-#define __PSS_LMEM1_CORR_ERR 0x00008000
-#define __PSS_LMEM0_CORR_ERR 0x00004000
-#define __PSS_LMEM5_UNCORR_ERR 0x00002000
-#define __PSS_LMEM4_UNCORR_ERR 0x00001000
-#define __PSS_LMEM3_UNCORR_ERR 0x00000800
-#define __PSS_LMEM2_UNCORR_ERR 0x00000400
-#define __PSS_LMEM1_UNCORR_ERR 0x00000200
-#define __PSS_LMEM0_UNCORR_ERR 0x00000100
-#define __PSS_BAL_PERR 0x00000080
-#define __PSS_DIP_IF_ERR 0x00000040
-#define __PSS_IOH_IF_ERR 0x00000020
-#define __PSS_TDS_IF_ERR 0x00000010
-#define __PSS_RDS_IF_ERR 0x00000008
-#define __PSS_SGM_IF_ERR 0x00000004
-#define __PSS_LPU1_RAM_ERR 0x00000002
-#define __PSS_LPU0_RAM_ERR 0x00000001
-#define ERR_SET_REG 0x00018818
-#define __PSS_ERR_STATUS_SET 0x003fffff
-#define PMM_1T_RESET_REG_P0 0x0002381c
-#define __PMM_1T_RESET_P 0x00000001
-#define PMM_1T_RESET_REG_P1 0x00023c1c
-#define HQM_QSET0_RXQ_DRBL_P0 0x00038000
-#define __RXQ0_ADD_VECTORS_P 0x80000000
-#define __RXQ0_STOP_P 0x40000000
-#define __RXQ0_PRD_PTR_P 0x0000ffff
-#define HQM_QSET1_RXQ_DRBL_P0 0x00038080
-#define __RXQ1_ADD_VECTORS_P 0x80000000
-#define __RXQ1_STOP_P 0x40000000
-#define __RXQ1_PRD_PTR_P 0x0000ffff
-#define HQM_QSET0_RXQ_DRBL_P1 0x0003c000
-#define HQM_QSET1_RXQ_DRBL_P1 0x0003c080
-#define HQM_QSET0_TXQ_DRBL_P0 0x00038020
-#define __TXQ0_ADD_VECTORS_P 0x80000000
-#define __TXQ0_STOP_P 0x40000000
-#define __TXQ0_PRD_PTR_P 0x0000ffff
-#define HQM_QSET1_TXQ_DRBL_P0 0x000380a0
-#define __TXQ1_ADD_VECTORS_P 0x80000000
-#define __TXQ1_STOP_P 0x40000000
-#define __TXQ1_PRD_PTR_P 0x0000ffff
-#define HQM_QSET0_TXQ_DRBL_P1 0x0003c020
-#define HQM_QSET1_TXQ_DRBL_P1 0x0003c0a0
-#define HQM_QSET0_IB_DRBL_1_P0 0x00038040
-#define __IB1_0_ACK_P 0x80000000
-#define __IB1_0_DISABLE_P 0x40000000
-#define __IB1_0_COALESCING_CFG_P_MK 0x00ff0000
-#define __IB1_0_COALESCING_CFG_P_SH 16
-#define __IB1_0_COALESCING_CFG_P(_v) ((_v) << __IB1_0_COALESCING_CFG_P_SH)
-#define __IB1_0_NUM_OF_ACKED_EVENTS_P 0x0000ffff
-#define HQM_QSET1_IB_DRBL_1_P0 0x000380c0
-#define __IB1_1_ACK_P 0x80000000
-#define __IB1_1_DISABLE_P 0x40000000
-#define __IB1_1_COALESCING_CFG_P_MK 0x00ff0000
-#define __IB1_1_COALESCING_CFG_P_SH 16
-#define __IB1_1_COALESCING_CFG_P(_v) ((_v) << __IB1_1_COALESCING_CFG_P_SH)
-#define __IB1_1_NUM_OF_ACKED_EVENTS_P 0x0000ffff
-#define HQM_QSET0_IB_DRBL_1_P1 0x0003c040
-#define HQM_QSET1_IB_DRBL_1_P1 0x0003c0c0
-#define HQM_QSET0_IB_DRBL_2_P0 0x00038060
-#define __IB2_0_ACK_P 0x80000000
-#define __IB2_0_DISABLE_P 0x40000000
-#define __IB2_0_COALESCING_CFG_P_MK 0x00ff0000
-#define __IB2_0_COALESCING_CFG_P_SH 16
-#define __IB2_0_COALESCING_CFG_P(_v) ((_v) << __IB2_0_COALESCING_CFG_P_SH)
-#define __IB2_0_NUM_OF_ACKED_EVENTS_P 0x0000ffff
-#define HQM_QSET1_IB_DRBL_2_P0 0x000380e0
-#define __IB2_1_ACK_P 0x80000000
-#define __IB2_1_DISABLE_P 0x40000000
-#define __IB2_1_COALESCING_CFG_P_MK 0x00ff0000
-#define __IB2_1_COALESCING_CFG_P_SH 16
-#define __IB2_1_COALESCING_CFG_P(_v) ((_v) << __IB2_1_COALESCING_CFG_P_SH)
-#define __IB2_1_NUM_OF_ACKED_EVENTS_P 0x0000ffff
-#define HQM_QSET0_IB_DRBL_2_P1 0x0003c060
-#define HQM_QSET1_IB_DRBL_2_P1 0x0003c0e0
-
-/*
- * These definitions are either in error/missing in spec. Its auto-generated
- * from hard coded values in regparse.pl.
- */
-#define __EMPHPOST_AT_4G_MK_FIX 0x0000001c
-#define __EMPHPOST_AT_4G_SH_FIX 0x00000002
-#define __EMPHPRE_AT_4G_FIX 0x00000003
-#define __SFP_TXRATE_EN_FIX 0x00000100
-#define __SFP_RXRATE_EN_FIX 0x00000080
-
-/*
- * These register definitions are auto-generated from hard coded values
- * in regparse.pl.
- */
-
-/*
- * These register mapping definitions are auto-generated from mapping tables
- * in regparse.pl.
- */
-#define BFA_IOC0_HBEAT_REG HOST_SEM0_INFO_REG
-#define BFA_IOC0_STATE_REG HOST_SEM1_INFO_REG
-#define BFA_IOC1_HBEAT_REG HOST_SEM2_INFO_REG
-#define BFA_IOC1_STATE_REG HOST_SEM3_INFO_REG
-#define BFA_FW_USE_COUNT HOST_SEM4_INFO_REG
-#define BFA_IOC_FAIL_SYNC HOST_SEM5_INFO_REG
-
-#define CPE_DEPTH_Q(__n) \
- (CPE_DEPTH_Q0 + (__n) * (CPE_DEPTH_Q1 - CPE_DEPTH_Q0))
-#define CPE_QCTRL_Q(__n) \
- (CPE_QCTRL_Q0 + (__n) * (CPE_QCTRL_Q1 - CPE_QCTRL_Q0))
-#define CPE_PI_PTR_Q(__n) \
- (CPE_PI_PTR_Q0 + (__n) * (CPE_PI_PTR_Q1 - CPE_PI_PTR_Q0))
-#define CPE_CI_PTR_Q(__n) \
- (CPE_CI_PTR_Q0 + (__n) * (CPE_CI_PTR_Q1 - CPE_CI_PTR_Q0))
-#define RME_DEPTH_Q(__n) \
- (RME_DEPTH_Q0 + (__n) * (RME_DEPTH_Q1 - RME_DEPTH_Q0))
-#define RME_QCTRL_Q(__n) \
- (RME_QCTRL_Q0 + (__n) * (RME_QCTRL_Q1 - RME_QCTRL_Q0))
-#define RME_PI_PTR_Q(__n) \
- (RME_PI_PTR_Q0 + (__n) * (RME_PI_PTR_Q1 - RME_PI_PTR_Q0))
-#define RME_CI_PTR_Q(__n) \
- (RME_CI_PTR_Q0 + (__n) * (RME_CI_PTR_Q1 - RME_CI_PTR_Q0))
-#define HQM_QSET_RXQ_DRBL_P0(__n) \
- (HQM_QSET0_RXQ_DRBL_P0 + (__n) * \
- (HQM_QSET1_RXQ_DRBL_P0 - HQM_QSET0_RXQ_DRBL_P0))
-#define HQM_QSET_TXQ_DRBL_P0(__n) \
- (HQM_QSET0_TXQ_DRBL_P0 + (__n) * \
- (HQM_QSET1_TXQ_DRBL_P0 - HQM_QSET0_TXQ_DRBL_P0))
-#define HQM_QSET_IB_DRBL_1_P0(__n) \
- (HQM_QSET0_IB_DRBL_1_P0 + (__n) * \
- (HQM_QSET1_IB_DRBL_1_P0 - HQM_QSET0_IB_DRBL_1_P0))
-#define HQM_QSET_IB_DRBL_2_P0(__n) \
- (HQM_QSET0_IB_DRBL_2_P0 + (__n) * \
- (HQM_QSET1_IB_DRBL_2_P0 - HQM_QSET0_IB_DRBL_2_P0))
-#define HQM_QSET_RXQ_DRBL_P1(__n) \
- (HQM_QSET0_RXQ_DRBL_P1 + (__n) * \
- (HQM_QSET1_RXQ_DRBL_P1 - HQM_QSET0_RXQ_DRBL_P1))
-#define HQM_QSET_TXQ_DRBL_P1(__n) \
- (HQM_QSET0_TXQ_DRBL_P1 + (__n) * \
- (HQM_QSET1_TXQ_DRBL_P1 - HQM_QSET0_TXQ_DRBL_P1))
-#define HQM_QSET_IB_DRBL_1_P1(__n) \
- (HQM_QSET0_IB_DRBL_1_P1 + (__n) * \
- (HQM_QSET1_IB_DRBL_1_P1 - HQM_QSET0_IB_DRBL_1_P1))
-#define HQM_QSET_IB_DRBL_2_P1(__n) \
- (HQM_QSET0_IB_DRBL_2_P1 + (__n) * \
- (HQM_QSET1_IB_DRBL_2_P1 - HQM_QSET0_IB_DRBL_2_P1))
-
-#define CPE_Q_NUM(__fn, __q) (((__fn) << 2) + (__q))
-#define RME_Q_NUM(__fn, __q) (((__fn) << 2) + (__q))
-#define CPE_Q_MASK(__q) ((__q) & 0x3)
-#define RME_Q_MASK(__q) ((__q) & 0x3)
-
-/*
- * PCI MSI-X vector defines
- */
-enum {
- BFA_MSIX_CPE_Q0 = 0,
- BFA_MSIX_CPE_Q1 = 1,
- BFA_MSIX_CPE_Q2 = 2,
- BFA_MSIX_CPE_Q3 = 3,
- BFA_MSIX_RME_Q0 = 4,
- BFA_MSIX_RME_Q1 = 5,
- BFA_MSIX_RME_Q2 = 6,
- BFA_MSIX_RME_Q3 = 7,
- BFA_MSIX_LPU_ERR = 8,
- BFA_MSIX_CT_MAX = 9,
-};
-
-/*
- * And corresponding host interrupt status bit field defines
- */
-#define __HFN_INT_CPE_Q0 0x00000001U
-#define __HFN_INT_CPE_Q1 0x00000002U
-#define __HFN_INT_CPE_Q2 0x00000004U
-#define __HFN_INT_CPE_Q3 0x00000008U
-#define __HFN_INT_CPE_Q4 0x00000010U
-#define __HFN_INT_CPE_Q5 0x00000020U
-#define __HFN_INT_CPE_Q6 0x00000040U
-#define __HFN_INT_CPE_Q7 0x00000080U
-#define __HFN_INT_RME_Q0 0x00000100U
-#define __HFN_INT_RME_Q1 0x00000200U
-#define __HFN_INT_RME_Q2 0x00000400U
-#define __HFN_INT_RME_Q3 0x00000800U
-#define __HFN_INT_RME_Q4 0x00001000U
-#define __HFN_INT_RME_Q5 0x00002000U
-#define __HFN_INT_RME_Q6 0x00004000U
-#define __HFN_INT_RME_Q7 0x00008000U
-#define __HFN_INT_ERR_EMC 0x00010000U
-#define __HFN_INT_ERR_LPU0 0x00020000U
-#define __HFN_INT_ERR_LPU1 0x00040000U
-#define __HFN_INT_ERR_PSS 0x00080000U
-#define __HFN_INT_MBOX_LPU0 0x00100000U
-#define __HFN_INT_MBOX_LPU1 0x00200000U
-#define __HFN_INT_MBOX1_LPU0 0x00400000U
-#define __HFN_INT_MBOX1_LPU1 0x00800000U
-#define __HFN_INT_LL_HALT 0x01000000U
-#define __HFN_INT_CPE_MASK 0x000000ffU
-#define __HFN_INT_RME_MASK 0x0000ff00U
-
-/*
- * catapult memory map.
- */
-#define LL_PGN_HQM0 0x0096
-#define LL_PGN_HQM1 0x0097
-#define PSS_SMEM_PAGE_START 0x8000
-#define PSS_SMEM_PGNUM(_pg0, _ma) ((_pg0) + ((_ma) >> 15))
-#define PSS_SMEM_PGOFF(_ma) ((_ma) & 0x7fff)
-
-/*
- * End of catapult memory map
- */
-
-#endif /* __BFI_CTREG_H__ */
--
1.7.1
^ permalink raw reply related
* [PATCH 1/6] bna: Remove get_regs Ethtool Support
From: Rasesh Mody @ 2011-08-01 20:42 UTC (permalink / raw)
To: davem, netdev; +Cc: adapter_linux_open_src_team, Rasesh Mody
In-Reply-To: <1312231375-14398-1-git-send-email-rmody@brocade.com>
Change details:
- This patch contains removal of get_regs support in bnad_ethtool.c. Thus
BNA will have minimal register definitions necessary for MBOX and
interrupt operations
Signed-off-by: Rasesh Mody <rmody@brocade.com>
---
drivers/net/bna/bnad_ethtool.c | 319 ----------------------------------------
1 files changed, 0 insertions(+), 319 deletions(-)
diff --git a/drivers/net/bna/bnad_ethtool.c b/drivers/net/bna/bnad_ethtool.c
index fea07f1..49174f8 100644
--- a/drivers/net/bna/bnad_ethtool.c
+++ b/drivers/net/bna/bnad_ethtool.c
@@ -288,323 +288,6 @@ bnad_get_drvinfo(struct net_device *netdev, struct ethtool_drvinfo *drvinfo)
strncpy(drvinfo->bus_info, pci_name(bnad->pcidev), ETHTOOL_BUSINFO_LEN);
}
-static int
-get_regs(struct bnad *bnad, u32 * regs)
-{
- int num = 0, i;
- u32 reg_addr;
- unsigned long flags;
-
-#define BNAD_GET_REG(addr) \
-do { \
- if (regs) \
- regs[num++] = readl(bnad->bar0 + (addr)); \
- else \
- num++; \
-} while (0)
-
- spin_lock_irqsave(&bnad->bna_lock, flags);
-
- /* DMA Block Internal Registers */
- BNAD_GET_REG(DMA_CTRL_REG0);
- BNAD_GET_REG(DMA_CTRL_REG1);
- BNAD_GET_REG(DMA_ERR_INT_STATUS);
- BNAD_GET_REG(DMA_ERR_INT_ENABLE);
- BNAD_GET_REG(DMA_ERR_INT_STATUS_SET);
-
- /* APP Block Register Address Offset from BAR0 */
- BNAD_GET_REG(HOSTFN0_INT_STATUS);
- BNAD_GET_REG(HOSTFN0_INT_MASK);
- BNAD_GET_REG(HOST_PAGE_NUM_FN0);
- BNAD_GET_REG(HOST_MSIX_ERR_INDEX_FN0);
- BNAD_GET_REG(FN0_PCIE_ERR_REG);
- BNAD_GET_REG(FN0_ERR_TYPE_STATUS_REG);
- BNAD_GET_REG(FN0_ERR_TYPE_MSK_STATUS_REG);
-
- BNAD_GET_REG(HOSTFN1_INT_STATUS);
- BNAD_GET_REG(HOSTFN1_INT_MASK);
- BNAD_GET_REG(HOST_PAGE_NUM_FN1);
- BNAD_GET_REG(HOST_MSIX_ERR_INDEX_FN1);
- BNAD_GET_REG(FN1_PCIE_ERR_REG);
- BNAD_GET_REG(FN1_ERR_TYPE_STATUS_REG);
- BNAD_GET_REG(FN1_ERR_TYPE_MSK_STATUS_REG);
-
- BNAD_GET_REG(PCIE_MISC_REG);
-
- BNAD_GET_REG(HOST_SEM0_INFO_REG);
- BNAD_GET_REG(HOST_SEM1_INFO_REG);
- BNAD_GET_REG(HOST_SEM2_INFO_REG);
- BNAD_GET_REG(HOST_SEM3_INFO_REG);
-
- BNAD_GET_REG(TEMPSENSE_CNTL_REG);
- BNAD_GET_REG(TEMPSENSE_STAT_REG);
-
- BNAD_GET_REG(APP_LOCAL_ERR_STAT);
- BNAD_GET_REG(APP_LOCAL_ERR_MSK);
-
- BNAD_GET_REG(PCIE_LNK_ERR_STAT);
- BNAD_GET_REG(PCIE_LNK_ERR_MSK);
-
- BNAD_GET_REG(FCOE_FIP_ETH_TYPE);
- BNAD_GET_REG(RESV_ETH_TYPE);
-
- BNAD_GET_REG(HOSTFN2_INT_STATUS);
- BNAD_GET_REG(HOSTFN2_INT_MASK);
- BNAD_GET_REG(HOST_PAGE_NUM_FN2);
- BNAD_GET_REG(HOST_MSIX_ERR_INDEX_FN2);
- BNAD_GET_REG(FN2_PCIE_ERR_REG);
- BNAD_GET_REG(FN2_ERR_TYPE_STATUS_REG);
- BNAD_GET_REG(FN2_ERR_TYPE_MSK_STATUS_REG);
-
- BNAD_GET_REG(HOSTFN3_INT_STATUS);
- BNAD_GET_REG(HOSTFN3_INT_MASK);
- BNAD_GET_REG(HOST_PAGE_NUM_FN3);
- BNAD_GET_REG(HOST_MSIX_ERR_INDEX_FN3);
- BNAD_GET_REG(FN3_PCIE_ERR_REG);
- BNAD_GET_REG(FN3_ERR_TYPE_STATUS_REG);
- BNAD_GET_REG(FN3_ERR_TYPE_MSK_STATUS_REG);
-
- /* Host Command Status Registers */
- reg_addr = HOST_CMDSTS0_CLR_REG;
- for (i = 0; i < 16; i++) {
- BNAD_GET_REG(reg_addr);
- BNAD_GET_REG(reg_addr + 4);
- BNAD_GET_REG(reg_addr + 8);
- reg_addr += 0x10;
- }
-
- /* Function ID register */
- BNAD_GET_REG(FNC_ID_REG);
-
- /* Function personality register */
- BNAD_GET_REG(FNC_PERS_REG);
-
- /* Operation mode register */
- BNAD_GET_REG(OP_MODE);
-
- /* LPU0 Registers */
- BNAD_GET_REG(LPU0_MBOX_CTL_REG);
- BNAD_GET_REG(LPU0_MBOX_CMD_REG);
- BNAD_GET_REG(LPU0_MBOX_LINK_0REG);
- BNAD_GET_REG(LPU1_MBOX_LINK_0REG);
- BNAD_GET_REG(LPU0_MBOX_STATUS_0REG);
- BNAD_GET_REG(LPU1_MBOX_STATUS_0REG);
- BNAD_GET_REG(LPU0_ERR_STATUS_REG);
- BNAD_GET_REG(LPU0_ERR_SET_REG);
-
- /* LPU1 Registers */
- BNAD_GET_REG(LPU1_MBOX_CTL_REG);
- BNAD_GET_REG(LPU1_MBOX_CMD_REG);
- BNAD_GET_REG(LPU0_MBOX_LINK_1REG);
- BNAD_GET_REG(LPU1_MBOX_LINK_1REG);
- BNAD_GET_REG(LPU0_MBOX_STATUS_1REG);
- BNAD_GET_REG(LPU1_MBOX_STATUS_1REG);
- BNAD_GET_REG(LPU1_ERR_STATUS_REG);
- BNAD_GET_REG(LPU1_ERR_SET_REG);
-
- /* PSS Registers */
- BNAD_GET_REG(PSS_CTL_REG);
- BNAD_GET_REG(PSS_ERR_STATUS_REG);
- BNAD_GET_REG(ERR_STATUS_SET);
- BNAD_GET_REG(PSS_RAM_ERR_STATUS_REG);
-
- /* Catapult CPQ Registers */
- BNAD_GET_REG(HOSTFN0_LPU0_MBOX0_CMD_STAT);
- BNAD_GET_REG(HOSTFN0_LPU1_MBOX0_CMD_STAT);
- BNAD_GET_REG(LPU0_HOSTFN0_MBOX0_CMD_STAT);
- BNAD_GET_REG(LPU1_HOSTFN0_MBOX0_CMD_STAT);
-
- BNAD_GET_REG(HOSTFN0_LPU0_MBOX1_CMD_STAT);
- BNAD_GET_REG(HOSTFN0_LPU1_MBOX1_CMD_STAT);
- BNAD_GET_REG(LPU0_HOSTFN0_MBOX1_CMD_STAT);
- BNAD_GET_REG(LPU1_HOSTFN0_MBOX1_CMD_STAT);
-
- BNAD_GET_REG(HOSTFN1_LPU0_MBOX0_CMD_STAT);
- BNAD_GET_REG(HOSTFN1_LPU1_MBOX0_CMD_STAT);
- BNAD_GET_REG(LPU0_HOSTFN1_MBOX0_CMD_STAT);
- BNAD_GET_REG(LPU1_HOSTFN1_MBOX0_CMD_STAT);
-
- BNAD_GET_REG(HOSTFN1_LPU0_MBOX1_CMD_STAT);
- BNAD_GET_REG(HOSTFN1_LPU1_MBOX1_CMD_STAT);
- BNAD_GET_REG(LPU0_HOSTFN1_MBOX1_CMD_STAT);
- BNAD_GET_REG(LPU1_HOSTFN1_MBOX1_CMD_STAT);
-
- BNAD_GET_REG(HOSTFN2_LPU0_MBOX0_CMD_STAT);
- BNAD_GET_REG(HOSTFN2_LPU1_MBOX0_CMD_STAT);
- BNAD_GET_REG(LPU0_HOSTFN2_MBOX0_CMD_STAT);
- BNAD_GET_REG(LPU1_HOSTFN2_MBOX0_CMD_STAT);
-
- BNAD_GET_REG(HOSTFN2_LPU0_MBOX1_CMD_STAT);
- BNAD_GET_REG(HOSTFN2_LPU1_MBOX1_CMD_STAT);
- BNAD_GET_REG(LPU0_HOSTFN2_MBOX1_CMD_STAT);
- BNAD_GET_REG(LPU1_HOSTFN2_MBOX1_CMD_STAT);
-
- BNAD_GET_REG(HOSTFN3_LPU0_MBOX0_CMD_STAT);
- BNAD_GET_REG(HOSTFN3_LPU1_MBOX0_CMD_STAT);
- BNAD_GET_REG(LPU0_HOSTFN3_MBOX0_CMD_STAT);
- BNAD_GET_REG(LPU1_HOSTFN3_MBOX0_CMD_STAT);
-
- BNAD_GET_REG(HOSTFN3_LPU0_MBOX1_CMD_STAT);
- BNAD_GET_REG(HOSTFN3_LPU1_MBOX1_CMD_STAT);
- BNAD_GET_REG(LPU0_HOSTFN3_MBOX1_CMD_STAT);
- BNAD_GET_REG(LPU1_HOSTFN3_MBOX1_CMD_STAT);
-
- /* Host Function Force Parity Error Registers */
- BNAD_GET_REG(HOSTFN0_LPU_FORCE_PERR);
- BNAD_GET_REG(HOSTFN1_LPU_FORCE_PERR);
- BNAD_GET_REG(HOSTFN2_LPU_FORCE_PERR);
- BNAD_GET_REG(HOSTFN3_LPU_FORCE_PERR);
-
- /* LL Port[0|1] Halt Mask Registers */
- BNAD_GET_REG(LL_HALT_MSK_P0);
- BNAD_GET_REG(LL_HALT_MSK_P1);
-
- /* LL Port[0|1] Error Mask Registers */
- BNAD_GET_REG(LL_ERR_MSK_P0);
- BNAD_GET_REG(LL_ERR_MSK_P1);
-
- /* EMC FLI Registers */
- BNAD_GET_REG(FLI_CMD_REG);
- BNAD_GET_REG(FLI_ADDR_REG);
- BNAD_GET_REG(FLI_CTL_REG);
- BNAD_GET_REG(FLI_WRDATA_REG);
- BNAD_GET_REG(FLI_RDDATA_REG);
- BNAD_GET_REG(FLI_DEV_STATUS_REG);
- BNAD_GET_REG(FLI_SIG_WD_REG);
-
- BNAD_GET_REG(FLI_DEV_VENDOR_REG);
- BNAD_GET_REG(FLI_ERR_STATUS_REG);
-
- /* RxAdm 0 Registers */
- BNAD_GET_REG(RAD0_CTL_REG);
- BNAD_GET_REG(RAD0_PE_PARM_REG);
- BNAD_GET_REG(RAD0_BCN_REG);
- BNAD_GET_REG(RAD0_DEFAULT_REG);
- BNAD_GET_REG(RAD0_PROMISC_REG);
- BNAD_GET_REG(RAD0_BCNQ_REG);
- BNAD_GET_REG(RAD0_DEFAULTQ_REG);
-
- BNAD_GET_REG(RAD0_ERR_STS);
- BNAD_GET_REG(RAD0_SET_ERR_STS);
- BNAD_GET_REG(RAD0_ERR_INT_EN);
- BNAD_GET_REG(RAD0_FIRST_ERR);
- BNAD_GET_REG(RAD0_FORCE_ERR);
-
- BNAD_GET_REG(RAD0_MAC_MAN_1H);
- BNAD_GET_REG(RAD0_MAC_MAN_1L);
- BNAD_GET_REG(RAD0_MAC_MAN_2H);
- BNAD_GET_REG(RAD0_MAC_MAN_2L);
- BNAD_GET_REG(RAD0_MAC_MAN_3H);
- BNAD_GET_REG(RAD0_MAC_MAN_3L);
- BNAD_GET_REG(RAD0_MAC_MAN_4H);
- BNAD_GET_REG(RAD0_MAC_MAN_4L);
-
- BNAD_GET_REG(RAD0_LAST4_IP);
-
- /* RxAdm 1 Registers */
- BNAD_GET_REG(RAD1_CTL_REG);
- BNAD_GET_REG(RAD1_PE_PARM_REG);
- BNAD_GET_REG(RAD1_BCN_REG);
- BNAD_GET_REG(RAD1_DEFAULT_REG);
- BNAD_GET_REG(RAD1_PROMISC_REG);
- BNAD_GET_REG(RAD1_BCNQ_REG);
- BNAD_GET_REG(RAD1_DEFAULTQ_REG);
-
- BNAD_GET_REG(RAD1_ERR_STS);
- BNAD_GET_REG(RAD1_SET_ERR_STS);
- BNAD_GET_REG(RAD1_ERR_INT_EN);
-
- /* TxA0 Registers */
- BNAD_GET_REG(TXA0_CTRL_REG);
- /* TxA0 TSO Sequence # Registers (RO) */
- for (i = 0; i < 8; i++) {
- BNAD_GET_REG(TXA0_TSO_TCP_SEQ_REG(i));
- BNAD_GET_REG(TXA0_TSO_IP_INFO_REG(i));
- }
-
- /* TxA1 Registers */
- BNAD_GET_REG(TXA1_CTRL_REG);
- /* TxA1 TSO Sequence # Registers (RO) */
- for (i = 0; i < 8; i++) {
- BNAD_GET_REG(TXA1_TSO_TCP_SEQ_REG(i));
- BNAD_GET_REG(TXA1_TSO_IP_INFO_REG(i));
- }
-
- /* RxA Registers */
- BNAD_GET_REG(RXA0_CTL_REG);
- BNAD_GET_REG(RXA1_CTL_REG);
-
- /* PLB0 Registers */
- BNAD_GET_REG(PLB0_ECM_TIMER_REG);
- BNAD_GET_REG(PLB0_RL_CTL);
- for (i = 0; i < 8; i++)
- BNAD_GET_REG(PLB0_RL_MAX_BC(i));
- BNAD_GET_REG(PLB0_RL_TU_PRIO);
- for (i = 0; i < 8; i++)
- BNAD_GET_REG(PLB0_RL_BYTE_CNT(i));
- BNAD_GET_REG(PLB0_RL_MIN_REG);
- BNAD_GET_REG(PLB0_RL_MAX_REG);
- BNAD_GET_REG(PLB0_EMS_ADD_REG);
-
- /* PLB1 Registers */
- BNAD_GET_REG(PLB1_ECM_TIMER_REG);
- BNAD_GET_REG(PLB1_RL_CTL);
- for (i = 0; i < 8; i++)
- BNAD_GET_REG(PLB1_RL_MAX_BC(i));
- BNAD_GET_REG(PLB1_RL_TU_PRIO);
- for (i = 0; i < 8; i++)
- BNAD_GET_REG(PLB1_RL_BYTE_CNT(i));
- BNAD_GET_REG(PLB1_RL_MIN_REG);
- BNAD_GET_REG(PLB1_RL_MAX_REG);
- BNAD_GET_REG(PLB1_EMS_ADD_REG);
-
- /* HQM Control Register */
- BNAD_GET_REG(HQM0_CTL_REG);
- BNAD_GET_REG(HQM0_RXQ_STOP_SEM);
- BNAD_GET_REG(HQM0_TXQ_STOP_SEM);
- BNAD_GET_REG(HQM1_CTL_REG);
- BNAD_GET_REG(HQM1_RXQ_STOP_SEM);
- BNAD_GET_REG(HQM1_TXQ_STOP_SEM);
-
- /* LUT Registers */
- BNAD_GET_REG(LUT0_ERR_STS);
- BNAD_GET_REG(LUT0_SET_ERR_STS);
- BNAD_GET_REG(LUT1_ERR_STS);
- BNAD_GET_REG(LUT1_SET_ERR_STS);
-
- /* TRC Registers */
- BNAD_GET_REG(TRC_CTL_REG);
- BNAD_GET_REG(TRC_MODS_REG);
- BNAD_GET_REG(TRC_TRGC_REG);
- BNAD_GET_REG(TRC_CNT1_REG);
- BNAD_GET_REG(TRC_CNT2_REG);
- BNAD_GET_REG(TRC_NXTS_REG);
- BNAD_GET_REG(TRC_DIRR_REG);
- for (i = 0; i < 10; i++)
- BNAD_GET_REG(TRC_TRGM_REG(i));
- for (i = 0; i < 10; i++)
- BNAD_GET_REG(TRC_NXTM_REG(i));
- for (i = 0; i < 10; i++)
- BNAD_GET_REG(TRC_STRM_REG(i));
-
- spin_unlock_irqrestore(&bnad->bna_lock, flags);
-#undef BNAD_GET_REG
- return num;
-}
-static int
-bnad_get_regs_len(struct net_device *netdev)
-{
- int ret = get_regs(netdev_priv(netdev), NULL) * sizeof(u32);
- return ret;
-}
-
-static void
-bnad_get_regs(struct net_device *netdev, struct ethtool_regs *regs, void *buf)
-{
- memset(buf, 0, bnad_get_regs_len(netdev));
- get_regs(netdev_priv(netdev), buf);
-}
-
static void
bnad_get_wol(struct net_device *netdev, struct ethtool_wolinfo *wolinfo)
{
@@ -1192,8 +875,6 @@ static struct ethtool_ops bnad_ethtool_ops = {
.get_settings = bnad_get_settings,
.set_settings = bnad_set_settings,
.get_drvinfo = bnad_get_drvinfo,
- .get_regs_len = bnad_get_regs_len,
- .get_regs = bnad_get_regs,
.get_wol = bnad_get_wol,
.get_link = ethtool_op_get_link,
.get_coalesce = bnad_get_coalesce,
--
1.7.1
^ permalink raw reply related
* RE: [net-next v2 42/71] cirrus: Move the Cirrus network driver
From: H Hartley Sweeten @ 2011-08-01 20:23 UTC (permalink / raw)
To: Jeff Kirsher, davem@davemloft.net
Cc: netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com
In-Reply-To: <1312082850-24914-43-git-send-email-jeffrey.t.kirsher@intel.com>
On Saturday, July 30, 2011 8:27 PM, Jeff Kirsher wrote:
>
> Move the Cirrus Ethernet driver into drivers/net/ethernet/cirrus/
> and make the necessary Kconfig and Makefile changes
>
> CC: Hartley Sweeten <hsweeten@visionengravers.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
I'm not sure why this is being done... Are all the Ethernet drivers being
moved into "vendor" sub-directories?
A couple comments below...
> ---
> MAINTAINERS | 2 +-
> drivers/net/arm/Kconfig | 8 -------
> drivers/net/arm/Makefile | 1 -
> drivers/net/ethernet/Kconfig | 1 +
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/ethernet/cirrus/Kconfig | 24 +++++++++++++++++++++
> drivers/net/ethernet/cirrus/Makefile | 5 ++++
> drivers/net/{arm => ethernet/cirrus}/ep93xx_eth.c | 0
> 8 files changed, 32 insertions(+), 10 deletions(-)
> create mode 100644 drivers/net/ethernet/cirrus/Kconfig
> create mode 100644 drivers/net/ethernet/cirrus/Makefile
> rename drivers/net/{arm => ethernet/cirrus}/ep93xx_eth.c (100%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3c28188..d84f2c6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1761,7 +1761,7 @@ CIRRUS LOGIC EP93XX ETHERNET DRIVER
> M: Hartley Sweeten <hsweeten@visionengravers.com>
> L: netdev@vger.kernel.org
> S: Maintained
> -F: drivers/net/arm/ep93xx_eth.c
> +F: drivers/net/ethernet/cirrus/ep93xx_eth.c
>
> CIRRUS LOGIC EP93XX OHCI USB HOST DRIVER
> M: Lennert Buytenhek <kernel@wantstofly.org>
> diff --git a/drivers/net/arm/Kconfig b/drivers/net/arm/Kconfig
> index 4f748cc..fc94b4b 100644
> --- a/drivers/net/arm/Kconfig
> +++ b/drivers/net/arm/Kconfig
> @@ -11,14 +11,6 @@ config ARM_AT91_ETHER
> If you wish to compile a kernel for the AT91RM9200 and enable
> ethernet support, then you should always answer Y to this.
>
> -config EP93XX_ETH
> - tristate "EP93xx Ethernet support"
> - depends on ARM && ARCH_EP93XX
> - select MII
> - help
> - This is a driver for the ethernet hardware included in EP93xx CPUs.
> - Say Y if you are building a kernel for EP93xx based devices.
> -
> config W90P910_ETH
> tristate "Nuvoton w90p910 Ethernet support"
> depends on ARM && ARCH_W90X900
> diff --git a/drivers/net/arm/Makefile b/drivers/net/arm/Makefile
> index 316b06c..462b3a4 100644
> --- a/drivers/net/arm/Makefile
> +++ b/drivers/net/arm/Makefile
> @@ -4,5 +4,4 @@
> #
>
> obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o
> -obj-$(CONFIG_EP93XX_ETH) += ep93xx_eth.o
> obj-$(CONFIG_W90P910_ETH) += w90p910_ether.o
> diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
> index b15b1e2..ff07408 100644
> --- a/drivers/net/ethernet/Kconfig
> +++ b/drivers/net/ethernet/Kconfig
> @@ -18,6 +18,7 @@ source "drivers/net/ethernet/atheros/Kconfig"
> source "drivers/net/ethernet/broadcom/Kconfig"
> source "drivers/net/ethernet/brocade/Kconfig"
> source "drivers/net/ethernet/chelsio/Kconfig"
> +source "drivers/net/ethernet/cirrus/Kconfig"
> source "drivers/net/ethernet/cisco/Kconfig"
> source "drivers/net/ethernet/dec/Kconfig"
> source "drivers/net/ethernet/dlink/Kconfig"
> diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
> index 1f45ec9..3a17413 100644
> --- a/drivers/net/ethernet/Makefile
> +++ b/drivers/net/ethernet/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_NET_VENDOR_ATHEROS) += atheros/
> obj-$(CONFIG_NET_VENDOR_BROADCOM) += broadcom/
> obj-$(CONFIG_NET_VENDOR_BROCADE) += brocade/
> obj-$(CONFIG_NET_VENDOR_CHELSIO) += chelsio/
> +obj-$(CONFIG_NET_VENDOR_CIRRUS) += cirrus/
> obj-$(CONFIG_NET_VENDOR_CISCO) += cisco/
> obj-$(CONFIG_NET_VENDOR_DEC) += dec/
> obj-$(CONFIG_NET_VENDOR_DLINK) += dlink/
> diff --git a/drivers/net/ethernet/cirrus/Kconfig b/drivers/net/ethernet/cirrus/Kconfig
> new file mode 100644
> index 0000000..b48128b
> --- /dev/null
> +++ b/drivers/net/ethernet/cirrus/Kconfig
> @@ -0,0 +1,24 @@
> +#
> +# Cirrus network device configuration
> +#
> +
> +config NET_VENDOR_CIRRUS
> + bool "Cirrus devices"
> + depends on ARM && ARCH_EP93XX
I'm not sure this depends on is correct.
Cirrus also manufactures the CS8900A and CS8952 Ethernet controllers. As far as I
can tell, these controllers are general purpose and not limited to ARM or ARCH_EP93XX.
> + ---help---
> + If you have a network (Ethernet) card belonging to this class, say Y
> + and read the Ethernet-HOWTO, available from
> + <http://www.tldp.org/docs.html#howto>.
> +
> + Note that the answer to this question doesn't directly affect the
> + kernel: saying N will just cause the configurator to skip all
> + the questions about Cirrus cards. If you say Y, you will be asked
> + for your specific card in the following questions.
> +
> +config EP93XX_ETH
> + tristate "EP93xx Ethernet support"
> + depends on NET_VENDOR_CIRRUS && ARM && ARCH_EP93XX
The depends on ARM is redundant. ARCH_EP93XX can only be selected if ARM is already
selected.
If drivers exist for the other two Cirrus controllers and are going to be moved
to this directory it might be cleaner to just block all the drivers in a
+if NET_VENDOR_CIRRUS
# add all config options for Cirrus Ethernet controllers
+endif
> + select MII
> + help
> + This is a driver for the ethernet hardware included in EP93xx CPUs.
> + Say Y if you are building a kernel for EP93xx based devices.
> diff --git a/drivers/net/ethernet/cirrus/Makefile b/drivers/net/ethernet/cirrus/Makefile
> new file mode 100644
> index 0000000..9905ea2
> --- /dev/null
> +++ b/drivers/net/ethernet/cirrus/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for the Cirrus network device drivers.
> +#
> +
> +obj-$(CONFIG_EP93XX_ETH) += ep93xx_eth.o
> diff --git a/drivers/net/arm/ep93xx_eth.c b/drivers/net/ethernet/cirrus/ep93xx_eth.c
> similarity index 100%
> rename from drivers/net/arm/ep93xx_eth.c
> rename to drivers/net/ethernet/cirrus/ep93xx_eth.c
Other than those comments...
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* Re: [net-next v2 02/71] 3c*/acenic/typhoon: Move 3Com Ethernet drivers
From: Jeff Kirsher @ 2011-08-01 20:15 UTC (permalink / raw)
To: Alan Cox
Cc: davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com,
sassmann@redhat.com, Philip Blundell, Steffen Klassert,
David Dillow, Jes Sorensen, Donald Becker, Craig Southeren,
David Hinds
In-Reply-To: <20110801100303.48ed75f7@bob.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2037 bytes --]
On Mon, 2011-08-01 at 02:03 -0700, Alan Cox wrote:
> On Sat, 30 Jul 2011 20:26:21 -0700
> Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
>
> > Moves the 3Com drivers into drivers/net/ethernet/3com/ and the
> > necessary Kconfig and Makefile changes.
>
> This still seems crazy
>
> The 3c503 is not being moved (as its 8390 based)
>
> But the 3c505/3c523/3c527/3c507 by that logic also shouldn't be moved
> as really they all belong with the rest of the Intel devices they are
> basically variants of (the 3c527 is weirder, in fact you can probably
> run CP/M 86 on it if you were mad enough)
I did as you asked, just not in this patch. I should have cleaned up
this patch to reflect the changes I made in patch #4 and #10.
>
> > drivers/net/{pcmcia => ethernet/3com}/3c574_cs.c | 0
> > drivers/net/{pcmcia => ethernet/3com}/3c589_cs.c | 0
>
> These are currently sensibly where they belong - with the pcmcia
> adapters.
>
> > drivers/net/{ => ethernet/3com}/3c59x.c | 0
> > drivers/net/ethernet/3com/Kconfig | 200
> > ++++++++++++++++++++++
> > drivers/net/ethernet/3com/Makefile | 16 ++
> > drivers/net/{ => ethernet/3com}/acenic.c | 0
> > drivers/net/{ => ethernet/3com}/acenic.h | 0
>
> And most Acenic devices are probably branded Netgear not 3COM and may
> also claim to be from Farallon, SGI, Alteon or DEC. Again not a 3Com
> originated part.
>
> So I still think this patch is utter nonsense and just noise.
>
> There isn't any sense in trying to line the network drivers up by
> whatever is written on the box that was thrown away years before. The
> reality is that most cards do not bear anything relevant to the chipset
> vendors name, even by the early 1990s.
>
> Architectually it makes more sense to keep tidy by bus type and by
> chipset, not by vendor name
>
> NAK
>
> And even if you wanted to make Kconfig simpler - you don't need to move
> files around.
>
> Alan
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] net: add Documentation/networking/scaling.txt
From: Rick Jones @ 2011-08-01 18:49 UTC (permalink / raw)
To: Tom Herbert; +Cc: rdunlap, linux-doc, davem, netdev, willemb
In-Reply-To: <alpine.DEB.2.00.1107312346350.28722@pokey.mtv.corp.google.com>
On 07/31/2011 11:56 PM, Tom Herbert wrote:
> Describes RSS, RPS, RFS, accelerated RFS, and XPS.
>
> Signed-off-by: Tom Herbert<therbert@google.com>
> ---
> Documentation/networking/scaling.txt | 346 ++++++++++++++++++++++++++++++++++
> 1 files changed, 346 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/networking/scaling.txt
>
> diff --git a/Documentation/networking/scaling.txt b/Documentation/networking/scaling.txt
> new file mode 100644
> index 0000000..aa51f0f
> --- /dev/null
> +++ b/Documentation/networking/scaling.txt
> @@ -0,0 +1,346 @@
> +Scaling in the Linux Networking Stack
> +
> +
> +Introduction
> +============
> +
> +This document describes a set of complementary techniques in the Linux
> +networking stack to increase parallelism and improve performance (in
> +throughput, latency, CPU utilization, etc.) for multi-processor systems.
Why not just leave-out the parenthetical lest some picky pedant find a
specific example where either of those three are not improved?
> +
> +The following technologies are described:
> +
> + RSS: Receive Side Scaling
> + RPS: Receive Packet Steering
> + RFS: Receive Flow Steering
> + Accelerated Receive Flow Steering
> + XPS: Transmit Packet Steering
> +
> +
> +RSS: Receive Side Scaling
> +=========================
> +
> +Contemporary NICs support multiple receive queues (multi-queue), which
> +can be used to distribute packets amongst CPUs for processing. The NIC
> +distributes packets by applying a filter to each packet to assign it to
> +one of a small number of logical flows. Packets for each flow are
> +steered to a separate receive queue, which in turn can be processed by
> +separate CPUs. This mechanism is generally known as “Receive-side
> +Scaling” (RSS).
> +
> +The filter used in RSS is typically a hash function over the network or
> +transport layer headers-- for example, a 4-tuple hash over IP addresses
Network *and* transport layer headers? And/or?
> +== RSS IRQ Configuration
> +
> +Each receive queue has a separate IRQ associated with it. The NIC
> +triggers this to notify a CPU when new packets arrive on the given
> +queue. The signaling path for PCIe devices uses message signaled
> +interrupts (MSI-X), that can route each interrupt to a particular CPU.
> +The active mapping of queues to IRQs can be determined from
> +/proc/interrupts. By default, all IRQs are routed to CPU0. Because a
Really?
> +non-negligible part of packet processing takes place in receive
> +interrupt handling, it is advantageous to spread receive interrupts
> +between CPUs. To manually adjust the IRQ affinity of each interrupt see
> +Documentation/IRQ-affinity. On some systems, the irqbalance daemon is
> +running and will try to dynamically optimize this setting.
I would probably make it explicit that the irqbalance daemon will undo
one's manual changes:
"Some systems will be running an irqbalance daemon which will be trying
to dynamically optimize IRQ assignments and will undo manual adjustments."
Whether one needs to go so far as to explicitly suggest that the
irqbalance daemon should be disabled in such cases I'm not sure.
> +RPS: Receive Packet Steering
> +============================
> +
> +Receive Packet Steering (RPS) is logically a software implementation of
> ...
> +
> +Each receive hardware qeueue has associated list of CPUs which can
"queue has an associated" (spelling and grammar nits)
> +process packets received on the queue for RPS. For each received
> +packet, an index into the list is computed from the flow hash modulo the
> +size of the list. The indexed CPU is the target for processing the
> +packet, and the packet is queued to the tail of that CPU’s backlog
> +queue. At the end of the bottom half routine, inter-processor interrupts
> +(IPIs) are sent to any CPUs for which packets have been queued to their
> +backlog queue. The IPI wakes backlog processing on the remote CPU, and
> +any queued packets are then processed up the networking stack. Note that
> +the list of CPUs can be configured separately for each hardware receive
> +queue.
> +
> +== RPS Configuration
> +
> +RPS requires a kernel compiled with the CONFIG_RPS flag (on by default
> +for smp). Even when compiled in, it is disabled without any
> +configuration. The list of CPUs to which RPS may forward traffic can be
> +configured for each receive queue using the sysfs file entry:
> +
> + /sys/class/net/<dev>/queues/rx-<n>/rps_cpus
> +
> +This file implements a bitmap of CPUs. RPS is disabled when it is zero
> +(the default), in which case packets are processed on the interrupting
> +CPU. IRQ-affinity.txt explains how CPUs are assigned to the bitmap.
Earlier in the writeup (snipped) it is presented as
"Documentation/IRQ-affinity" and here as IRQ-affinity.txt, should that
be "Documentation/IRQ-affinity.txt" in both cases?
> +For a single queue device, a typical RPS configuration would be to set
> +the rps_cpus to the CPUs in the same cache domain of the interrupting
> +CPU for a queue. If NUMA locality is not an issue, this could also be
> +all CPUs in the system. At high interrupt rate, it might wise to exclude
> +the interrupting CPU from the map since that already performs much work.
> +
> +For a multi-queue system, if RSS is configured so that a receive queue
Multple hardware queue to help keep the "queues" separate in the mind of
the reader?
> +is mapped to each CPU, then RPS is probably redundant and unnecessary.
> +If there are fewer queues than CPUs, then RPS might be beneficial if the
same.
> +rps_cpus for each queue are the ones that share the same cache domain as
> +the interrupting CPU for the queue.
> +
> +RFS: Receive Flow Steering
> +==========================
> +
> +While RPS steers packet solely based on hash, and thus generally
> +provides good load distribution, it does not take into account
> +application locality. This is accomplished by Receive Flow Steering
Should it also mention how an application thread of execution might be
processing requests on multiple connections, which themselves might not
normally hash to the same place?
> +== RFS Configuration
> +
> +RFS is only available if the kernel flag CONFIG_RFS is enabled (on by
> +default for smp). The functionality is disabled without any
> +configuration.
Perhaps just wordsmithing, but "This functionality remains disabled
until explicitly configured." seems clearer.
> +== Accelerated RFS Configuration
> +
> +Accelerated RFS is only available if the kernel is compiled with
> +CONFIG_RFS_ACCEL and support is provided by the NIC device and driver.
> +It also requires that ntuple filtering is enabled via ethtool.
Requires that ntuple filtering be enabled?
> +XPS: Transmit Packet Steering
> +=============================
> +
> +Transmit Packet Steering is a mechanism for intelligently selecting
> +which transmit queue to use when transmitting a packet on a multi-queue
> +device.
Minor nit. Up to this point a multi-queue device was only described as
one with multiple receive queues.
> +Further Information
> +===================
> +RPS and RFS were introduced in kernel 2.6.35. XPS was incorporated into
> +2.6.38. Original patches were submitted by Tom Herbert
> +(therbert@google.com)
> +
> +
> +Accelerated RFS was introduced in 2.6.35. Original patches were
> +submitted by Ben Hutchings (bhutchings@solarflare.com)
> +
> +Authors:
> +Tom Herbert (therbert@google.com)
> +Willem de Bruijn (willemb@google.com)
> +
While there are tidbits and indications in the descriptions of each
mechanism, a section with explicit description of when one would use the
different mechanisms would be goodness.
rick jones
^ permalink raw reply
* Re: [PATCH] net: add Documentation/networking/scaling.txt
From: Randy Dunlap @ 2011-08-01 18:41 UTC (permalink / raw)
To: Tom Herbert; +Cc: linux-doc, davem, netdev, willemb
In-Reply-To: <alpine.DEB.2.00.1107312346350.28722@pokey.mtv.corp.google.com>
On Sun, 31 Jul 2011 23:56:26 -0700 (PDT) Tom Herbert wrote:
> Describes RSS, RPS, RFS, accelerated RFS, and XPS.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> Documentation/networking/scaling.txt | 346 ++++++++++++++++++++++++++++++++++
> 1 files changed, 346 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/networking/scaling.txt
>
> diff --git a/Documentation/networking/scaling.txt b/Documentation/networking/scaling.txt
> new file mode 100644
> index 0000000..aa51f0f
> --- /dev/null
> +++ b/Documentation/networking/scaling.txt
> @@ -0,0 +1,346 @@
> +Scaling in the Linux Networking Stack
> +
> +
> +Introduction
> +============
> +
> +This document describes a set of complementary techniques in the Linux
> +networking stack to increase parallelism and improve performance (in
> +throughput, latency, CPU utilization, etc.) for multi-processor systems.
> +
> +The following technologies are described:
> +
> + RSS: Receive Side Scaling
> + RPS: Receive Packet Steering
> + RFS: Receive Flow Steering
> + Accelerated Receive Flow Steering
> + XPS: Transmit Packet Steering
> +
> +
> +RSS: Receive Side Scaling
> +=========================
> +
> +Contemporary NICs support multiple receive queues (multi-queue), which
> +can be used to distribute packets amongst CPUs for processing. The NIC
> +distributes packets by applying a filter to each packet to assign it to
> +one of a small number of logical flows. Packets for each flow are
> +steered to a separate receive queue, which in turn can be processed by
> +separate CPUs. This mechanism is generally known as “Receive-side
> +Scaling” (RSS).
> +
> +The filter used in RSS is typically a hash function over the network or
> +transport layer headers-- for example, a 4-tuple hash over IP addresses
> +and TCP ports of a packet. The most common hardware implementation of
> +RSS uses a 128 entry indirection table where each entry stores a queue
128-entry
> +number. The receive queue for a packet is determined by masking out the
> +low order seven bits of the computed hash for the packet (usually a
> +Toeplitz hash), taking this number as a key into the indirection table
> +and reading the corresponding value.
> +
> +Some advanced NICs allow steering packets to queues based on
> +programmable filters. For example, webserver bound TCP port 80 packets
> +can be directed to their own receive queue. Such “n-tuple” filters can
> +be configured from ethtool (--config-ntuple).
> +
> +== RSS Configuration
> +
> +The driver for a multi-queue capable NIC typically provides a module
> +parameter specifying the number of hardware queues to configure. In the
> +bnx2x driver, for instance, this parameter is called num_queues. A
> +typical RSS configuration would be to have one receive queue for each
> +CPU if the device supports enough queues, or otherwise at least one for
> +each cache domain at a particular cache level (L1, L2, etc.).
> +
> +The indirection table of an RSS device, which resolves a queue by masked
> +hash, is usually programmed by the driver at initialization. The
> +default mapping is to distribute the queues evenly in the table, but the
> +indirection table can be retrieved and modified at runtime using ethtool
> +commands (--show-rxfh-indir and --set-rxfh-indir). Modifying the
> +indirection table could be done to to give different queues different
^^drop one "to"
> +relative weights.
Drop trailing whitespace above and anywhere else that it's found. (5 places)
I thought (long ago :) that multiple RX queues were for prioritizing traffic,
but there is nothing here about using multi-queues for priorities.
Is that (no longer) done?
> +
> +== RSS IRQ Configuration
> +
> +Each receive queue has a separate IRQ associated with it. The NIC
> +triggers this to notify a CPU when new packets arrive on the given
> +queue. The signaling path for PCIe devices uses message signaled
> +interrupts (MSI-X), that can route each interrupt to a particular CPU.
> +The active mapping of queues to IRQs can be determined from
> +/proc/interrupts. By default, all IRQs are routed to CPU0. Because a
> +non-negligible part of packet processing takes place in receive
> +interrupt handling, it is advantageous to spread receive interrupts
> +between CPUs. To manually adjust the IRQ affinity of each interrupt see
> +Documentation/IRQ-affinity. On some systems, the irqbalance daemon is
> +running and will try to dynamically optimize this setting.
or (avoid a split infinitive): will try to optimize this setting dynamically.
> +
> +
> +RPS: Receive Packet Steering
> +============================
> +
> +Receive Packet Steering (RPS) is logically a software implementation of
> +RSS. Being in software, it is necessarily called later in the datapath.
> +Whereas RSS selects the queue and hence CPU that will run the hardware
> +interrupt handler, RPS selects the CPU to perform protocol processing
> +above the interrupt handler. This is accomplished by placing the packet
> +on the desired CPU’s backlog queue and waking up the CPU for processing.
> +RPS has some advantages over RSS: 1) it can be used with any NIC, 2)
> +software filters can easily be added to handle new protocols, 3) it does
> +not increase hardware device interrupt rate (but does use IPIs).
> +
> +RPS is called during bottom half of the receive interrupt handler, when
> +a driver sends a packet up the network stack with netif_rx() or
> +netif_receive_skb(). These call the get_rps_cpu() function, which
> +selects the queue that should process a packet.
> +
> +The first step in determining the target CPU for RPS is to calculate a
> +flow hash over the packet’s addresses or ports (2-tuple or 4-tuple hash
> +depending on the protocol). This serves as a consistent hash of the
> +associated flow of the packet. The hash is either provided by hardware
> +or will be computed in the stack. Capable hardware can pass the hash in
> +the receive descriptor for the packet, this would usually be the same
packet;
> +hash used for RSS (e.g. computed Toeplitz hash). The hash is saved in
> +skb->rx_hash and can be used elsewhere in the stack as a hash of the
> +packet’s flow.
> +
> +Each receive hardware qeueue has associated list of CPUs which can
has an associated list (?)
> +process packets received on the queue for RPS. For each received
> +packet, an index into the list is computed from the flow hash modulo the
> +size of the list. The indexed CPU is the target for processing the
> +packet, and the packet is queued to the tail of that CPU’s backlog
> +queue. At the end of the bottom half routine, inter-processor interrupts
> +(IPIs) are sent to any CPUs for which packets have been queued to their
> +backlog queue. The IPI wakes backlog processing on the remote CPU, and
> +any queued packets are then processed up the networking stack. Note that
> +the list of CPUs can be configured separately for each hardware receive
> +queue.
> +
> +== RPS Configuration
> +
> +RPS requires a kernel compiled with the CONFIG_RPS flag (on by default
s/flag/kconfig symbol/
> +for smp). Even when compiled in, it is disabled without any
for SMP).
> +configuration. The list of CPUs to which RPS may forward traffic can be
> +configured for each receive queue using the sysfs file entry:
> +
> + /sys/class/net/<dev>/queues/rx-<n>/rps_cpus
> +
> +This file implements a bitmap of CPUs. RPS is disabled when it is zero
> +(the default), in which case packets are processed on the interrupting
> +CPU. IRQ-affinity.txt explains how CPUs are assigned to the bitmap.
> +
> +For a single queue device, a typical RPS configuration would be to set
> +the rps_cpus to the CPUs in the same cache domain of the interrupting
> +CPU for a queue. If NUMA locality is not an issue, this could also be
> +all CPUs in the system. At high interrupt rate, it might wise to exclude
it might be wise
> +the interrupting CPU from the map since that already performs much work.
> +
> +For a multi-queue system, if RSS is configured so that a receive queue
> +is mapped to each CPU, then RPS is probably redundant and unnecessary.
> +If there are fewer queues than CPUs, then RPS might be beneficial if the
> +rps_cpus for each queue are the ones that share the same cache domain as
> +the interrupting CPU for the queue.
> +
> +RFS: Receive Flow Steering
> +==========================
> +
> +While RPS steers packet solely based on hash, and thus generally
steers packets
> +provides good load distribution, it does not take into account
> +application locality. This is accomplished by Receive Flow Steering
> +(RFS). The goal of RFS is to increase datacache hitrate by steering
> +kernel processing of packets to the CPU where the application thread
> +consuming the packet is running. RFS relies on the same RPS mechanisms
> +to enqueue packets onto the backlog of another CPU and to wake that CPU.
> +
> +In RFS, packets are not forwarded directly by the value of their hash,
> +but the hash is used as index into a flow lookup table. This table maps
> +flows to the CPUs where those flows are being processed. The flow hash
> +(see RPS section above) is used to calculate the index into this table.
> +The CPU recorded in each entry is the one which last processed the flow,
> +and if there is not a valid CPU for an entry, then packets mapped to
> +that entry are steered using plain RPS.
> +
> +To avoid out of order packets (ie. when scheduler moves a thread with
(i.e., when the scheduler moves a thread that
> +outstanding receive packets on) there are two levels of flow tables used
has outstanding receive packets),
> +by RFS: rps_sock_flow_table and rps_dev_flow_table.
> +
> +rps_sock_table is a global flow table. Each table value is a CPU index
> +and is populated by recvmsg and sendmsg (specifically, inet_recvmsg(),
> +inet_sendmsg(), inet_sendpage() and tcp_splice_read()). This table
> +contains the *desired* CPUs for flows.
> +
> +rps_dev_flow_table is specific to each hardware receive queue of each
> +device. Each table value stores a CPU index and a counter. The CPU
> +index represents the *current* CPU that is assigned to processing the
> +matching flows.
> +
> +The counter records the length of this CPU's backlog when a packet in
> +this flow was last enqueued. Each backlog queue has a head counter that
> +is incremented on dequeue. A tail counter is computed as head counter +
> +queue length. In other words, the counter in rps_dev_flow_table[i]
> +records the last element in flow i that has been enqueued onto the
> +currently designated CPU for flow i (of course, entry i is actually
> +selected by hash and multiple flows may hash to the same entry i).
> +
> +And now the trick for avoiding out of order packets: when selecting the
> +CPU for packet processing (from get_rps_cpu()) the rps_sock_flow table
> +and the rps_dev_flow table of the queue that the packet was received on
> +are compared. If the desired CPU for the flow (found in the
> +rps_sock_flow table) matches the current CPU (found in the rps_dev_flow
> +table), the packet is enqueud onto that CPU’s backlog. If they differ,
enqueued
> +the current cpu is updated to match the desired CPU if one of the
s/cpu/CPU/ (globally as needed)
> +following is true:
> +
> +- The current CPU's queue head counter >= the recorded tail counter
> + value in rps_dev_flow[i]
> +- The current CPU is unset (equal to NR_CPUS)
> +- The current CPU is offline
> +
> +After this check, the packet is sent to the (possibly updated) current
> +CPU. These rules aim to ensure that a flow only moves to a new CPU when
> +there are no packets outstanding on the old CPU, as the outstanding
> +packets could arrive later than those about to be processed on the new
> +CPU.
> +
> +== RFS Configuration
> +
> +RFS is only available if the kernel flag CONFIG_RFS is enabled (on by
s/flag/kconfig symbol/
> +default for smp). The functionality is disabled without any
s/smp/SMP/
> +configuration. The number of entries in the global flow table is set
> +through:
> +
> + /proc/sys/net/core/rps_sock_flow_entries
> +
> +The number of entries in the per queue flow table are set through:
per-queue
> +
> + /sys/class/net/<dev>/queues/tx-<n>/rps_flow_cnt
> +
> +Both of these need to be set before RFS is enabled for a receive queue.
> +Values for both of these are rounded up to the nearest power of two. The
> +suggested flow count depends on the expected number active connections
number of
> +at any given time, which may be significantly less than the number of
> +open connections. We have found that a value of 32768 for
> +rps_sock_flow_entries works fairly well on a moderately loaded server.
> +
> +For a single queue device, the rps_flow_cnt value for the single queue
> +would normally be configured to the same value as rps_sock_flow_entries.
> +For a multi-queue device, the rps_flow_cnt for each queue might be
> +configured as rps_sock_flow_entries / N, where N is the number of
> +queues. So for instance, if rps_flow_entries is set to 32768 and there
> +are 16 configured receive queues, rps_flow_cnt for each queue might be
> +configured as 2048.
> +
> +
> +Accelerated RFS
> +===============
> +
> +Accelerated RFS is to RFS what RSS is to RPS: a hardware-accelerated
> +load balancing mechanism that uses soft state to steer flows based on
> +where the thread consuming the packets of each flow is running.
> +Accelerated RFS should perform better than RFS since packets are sent
> +directly to a CPU local to the thread consuming the data. The target CPU
> +will either be the same CPU where the application runs, or at least a
> +CPU which is local to the application thread’s CPU in the cache
> +hierarchy.
> +
> +To enable accelerated RFS, the networking stack calls the
> +ndo_rx_flow_steer driver function to communicate the desired hardware
> +queue for packets matching a particular flow. The network stack
> +automatically calls this function every time a flow entry in
> +rps_dev_flow_table is updated. The driver in turn uses a device specific
device-specific
> +method to program the NIC to steer the packets.
> +
> +The hardware queue for a flow is derived from the CPU recorded in
> +rps_dev_flow_table. The stack consults a CPU to hardware queue map which
CPU-to-hardware-queue map
> +is maintained by the NIC driver. This is an autogenerated reverse map of
> +the IRQ affinity table shown by /proc/interrupts. Drivers can use
> +functions in the cpu_rmap (“cpu affinitiy reverse map”) kernel library
> +to populate the map. For each CPU, the corresponding queue in the map is
> +set to be one whose processing CPU is closest in cache locality.
> +
> +== Accelerated RFS Configuration
> +
> +Accelerated RFS is only available if the kernel is compiled with
> +CONFIG_RFS_ACCEL and support is provided by the NIC device and driver.
> +It also requires that ntuple filtering is enabled via ethtool. The map
> +of CPU to queues is automatically deduced from the IRQ affinities
> +configured for each receive queue by the driver, so no additional
> +configuration should be necessary.
> +
> +XPS: Transmit Packet Steering
> +=============================
> +
> +Transmit Packet Steering is a mechanism for intelligently selecting
> +which transmit queue to use when transmitting a packet on a multi-queue
> +device. To accomplish this, a mapping from CPU to hardware queue(s) is
> +recorded. The goal of this mapping is usually to assign queues
> +exclusively to a subset of CPUs, where the transmit completions for
> +these queues are processed on a CPU within this set. This choice
> +provides two benefits. First, contention on the device queue lock is
> +significantly reduced since fewer CPUs contend for the same queue
> +(contention can be eliminated completely if each CPU has its own
> +transmit queue). Secondly, cache miss rate on transmit completion is
> +reduced, in particular for data cache lines that hold the sk_buff
> +structures.
> +
> +XPS is configured per transmit queue by setting a bitmap of CPUs that
> +may use that queue to transmit. The reverse mapping, from CPUs to
> +transmit queues, is computed and maintained for each network device.
> +When transmitting the first packet in a flow, the function
> +get_xps_queue() is called to select a queue. This function uses the ID
> +of the running CPU as a key into the CPU to queue lookup table. If the
CPU-to-queue
> +ID matches a single queue, that is used for transmission. If multiple
> +queues match, one is selected by using the flow hash to compute an index
> +into the set.
> +
> +The queue chosen for transmitting a particular flow is saved in the
> +corresponding socket structure for the flow (e.g. a TCP connection).
> +This transmit queue is used for subsequent packets sent on the flow to
> +prevent out of order (ooo) packets. The choice also amortizes the cost
> +of calling get_xps_queues() over all packets in the connection. To avoid
> +ooo packets, the queue for a flow can subsequently only be changed if
> +skb->ooo_okay is set for a packet in the flow. This flag indicates that
> +there are no outstanding packets in the flow, so the transmit queue can
> +change without the risk of generating out of order packets. The
> +transport layer is responsible for setting ooo_okay appropriately. TCP,
> +for instance, sets the flag when all data for a connection has been
> +acknowledged.
> +
> +
> +== XPS Configuration
> +
> +XPS is only available if the kernel flag CONFIG_XPS is enabled (on by
s/flag/kconfig symbol/
> +default for smp). The functionality is disabled without any
s/smp/SMP/
> +configuration, in which case the the transmit queue for a packet is
> +selected by using a flow hash as an index into the set of all transmit
> +queues for the device. To enable XPS, the bitmap of CPUs that may use a
> +transmit queue is configured using the sysfs file entry:
> +
> +/sys/class/net/<dev>/queues/tx-<n>/xps_cpus
> +
> +XPS is disabled when it is zero (the default). IRQ-affinity.txt explains
> +how CPUs are assigned to the bitmap.
> +
> +For a network device with a single transmission queue, XPS configuration
> +has no effect, since there is no choice in this case. In a multi-queue
> +system, XPS is usually configured so that each CPU maps onto one queue.
> +If there are as many queues as there are CPUs in the system, then each
> +queue can also map onto one CPU, resulting in exclusive pairings that
> +experience no contention. If there are fewer queues than CPUs, then the
> +best CPUs to share a given queue are probably those that share the cache
> +with the CPU that processes transmit completions for that queue
> +(transmit interrupts).
> +
> +
> +Further Information
> +===================
> +RPS and RFS were introduced in kernel 2.6.35. XPS was incorporated into
> +2.6.38. Original patches were submitted by Tom Herbert
> +(therbert@google.com)
> +
> +
> +Accelerated RFS was introduced in 2.6.35. Original patches were
> +submitted by Ben Hutchings (bhutchings@solarflare.com)
> +
> +Authors:
> +Tom Herbert (therbert@google.com)
> +Willem de Bruijn (willemb@google.com)
> +
> --
Very nice writeup. Thanks.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] net: filter: Convert the BPF VM to threaded code
From: Eric Dumazet @ 2011-08-01 18:37 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: Rui Ueyama, netdev
In-Reply-To: <20110801181652.GB2732@nuttenaction>
Le lundi 01 août 2011 à 20:16 +0200, Hagen Paul Pfeifer a écrit :
> * Rui Ueyama | 2011-07-29 01:10:26 [-0700]:
>
> >Convert the BPF VM to threaded code to improve performance.
> >
> >The BPF VM is basically a big for loop containing a switch statement. That is
> >slow because for each instruction it checks the for loop condition and does the
> >conditional branch of the switch statement.
> >
> >This patch eliminates the conditional branch, by replacing it with jump table
> >using GCC's labels-as-values feature. The for loop condition check can also be
> >removed, because the filter code always end with a RET instruction.
>
> With commit 01f2f3f6ef4d076c I reworked the BPF code so that gcc is in the
> ability to generate a jump table, I double checked this. Not sure what happened
> in the meantime.
>
A switch() always generates one conditional branch, catching values not
enumerated in the "case ..." clauses.
^ permalink raw reply
* [PATCH 2/2] Create a new connector proc_event for successful calls to accept.
From: Joe Damato @ 2011-08-01 18:04 UTC (permalink / raw)
To: zbr; +Cc: netdev, Joe Damato
In-Reply-To: <1312221865-3012-1-git-send-email-joe@boundary.com>
Signed-off-by: Joe Damato <joe@boundary.com>
---
drivers/connector/cn_proc.c | 36 ++++++++++++++++++++++++++++++++++++
include/linux/cn_proc.h | 19 ++++++++++++++++++-
net/socket.c | 3 +++
3 files changed, 57 insertions(+), 1 deletions(-)
diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c
index 3e88d07..1106014 100644
--- a/drivers/connector/cn_proc.c
+++ b/drivers/connector/cn_proc.c
@@ -85,6 +85,42 @@ void proc_connect_connector(struct task_struct *task, struct socket *sock,
cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL);
}
+void proc_accept_connector(struct task_struct *task, struct socket *sock,
+ struct sockaddr *addr, int addrlen)
+{
+ struct cn_msg *msg;
+ struct proc_event *ev;
+ __u8 buffer[CN_PROC_MSG_SIZE];
+ struct timespec ts;
+
+ if (atomic_read(&proc_event_num_listeners) < 1)
+ return;
+
+ msg = (struct cn_msg*)buffer;
+ ev = (struct proc_event*)msg->data;
+ get_seq(&msg->seq, &ev->cpu);
+ ktime_get_ts(&ts); /* get high res monotonic timestamp */
+ put_unaligned(timespec_to_ns(&ts), (__u64 *)&ev->timestamp_ns);
+ ev->what = PROC_EVENT_ACCEPT;
+ ev->event_data.accept.process_pid = task->pid;
+ ev->event_data.accept.process_tgid = task->tgid;
+ ev->event_data.accept.protocol = sock->sk->sk_protocol;
+ ev->event_data.accept.address_len = addrlen;
+ memcpy(&ev->event_data.accept.address, addr, addrlen);
+
+ ev->event_data.accept.local_address_len = sizeof(struct __kernel_sockaddr_storage);
+ kernel_getsockname(sock, (struct sockaddr *) &ev->event_data.accept.local_address,
+ &ev->event_data.accept.local_address_len);
+
+ memcpy(&msg->id, &cn_proc_event_id, sizeof(msg->id));
+ msg->ack = 0; /* not used */
+ msg->len = sizeof(*ev);
+ /* If cn_netlink_send() failed, the data is not sent */
+ cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL);
+
+ return;
+}
+
void proc_fork_connector(struct task_struct *task)
{
struct cn_msg *msg;
diff --git a/include/linux/cn_proc.h b/include/linux/cn_proc.h
index a49ed22..d68a3de 100644
--- a/include/linux/cn_proc.h
+++ b/include/linux/cn_proc.h
@@ -56,7 +56,8 @@ struct proc_event {
PROC_EVENT_SID = 0x00000080,
PROC_EVENT_PTRACE = 0x00000100,
PROC_EVENT_CONNECT = 0x00000400,
- /* "next" should be 0x00000800 */
+ PROC_EVENT_ACCEPT = 0x00000800,
+ /* "next" should be 0x00001000 */
/* "last" is the last process event: exit */
PROC_EVENT_EXIT = 0x80000000
} what;
@@ -90,6 +91,16 @@ struct proc_event {
int protocol;
} connect;
+ struct accept_proc_event {
+ __kernel_pid_t process_pid;
+ __kernel_pid_t process_tgid;
+ struct sockaddr_storage address;
+ int address_len;
+ struct __kernel_sockaddr_storage local_address;
+ int local_address_len;
+ int protocol;
+ } accept;
+
struct id_proc_event {
__kernel_pid_t process_pid;
__kernel_pid_t process_tgid;
@@ -133,6 +144,8 @@ void proc_ptrace_connector(struct task_struct *task, int which_id);
void proc_exit_connector(struct task_struct *task);
void proc_connect_connector(struct task_struct *task, struct socket *sock,
struct sockaddr *addr, int addrlen);
+void proc_accept_connector(struct task_struct *task, struct socket *sock,
+ struct sockaddr *addr, int addrlen);
#else
static inline void proc_fork_connector(struct task_struct *task)
{}
@@ -159,6 +172,10 @@ static inline void proc_connect_connector(struct task_struct *task,
struct sockaddr *addr, int addrlen)
{}
+static inline void proc_accept_connector(struct task_struct *task,
+ struct socket *sock,
+ struct sockaddr *addr, int addrlen)
+{}
#endif /* CONFIG_PROC_EVENTS */
#endif /* __KERNEL__ */
#endif /* CN_PROC_H */
diff --git a/net/socket.c b/net/socket.c
index b4f9a6c..d21a266 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1544,6 +1544,9 @@ SYSCALL_DEFINE4(accept4, int, fd, struct sockaddr __user *, upeer_sockaddr,
goto out_fd;
}
+ proc_accept_connector(current, newsock,
+ (struct sockaddr *)&address, len);
+
/* File flags are not inherited via accept() unlike another OSes. */
fd_install(newfd, newfile);
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/2] Create a new connector proc_event for successful calls to connect.
From: Joe Damato @ 2011-08-01 18:04 UTC (permalink / raw)
To: zbr; +Cc: netdev, Joe Damato
In-Reply-To: <1312221865-3012-1-git-send-email-joe@boundary.com>
Signed-off-by: Joe Damato <joe@boundary.com>
---
drivers/connector/cn_proc.c | 34 ++++++++++++++++++++++++++++++++++
include/linux/cn_proc.h | 22 +++++++++++++++++++++-
net/socket.c | 6 ++++++
3 files changed, 61 insertions(+), 1 deletions(-)
diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c
index 3ee1fdb..3e88d07 100644
--- a/drivers/connector/cn_proc.c
+++ b/drivers/connector/cn_proc.c
@@ -51,6 +51,40 @@ static inline void get_seq(__u32 *ts, int *cpu)
preempt_enable();
}
+void proc_connect_connector(struct task_struct *task, struct socket *sock,
+ struct sockaddr *addr, int addrlen)
+{
+ struct cn_msg *msg;
+ struct proc_event *ev;
+ __u8 buffer[CN_PROC_MSG_SIZE];
+ struct timespec ts;
+
+ if (atomic_read(&proc_event_num_listeners) < 1)
+ return;
+
+ msg = (struct cn_msg*)buffer;
+ ev = (struct proc_event*)msg->data;
+ get_seq(&msg->seq, &ev->cpu);
+ ktime_get_ts(&ts); /* get high res monotonic timestamp */
+ put_unaligned(timespec_to_ns(&ts), (__u64 *)&ev->timestamp_ns);
+ ev->what = PROC_EVENT_CONNECT;
+ ev->event_data.connect.process_pid = task->pid;
+ ev->event_data.connect.process_tgid = task->tgid;
+ ev->event_data.connect.protocol = sock->sk->sk_protocol;
+ ev->event_data.connect.address_len = addrlen;
+ memcpy(&ev->event_data.connect.address, addr, addrlen);
+
+ ev->event_data.connect.local_address_len = sizeof(struct __kernel_sockaddr_storage);
+ kernel_getsockname(sock, (struct sockaddr *) &ev->event_data.connect.local_address,
+ &ev->event_data.connect.local_address_len);
+
+ memcpy(&msg->id, &cn_proc_event_id, sizeof(msg->id));
+ msg->ack = 0; /* not used */
+ msg->len = sizeof(*ev);
+ /* If cn_netlink_send() failed, the data is not sent */
+ cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL);
+}
+
void proc_fork_connector(struct task_struct *task)
{
struct cn_msg *msg;
diff --git a/include/linux/cn_proc.h b/include/linux/cn_proc.h
index 12c517b..a49ed22 100644
--- a/include/linux/cn_proc.h
+++ b/include/linux/cn_proc.h
@@ -19,6 +19,7 @@
#define CN_PROC_H
#include <linux/types.h>
+#include <linux/socket.h>
/*
* Userspace sends this enum to register with the kernel that it is listening
@@ -54,7 +55,8 @@ struct proc_event {
PROC_EVENT_GID = 0x00000040,
PROC_EVENT_SID = 0x00000080,
PROC_EVENT_PTRACE = 0x00000100,
- /* "next" should be 0x00000400 */
+ PROC_EVENT_CONNECT = 0x00000400,
+ /* "next" should be 0x00000800 */
/* "last" is the last process event: exit */
PROC_EVENT_EXIT = 0x80000000
} what;
@@ -78,6 +80,16 @@ struct proc_event {
__kernel_pid_t process_tgid;
} exec;
+ struct connect_proc_event {
+ __kernel_pid_t process_pid;
+ __kernel_pid_t process_tgid;
+ struct __kernel_sockaddr_storage address;
+ int address_len;
+ struct __kernel_sockaddr_storage local_address;
+ int local_address_len;
+ int protocol;
+ } connect;
+
struct id_proc_event {
__kernel_pid_t process_pid;
__kernel_pid_t process_tgid;
@@ -119,6 +131,8 @@ void proc_id_connector(struct task_struct *task, int which_id);
void proc_sid_connector(struct task_struct *task);
void proc_ptrace_connector(struct task_struct *task, int which_id);
void proc_exit_connector(struct task_struct *task);
+void proc_connect_connector(struct task_struct *task, struct socket *sock,
+ struct sockaddr *addr, int addrlen);
#else
static inline void proc_fork_connector(struct task_struct *task)
{}
@@ -139,6 +153,12 @@ static inline void proc_ptrace_connector(struct task_struct *task,
static inline void proc_exit_connector(struct task_struct *task)
{}
+
+static inline void proc_connect_connector(struct task_struct *task,
+ struct socket *sock,
+ struct sockaddr *addr, int addrlen)
+{}
+
#endif /* CONFIG_PROC_EVENTS */
#endif /* __KERNEL__ */
#endif /* CN_PROC_H */
diff --git a/net/socket.c b/net/socket.c
index b1cbbcd..b4f9a6c 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -88,6 +88,8 @@
#include <linux/nsproxy.h>
#include <linux/magic.h>
#include <linux/slab.h>
+#include <linux/connector.h>
+#include <linux/cn_proc.h>
#include <asm/uaccess.h>
#include <asm/unistd.h>
@@ -1596,6 +1598,10 @@ SYSCALL_DEFINE3(connect, int, fd, struct sockaddr __user *, uservaddr,
err = sock->ops->connect(sock, (struct sockaddr *)&address, addrlen,
sock->file->f_flags);
+
+ if (err == 0)
+ proc_connect_connector(current, sock, (struct sockaddr *)&address, addrlen);
+
out_put:
fput_light(sock->file, fput_needed);
out:
--
1.7.4.1
^ permalink raw reply related
* [PATCH 0/2] connector: Add proc_events for connect/accept
From: Joe Damato @ 2011-08-01 18:04 UTC (permalink / raw)
To: zbr; +Cc: netdev, Joe Damato
Hi -
It would be extremely useful to have a simple way of mapping pids to network
connections without having to create piles of inotify watches in /proc/ and
/proc/<pid>/fd/ and then search for corresponding inode numbers in
/proc/net/{tcp, udp, ... }.
I've added two simple connector events so that monitoring processes using
connector can get a notification of successful calls to connect/accept. This
allows a monitoring process to be aware of network connections without having
to jump through the inotify+proc parsing hoops.
Thanks,
Joe
Joe Damato (2):
Create a new connector proc_event for successful calls to connect.
Create a new connector proc_event for successful calls to accept.
drivers/connector/cn_proc.c | 70 +++++++++++++++++++++++++++++++++++++++++++
include/linux/cn_proc.h | 39 +++++++++++++++++++++++-
net/socket.c | 9 +++++
3 files changed, 117 insertions(+), 1 deletions(-)
--
1.7.4.1
^ permalink raw reply
* Re: [PATCH] net: filter: Convert the BPF VM to threaded code
From: Hagen Paul Pfeifer @ 2011-08-01 18:16 UTC (permalink / raw)
To: Rui Ueyama; +Cc: netdev
In-Reply-To: <CACKH++ZfNTB7Y8YhvQnZPEXpwmpWXzxQgnWniamDrjRWUwxaNw@mail.gmail.com>
* Rui Ueyama | 2011-07-29 01:10:26 [-0700]:
>Convert the BPF VM to threaded code to improve performance.
>
>The BPF VM is basically a big for loop containing a switch statement. That is
>slow because for each instruction it checks the for loop condition and does the
>conditional branch of the switch statement.
>
>This patch eliminates the conditional branch, by replacing it with jump table
>using GCC's labels-as-values feature. The for loop condition check can also be
>removed, because the filter code always end with a RET instruction.
With commit 01f2f3f6ef4d076c I reworked the BPF code so that gcc is in the
ability to generate a jump table, I double checked this. Not sure what happened
in the meantime.
Hagen
^ permalink raw reply
* Re: [net-next v2 70/71] tile: Move the Tilera driver
From: Chris Metcalf @ 2011-08-01 17:21 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo, sassmann
In-Reply-To: <1312082850-24914-71-git-send-email-jeffrey.t.kirsher@intel.com>
On 7/30/2011 11:27 PM, Jeff Kirsher wrote:
> Move the Tilera driver into drivers/net/ethernet/tile and
> make the necessary Kconfig and Makefile changes.
>
> CC: Chris Metcalf <cmetcalf@tilera.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> [...]
> +++ b/drivers/net/ethernet/tile/Kconfig
> @@ -0,0 +1,28 @@
> +#
> +# Tilera network device configuration
> +#
> +
> +config NET_VENDOR_TILERA
> + bool "Tilera devices"
> + depends on TILE
> + ---help---
> + If you have a network (Ethernet) card belonging to this class, say Y
> + and read the Ethernet-HOWTO, available from
> + <http://www.tldp.org/docs.html#howto>.
> +
> + Note that the answer to this question doesn't directly affect the
> + kernel: saying N will just cause the configurator to skip all
> + the questions about Tilera cards. If you say Y, you will be asked for
> + your specific card in the following questions.
> +
> +config TILE_NET
> + tristate "Tilera GBE/XGBE network driver support"
> + depends on NET_VENDOR_TILERA && TILE
> + default y
> + select CRC32
> + ---help---
> + This is a standard Linux network device driver for the
> + on-chip Tilera Gigabit Ethernet and XAUI interfaces.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called tile_net.
Overall, this seems fine, since the Tilera drivers get grouped more
appropriately as a result. However, the drivers in question are not
Ethernet cards (and Tilera is not an Ethernet card vendor and has no plans
to become one). Instead, this is the driver support for the built-in
networking hardware on the Tilera multicore CPU chip. I'm happy to group
this support under drivers/net/ethernet/tile/, but I think it's appropriate
to default it to "Y" if you are building a TILE kernel (since you are
guaranteed to have the networking hardware available).
I suspect for now the cleanest thing to do is to fold the two config
options together, using NET_VENDOR_TILERA for consistency with other
NET_VENDOR_xxx symbols, and defaulting it to "Y" via "depends on TILE". I
don't think the Ethernet-HOWO reference is particularly helpful since it
mostly tackles all the various card issues, kernel boot param issues, etc.,
none of which are relevant to this driver. Something like:
+config NET_VENDOR_TILERA
+ bool "Tilera devices"
+ depends on TILE
+ default y
+ select CRC32
+ ---help---
+ This is a standard Linux network device driver for the arch/tile
+ on-chip Gigabit Ethernet and XAUI interfaces.
+
+ To compile this driver as a module, choose M here: the module
+ will be called tile_net.
Obviously you'd also need to tweak the TILE_NET symbol in the Makefile to
be VENDOR_TILERA. If this makes sense to you, go ahead and make the
change, and feel free to use my
Acked-by: Chris Metcalf <cmetcalf@tilera.com>
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: [net-next v2 17/71] myri*: Move the Myricom drivers
From: Jon Mason @ 2011-08-01 17:09 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, netdev, gospo, sassmann, Andrew Gallatin, Brice Goglin
In-Reply-To: <1312082850-24914-18-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jul 30, 2011 at 10:26 PM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> Move the Myricom drivers into drivers/net/ethernet/myricom/ and make
> the necessary Kconfig and Makefile changes.
Acked-by: Jon Mason <mason@myri.com>
> CC: Andrew Gallatin <gallatin@myri.com>
> CC: Brice Goglin <brice@myri.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> MAINTAINERS | 2 +-
> drivers/net/Kconfig | 26 ------------
> drivers/net/Makefile | 1 -
> drivers/net/ethernet/Kconfig | 1 +
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/ethernet/myricom/Kconfig | 42 ++++++++++++++++++++
> drivers/net/ethernet/myricom/Makefile | 5 ++
> .../net/{ => ethernet/myricom}/myri10ge/Makefile | 0
> .../net/{ => ethernet/myricom}/myri10ge/myri10ge.c | 0
> .../{ => ethernet/myricom}/myri10ge/myri10ge_mcp.h | 0
> .../myricom}/myri10ge/myri10ge_mcp_gen_header.h | 0
> 11 files changed, 50 insertions(+), 28 deletions(-)
> create mode 100644 drivers/net/ethernet/myricom/Kconfig
> create mode 100644 drivers/net/ethernet/myricom/Makefile
> rename drivers/net/{ => ethernet/myricom}/myri10ge/Makefile (100%)
> rename drivers/net/{ => ethernet/myricom}/myri10ge/myri10ge.c (100%)
> rename drivers/net/{ => ethernet/myricom}/myri10ge/myri10ge_mcp.h (100%)
> rename drivers/net/{ => ethernet/myricom}/myri10ge/myri10ge_mcp_gen_header.h (100%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ddec2eb..3423692 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4308,7 +4308,7 @@ M: Andrew Gallatin <gallatin@myri.com>
> L: netdev@vger.kernel.org
> W: http://www.myri.com/scs/download-Myri10GE.html
> S: Supported
> -F: drivers/net/myri10ge/
> +F: drivers/net/ethernet/myricom/myri10ge/
>
> NATSEMI ETHERNET DRIVER (DP8381x)
> M: Tim Hockin <thockin@hockin.org>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 56c033a..38fcaea 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -1519,32 +1519,6 @@ config VXGE_DEBUG_TRACE_ALL
> the vxge driver. By default only few debug trace statements are
> enabled.
>
> -config MYRI10GE
> - tristate "Myricom Myri-10G Ethernet support"
> - depends on PCI && INET
> - select FW_LOADER
> - select CRC32
> - select INET_LRO
> - ---help---
> - This driver supports Myricom Myri-10G Dual Protocol interface in
> - Ethernet mode. If the eeprom on your board is not recent enough,
> - you will need a newer firmware image.
> - You may get this image or more information, at:
> -
> - <http://www.myri.com/scs/download-Myri10GE.html>
> -
> - To compile this driver as a module, choose M here. The module
> - will be called myri10ge.
> -
> -config MYRI10GE_DCA
> - bool "Direct Cache Access (DCA) Support"
> - default y
> - depends on MYRI10GE && DCA && !(MYRI10GE=y && DCA=m)
> - ---help---
> - Say Y here if you want to use Direct Cache Access (DCA) in the
> - driver. DCA is a method for warming the CPU cache before data
> - is used, with the intent of lessening the impact of cache misses.
> -
> config PASEMI_MAC
> tristate "PA Semi 1/10Gbit MAC"
> depends on PPC_PASEMI && PCI && INET
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 73e357e..b9e1f5a 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -151,7 +151,6 @@ obj-$(CONFIG_R8169) += r8169.o
> obj-$(CONFIG_IBMVETH) += ibmveth.o
> obj-$(CONFIG_S2IO) += s2io.o
> obj-$(CONFIG_VXGE) += vxge/
> -obj-$(CONFIG_MYRI10GE) += myri10ge/
> obj-$(CONFIG_PXA168_ETH) += pxa168_eth.o
> obj-$(CONFIG_BFIN_MAC) += bfin_mac.o
> obj-$(CONFIG_DM9000) += dm9000.o
> diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
> index 8bbddc9..ce3040d 100644
> --- a/drivers/net/ethernet/Kconfig
> +++ b/drivers/net/ethernet/Kconfig
> @@ -21,6 +21,7 @@ source "drivers/net/ethernet/emulex/Kconfig"
> source "drivers/net/ethernet/intel/Kconfig"
> source "drivers/net/ethernet/i825xx/Kconfig"
> source "drivers/net/ethernet/mellanox/Kconfig"
> +source "drivers/net/ethernet/myricom/Kconfig"
> source "drivers/net/ethernet/qlogic/Kconfig"
> source "drivers/net/ethernet/racal/Kconfig"
> source "drivers/net/ethernet/sfc/Kconfig"
> diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
> index e5f2954..b4dcb93 100644
> --- a/drivers/net/ethernet/Makefile
> +++ b/drivers/net/ethernet/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_NET_VENDOR_EMULEX) += emulex/
> obj-$(CONFIG_NET_VENDOR_INTEL) += intel/
> obj-$(CONFIG_NET_VENDOR_I825XX) += i825xx/
> obj-$(CONFIG_NET_VENDOR_MELLANOX) += mellanox/
> +obj-$(CONFIG_NET_VENDOR_MYRI) += myricom/
> obj-$(CONFIG_NET_VENDOR_QLOGIC) += qlogic/
> obj-$(CONFIG_NET_VENDOR_RACAL) += racal/
> obj-$(CONFIG_SFC) += sfc/
> diff --git a/drivers/net/ethernet/myricom/Kconfig b/drivers/net/ethernet/myricom/Kconfig
> new file mode 100644
> index 0000000..8dc4241
> --- /dev/null
> +++ b/drivers/net/ethernet/myricom/Kconfig
> @@ -0,0 +1,42 @@
> +#
> +# Myricom device configuration
> +#
> +
> +config NET_VENDOR_MYRI
> + bool "Myricom devices"
> + depends on PCI || INET
> + ---help---
> + If you have a network (Ethernet) card belonging to this class, say
> + Y and read the Ethernet-HOWTO, available from
> + <http://www.tldp.org/docs.html#howto>.
> +
> + Note that the answer to this question doesn't directly affect the
> + kernel: saying N will just cause the configurator to skip all
> + the questions about Myricom cards. If you say Y, you will be asked for
> + your specific card in the following questions.
> +
> +config MYRI10GE
> + tristate "Myricom Myri-10G Ethernet support"
> + depends on NET_VENDOR_MYRI && PCI && INET
> + select FW_LOADER
> + select CRC32
> + select INET_LRO
> + ---help---
> + This driver supports Myricom Myri-10G Dual Protocol interface in
> + Ethernet mode. If the eeprom on your board is not recent enough,
> + you will need a newer firmware image.
> + You may get this image or more information, at:
> +
> + <http://www.myri.com/scs/download-Myri10GE.html>
> +
> + To compile this driver as a module, choose M here. The module
> + will be called myri10ge.
> +
> +config MYRI10GE_DCA
> + bool "Direct Cache Access (DCA) Support"
> + default y
> + depends on MYRI10GE && DCA && !(MYRI10GE=y && DCA=m)
> + ---help---
> + Say Y here if you want to use Direct Cache Access (DCA) in the
> + driver. DCA is a method for warming the CPU cache before data
> + is used, with the intent of lessening the impact of cache misses.
> diff --git a/drivers/net/ethernet/myricom/Makefile b/drivers/net/ethernet/myricom/Makefile
> new file mode 100644
> index 0000000..296c0a1
> --- /dev/null
> +++ b/drivers/net/ethernet/myricom/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for the Myricom network device drivers.
> +#
> +
> +obj-$(CONFIG_MYRI10GE) += myri10ge/
> diff --git a/drivers/net/myri10ge/Makefile b/drivers/net/ethernet/myricom/myri10ge/Makefile
> similarity index 100%
> rename from drivers/net/myri10ge/Makefile
> rename to drivers/net/ethernet/myricom/myri10ge/Makefile
> diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
> similarity index 100%
> rename from drivers/net/myri10ge/myri10ge.c
> rename to drivers/net/ethernet/myricom/myri10ge/myri10ge.c
> diff --git a/drivers/net/myri10ge/myri10ge_mcp.h b/drivers/net/ethernet/myricom/myri10ge/myri10ge_mcp.h
> similarity index 100%
> rename from drivers/net/myri10ge/myri10ge_mcp.h
> rename to drivers/net/ethernet/myricom/myri10ge/myri10ge_mcp.h
> diff --git a/drivers/net/myri10ge/myri10ge_mcp_gen_header.h b/drivers/net/ethernet/myricom/myri10ge/myri10ge_mcp_gen_header.h
> similarity index 100%
> rename from drivers/net/myri10ge/myri10ge_mcp_gen_header.h
> rename to drivers/net/ethernet/myricom/myri10ge/myri10ge_mcp_gen_header.h
> --
> 1.7.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [net-next v2 16/71] mlx4: Move the Mellanox driver
From: Eli Cohen @ 2011-08-01 16:15 UTC (permalink / raw)
To: Roland Dreier; +Cc: Jeff Kirsher, davem, netdev, gospo, sassmann
In-Reply-To: <CAG4TOxPP-+DnPmveCryXpiiuQT=kvS65yfMDnph2SumuNM+r_A@mail.gmail.com>
On Mon, Aug 01, 2011 at 06:10:21AM -0700, Roland Dreier wrote:
>
> Hi,
>
> no objection to this, but if we're going to move this code around,
> maybe it makes sense to split the mlx4_core and mlx4_en code
> into separate directories at the same time?
>
Hi Roland,
it makes sense to split the original mlx4 driver into mlx4_en and
mlx4_core. We will submit patches in a few days.
^ permalink raw reply
* Re: [net-next v2 54/71] lantiq: Move the Lantiq SoC driver
From: John Crispin @ 2011-08-01 16:14 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo, sassmann, John Crispin
In-Reply-To: <1312082850-24914-55-git-send-email-jeffrey.t.kirsher@intel.com>
Am 7/31/11 5:27 AM, schrieb Jeff Kirsher:
> Move the Lantiq driver into drivers/net/ethernet/ and the
> necessary Kconfig and Makefile changes.
>
> CC: John Crispin<blogic@openwrt.org>
> Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
Acked-by: John Crispin<blogic@openwrt.org>
^ permalink raw reply
* Re: [Bug?] Machine hangs, rtl8192se possible cause
From: Larry Finger @ 2011-08-01 15:30 UTC (permalink / raw)
To: Jaroslaw Fedewicz
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAFdoEiT54o+NQKO=dAcOXgyf6GJ1E51w_H_p7PJyRmynz8Sbzg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 08/01/2011 08:26 AM, Jaroslaw Fedewicz wrote:
> Hello,
>
> I own a Thinkpad Edge 13 (AMD, machine type 0197) laptop, which is
> shipped with a Realtek 8192 SE WLAN card.
>
> The WLAN support with this particular card was never brilliant under
> Linux, first with (very) flakey drivers from Realtek which would stop
> transmitting packets every so often or panic after a few hours of
> usage. The in-tree drivers are better in this respect, but I'm
> experiencing mysterious hangups every once in a while. The machine is
> effectively dead and has to be power-cycled — no oops, no kernel
> panic, no nothing, it just hangs and that's it.
>
> I'm sure this is not a regression because the hangups were right there
> from the start.
>
> The last meaningful message which might be helpful was: "wait for
> BIT(6) return value X" (I don't remember what X was, it was a while
> ago and only once).
>
> I don't know if there are other means to debug (netconsole over eth0?)
> those hangs. The only other thing I know for sure that I can get a
> week long uptime if I blacklist rtl8192se.ko from loading.
>
> If I can provide any additional information to track the bug (or a
> faulty piece of hardware?) down, please tell me. Google tells me
> nobody reported this before, or it was just me feeding incorrect
> keywords.
>
> Thanks for your kind attention.
>
> P. S. Tried netconsole before, got nothing to pinpoint the error. The
> only recurring pattern I could see in it was that almost every time
> the machine hanged was after ip6tables initialized, at least it was
> the last message in the log.
>
> P. P. S. I don't track netdev@ and linux-wireless@ lists, so please Cc: me.
What kernel are you using? The only problems I've had were some kernel panics
due to improper handling of memory allocation failures with the receive skb's,
but they have been fixed.
It can be difficult to use netconsole to debug problems with wireless devices.
As you prevent rtl8192se from loading automatically, the logging console may
provide some clues. Use the following command to load the driver:
sleep 10 ; modprobe rtl8192se
During the 10 second sleep, use CTRL-ALT-F10 to switch consoles and see if any
messages appear.
Please use 'lspci -nn' to determine which version of the card you have.
Thanks,
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: PROBLEM: BUG (NULL ptr dereference in ipv4_dst_check)
From: synapse @ 2011-08-01 15:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1312190145.2719.2.camel@edumazet-laptop>
On 08/01/11 11:15, Eric Dumazet wrote:
> Le lundi 01 août 2011 à 10:57 +0200, synapse a écrit :
>> Hello
>>
>> Sorry, I wasn't home on the weekend. Exactly to which tree should I
>> apply this?
>> It doesn't apply cleanly to 3.0.0. Am I missing something?
>>
> Could you try latest linux tree ?
>
> We first validate patches on current tree, then backport them if needed
> to previous kernels.
>
> Thanks
>
deployed, we'll see if it works out :)
Gergely Kalman
^ permalink raw reply
* Re: [PATCH net-next 0/5] qlcnic: Fixes and debug support
From: Anirban Chakraborty @ 2011-08-01 15:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <20110801.015706.719035744873995476.davem@davemloft.net>
On Aug 1, 2011, at 1:57 AM, David Miller wrote:
> From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
> Date: Fri, 29 Jul 2011 16:30:30 -0700
>
>> Please apply the series to net-next. Thanks.
>
> Queued up for net-next
Would it be too much of a trouble to push these to net-2.6, as these are minor bug fixes anyway?
Thanks a lot.
-Anirban
^ permalink raw reply
* Re: [GIT] Networking
From: Ingo Molnar @ 2011-08-01 15:13 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20110722.073339.1236244143490935644.davem@davemloft.net>
* David Miller <davem@davemloft.net> wrote:
> forcedeth: do vlan cleanup
Trying to bring latest -git into latest -tip today i managed to
bisect back to a pretty bad networking breakage on one of my
testboxes back to this commit - where i have discovered that it has
been fixed freshly.
This bug cost me multiple days of debugging so here's a bit of a post
mortem.
The bit that IMO wasnt very optimal was the timing of the merge path:
- AuthorDate: Wed Jul 20 04:54:38 2011 +0000
- CommitDate: Thu Jul 21 13:47:57 2011 -0700
- tree Linus merge CommitDate: Fri Jul 22 14:43:13 2011 -0700
- first lkml bugreport: Sun Jul 24 16:10:59 2011 -0700
- fix CommitDate: Wed Jul 27 22:39:30 2011 -0700
- fix Linus merge CommitDate: Thu Jul 28 05:58:19 2011 -0700
So you can see that the commit was committed to net-next within 24
hours of it being submitted, the (bad) breakage was not discovered
until 4 days down the road.
I submit that *no one* with real forcedeth hardware actually tested
this commit before it hit upstream. It has not touched linux-next
before going to Linus and it took 8 days for the fix to get upstream.
If the latency of common driver bugfixes is on the order of 1 week
then the golden rule is that commits must be tested for at least 1
week as well. One day of testing was *way* too short.
Furthermore, the changelog of the fix:
0891b0e08937: forcedeth: fix vlans
Doesn't contain any reference to the bisection work done by
walt <w41ter@gmail.com> nor by any of the other bugreporters.
So this really sucked all around - could we please improve on it?
Thanks,
Ingo
^ permalink raw reply
* [PATCH 1/1] atm: br2864: sent packets truncated in VC routed mode
From: chas williams - CONTRACTOR @ 2011-08-01 15:03 UTC (permalink / raw)
To: netdev; +Cc: pascal, davem, linux-atm-general
hopefully this could be included for the next kernel release.
From: chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
commit 8b5e1c9db2bcd2d13c2db08e6c6dbe66882fa186
Author: chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Date: Mon Aug 1 07:55:07 2011 -0400
atm: br2864: sent packets truncated in VC routed mode
Reported-by: Pascal Hambourg <pascal@plouf.fr.eu.org>
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
diff --git a/net/atm/br2684.c b/net/atm/br2684.c
index 2252c20..52cfd0c 100644
--- a/net/atm/br2684.c
+++ b/net/atm/br2684.c
@@ -242,8 +242,6 @@ static int br2684_xmit_vcc(struct sk_buff *skb, struct net_device *dev,
if (brdev->payload == p_bridged) {
skb_push(skb, 2);
memset(skb->data, 0, 2);
- } else { /* p_routed */
- skb_pull(skb, ETH_HLEN);
}
}
skb_debug(skb);
^ permalink raw reply related
* Re: net-next-2.6 [PATCH 0/7] dccp: add support for dynamic parameter updates
From: Gerrit Renker @ 2011-08-01 14:43 UTC (permalink / raw)
To: David Miller; +Cc: dccp, netdev
In-Reply-To: <20110801.001042.6263177526030880.davem@davemloft.net>
Quoting David S. Miller:
| From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
| Date: Mon, 25 Jul 2011 07:36:29 -0600
|
| > I have also placed this in into a fresh (today's) copy of net-next-2.6, on
| >
| > git://eden-feed.erg.abdn.ac.uk/net-next-2.6 [subtree 'dccp']
|
| I did a test pull and this URL doesn't work:
|
|
Sorry, I must have clobbered something during a subsequent update last week.
I have just regenerated the whole tree from scratch, including the 'dccp' sub-branch,
using today's net-next-2.6, double-checking it running
git ls-remote git://eden-feed.erg.abdn.ac.uk/net-next-2.6 dccp
and doing a test-pull of the dccp sub-tree.
Can you please consider pulling again, from
git://eden-feed.erg.abdn.ac.uk/net-next-2.6 [sub-tree 'dccp']
The patch listing of this set is at
http://eden-feed.erg.abdn.ac.uk/cgi-bin/gitweb.cgi?p=net-next-2.6.git;a=log;h=dccp
Thank you for the update
Gerrit
--
^ permalink raw reply
* Re: [net-next v2 56/71] macb: Move the Atmel driver
From: Nicolas Ferre @ 2011-08-01 14:49 UTC (permalink / raw)
To: Jeff Kirsher, netdev; +Cc: davem, gospo, sassmann, Jamie Iles
In-Reply-To: <1312082850-24914-57-git-send-email-jeffrey.t.kirsher@intel.com>
On 07/31/2011 04:27 AM, Jeff Kirsher wrote:
> Move the Atmel driver into drivers/net/ethernet/cadence/ and
> make the necessary Kconfig and Makefile changes.
>
> CC: Nicolas Ferre<nicolas.ferre@atmel.com>
You can add my:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> CC: Jamie Iles<jamie@jamieiles.com>
> Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
> ---
> MAINTAINERS | 2 +-
> drivers/net/Kconfig | 16 --------
> drivers/net/Makefile | 3 -
> drivers/net/arm/Kconfig | 12 ------
> drivers/net/arm/Makefile | 6 ---
> drivers/net/ethernet/Kconfig | 1 +
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/ethernet/cadence/Kconfig | 40 ++++++++++++++++++++
> drivers/net/ethernet/cadence/Makefile | 6 +++
> drivers/net/{arm => ethernet/cadence}/at91_ether.c | 0
> drivers/net/{arm => ethernet/cadence}/at91_ether.h | 0
> drivers/net/{ => ethernet/cadence}/macb.c | 0
> drivers/net/{ => ethernet/cadence}/macb.h | 0
> 13 files changed, 49 insertions(+), 38 deletions(-)
> delete mode 100644 drivers/net/arm/Kconfig
> delete mode 100644 drivers/net/arm/Makefile
> create mode 100644 drivers/net/ethernet/cadence/Kconfig
> create mode 100644 drivers/net/ethernet/cadence/Makefile
> rename drivers/net/{arm => ethernet/cadence}/at91_ether.c (100%)
> rename drivers/net/{arm => ethernet/cadence}/at91_ether.h (100%)
> rename drivers/net/{ => ethernet/cadence}/macb.c (100%)
> rename drivers/net/{ => ethernet/cadence}/macb.h (100%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 83a51ad..995f504 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1317,7 +1317,7 @@ F: include/video/atmel_lcdc.h
> ATMEL MACB ETHERNET DRIVER
> M: Nicolas Ferre<nicolas.ferre@atmel.com>
> S: Supported
> -F: drivers/net/macb.*
> +F: drivers/net/ethernet/cadence/
>
> ATMEL SPI DRIVER
> M: Nicolas Ferre<nicolas.ferre@atmel.com>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index bb4bc4b..6db322c 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2,9 +2,6 @@
> # Network device configuration
> #
>
> -config HAVE_NET_MACB
> - bool
> -
> menuconfig NETDEVICES
> default y if UML
> depends on NET
> @@ -224,19 +221,6 @@ menuconfig NET_ETHERNET
>
> if NET_ETHERNET
>
> -config MACB
> - tristate "Atmel MACB support"
> - depends on HAVE_NET_MACB
> - select PHYLIB
> - help
> - The Atmel MACB ethernet interface is found on many AT32 and AT91
> - parts. Say Y to include support for the MACB chip.
> -
> - To compile this driver as a module, choose M here: the module
> - will be called macb.
> -
> -source "drivers/net/arm/Kconfig"
> -
> config SH_ETH
> tristate "Renesas SuperH Ethernet support"
> depends on SUPERH&& \
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index d249d76..d7873ba 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -63,9 +63,6 @@ obj-$(CONFIG_ETHOC) += ethoc.o
> obj-$(CONFIG_GRETH) += greth.o
>
> obj-$(CONFIG_DNET) += dnet.o
> -obj-$(CONFIG_MACB) += macb.o
> -
> -obj-$(CONFIG_ARM) += arm/
> obj-$(CONFIG_DEV_APPLETALK) += appletalk/
> obj-$(CONFIG_ETHERNET) += ethernet/
> obj-$(CONFIG_TR) += tokenring/
> diff --git a/drivers/net/arm/Kconfig b/drivers/net/arm/Kconfig
> deleted file mode 100644
> index 57d16b9..0000000
> --- a/drivers/net/arm/Kconfig
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -#
> -# Acorn Network device configuration
> -# These are for Acorn's Expansion card network interfaces
> -#
> -
> -config ARM_AT91_ETHER
> - tristate "AT91RM9200 Ethernet support"
> - depends on ARM&& ARCH_AT91RM9200
> - select MII
> - help
> - If you wish to compile a kernel for the AT91RM9200 and enable
> - ethernet support, then you should always answer Y to this.
> diff --git a/drivers/net/arm/Makefile b/drivers/net/arm/Makefile
> deleted file mode 100644
> index fc0f85c..0000000
> --- a/drivers/net/arm/Makefile
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -# File: drivers/net/arm/Makefile
> -#
> -# Makefile for the ARM network device drivers
> -#
> -
> -obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o
> diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
> index e087337..68a31b9 100644
> --- a/drivers/net/ethernet/Kconfig
> +++ b/drivers/net/ethernet/Kconfig
> @@ -15,6 +15,7 @@ source "drivers/net/ethernet/3com/Kconfig"
> source "drivers/net/ethernet/amd/Kconfig"
> source "drivers/net/ethernet/apple/Kconfig"
> source "drivers/net/ethernet/atheros/Kconfig"
> +source "drivers/net/ethernet/cadence/Kconfig"
> source "drivers/net/ethernet/adi/Kconfig"
> source "drivers/net/ethernet/broadcom/Kconfig"
> source "drivers/net/ethernet/brocade/Kconfig"
> diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
> index 826db27..0e91c4d 100644
> --- a/drivers/net/ethernet/Makefile
> +++ b/drivers/net/ethernet/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_NET_VENDOR_8390) += 8390/
> obj-$(CONFIG_NET_VENDOR_AMD) += amd/
> obj-$(CONFIG_NET_VENDOR_APPLE) += apple/
> obj-$(CONFIG_NET_VENDOR_ATHEROS) += atheros/
> +obj-$(CONFIG_NET_ATMEL) += cadence/
> obj-$(CONFIG_NET_BFIN) += adi/
> obj-$(CONFIG_NET_VENDOR_BROADCOM) += broadcom/
> obj-$(CONFIG_NET_VENDOR_BROCADE) += brocade/
> diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
> new file mode 100644
> index 0000000..4c443da
> --- /dev/null
> +++ b/drivers/net/ethernet/cadence/Kconfig
> @@ -0,0 +1,40 @@
> +#
> +# Atmel device configuration
> +#
> +
> +config HAVE_NET_MACB
> + bool
> +
> +config NET_ATMEL
> + bool "Atmel devices"
> + depends on HAVE_NET_MACB || (ARM&& ARCH_AT91RM9200)
> + ---help---
> + If you have a network (Ethernet) card belonging to this class, say Y.
> + Make sure you know the name of your card. Read the Ethernet-HOWTO,
> + available from<http://www.tldp.org/docs.html#howto>.
> +
> + If unsure, say Y.
> +
> + Note that the answer to this question doesn't directly affect the
> + kernel: saying N will just cause the configurator to skip all
> + the remaining Atmel network card questions. If you say Y, you will be
> + asked for your specific card in the following questions.
> +
> +config ARM_AT91_ETHER
> + tristate "AT91RM9200 Ethernet support"
> + depends on NET_ATMEL&& ARM&& ARCH_AT91RM9200
> + select MII
> + ---help---
> + If you wish to compile a kernel for the AT91RM9200 and enable
> + ethernet support, then you should always answer Y to this.
> +
> +config MACB
> + tristate "Atmel MACB support"
> + depends on NET_ATMEL&& HAVE_NET_MACB
> + select PHYLIB
> + ---help---
> + The Atmel MACB ethernet interface is found on many AT32 and AT91
> + parts. Say Y to include support for the MACB chip.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called macb.
> diff --git a/drivers/net/ethernet/cadence/Makefile b/drivers/net/ethernet/cadence/Makefile
> new file mode 100644
> index 0000000..9068b83
> --- /dev/null
> +++ b/drivers/net/ethernet/cadence/Makefile
> @@ -0,0 +1,6 @@
> +#
> +# Makefile for the Atmel network device drivers.
> +#
> +
> +obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o
> +obj-$(CONFIG_MACB) += macb.o
> diff --git a/drivers/net/arm/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
> similarity index 100%
> rename from drivers/net/arm/at91_ether.c
> rename to drivers/net/ethernet/cadence/at91_ether.c
> diff --git a/drivers/net/arm/at91_ether.h b/drivers/net/ethernet/cadence/at91_ether.h
> similarity index 100%
> rename from drivers/net/arm/at91_ether.h
> rename to drivers/net/ethernet/cadence/at91_ether.h
> diff --git a/drivers/net/macb.c b/drivers/net/ethernet/cadence/macb.c
> similarity index 100%
> rename from drivers/net/macb.c
> rename to drivers/net/ethernet/cadence/macb.c
> diff --git a/drivers/net/macb.h b/drivers/net/ethernet/cadence/macb.h
> similarity index 100%
> rename from drivers/net/macb.h
> rename to drivers/net/ethernet/cadence/macb.h
^ permalink raw reply
* Re: [PATCH] cxgb3i: ref count cdev access to prevent modification while in use
From: Steve Wise @ 2011-08-01 14:42 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, Divy Le Ray, Steve Wise, David S. Miller, Karen Xie
In-Reply-To: <20110801111824.GB23131@hmsreliant.think-freely.org>
>> Signed-off-by: Neil Horman<nhorman@tuxdriver.com>
>> CC: Divy Le Ray<divy@chelsio.com>
>> CC: Steve Wise<swise@chelsio.com>
>> CC: "David S. Miller"<davem@davemloft.net>
> Divy, Steve, I think Dave is waiting for an ACK from one of you to, since you're
> the listed maintainers.
> Neil
Karen is the cxgb3i maintainer, but I just now reviewed the patch and it looks good. Divy is on vacation for a few
weeks. I think its ok to pull it in since Karen already acked it.
Steve.
^ permalink raw reply
* Re: [net-next v2 56/71] macb: Move the Atmel driver
From: Jamie Iles @ 2011-08-01 14:41 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo, sassmann, Nicolas Ferre, Jamie Iles
In-Reply-To: <1312082850-24914-57-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jul 30, 2011 at 08:27:15PM -0700, Jeff Kirsher wrote:
> Move the Atmel driver into drivers/net/ethernet/cadence/ and
> make the necessary Kconfig and Makefile changes.
>
> CC: Nicolas Ferre <nicolas.ferre@atmel.com>
> CC: Jamie Iles <jamie@jamieiles.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Looks good to me.
Acked-by: Jamie Iles <jamie@jamieiles.com>
^ permalink raw reply
* [Bug?] Machine hangs, rtl8192se possible cause
From: Jaroslaw Fedewicz @ 2011-08-01 13:26 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ
Hello,
I own a Thinkpad Edge 13 (AMD, machine type 0197) laptop, which is
shipped with a Realtek 8192 SE WLAN card.
The WLAN support with this particular card was never brilliant under
Linux, first with (very) flakey drivers from Realtek which would stop
transmitting packets every so often or panic after a few hours of
usage. The in-tree drivers are better in this respect, but I'm
experiencing mysterious hangups every once in a while. The machine is
effectively dead and has to be power-cycled — no oops, no kernel
panic, no nothing, it just hangs and that's it.
I'm sure this is not a regression because the hangups were right there
from the start.
The last meaningful message which might be helpful was: "wait for
BIT(6) return value X" (I don't remember what X was, it was a while
ago and only once).
I don't know if there are other means to debug (netconsole over eth0?)
those hangs. The only other thing I know for sure that I can get a
week long uptime if I blacklist rtl8192se.ko from loading.
If I can provide any additional information to track the bug (or a
faulty piece of hardware?) down, please tell me. Google tells me
nobody reported this before, or it was just me feeding incorrect
keywords.
Thanks for your kind attention.
P. S. Tried netconsole before, got nothing to pinpoint the error. The
only recurring pattern I could see in it was that almost every time
the machine hanged was after ip6tables initialized, at least it was
the last message in the log.
P. P. S. I don't track netdev@ and linux-wireless@ lists, so please Cc: me.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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