* Re: [PATCH 1/3] rtlwifi: btcoexist: Remove some unused functions
From: Kalle Valo @ 2015-01-15 13:49 UTC (permalink / raw)
To: Larry Finger
Cc: Rickard Strandqvist, Masanari Iida, Sachin Kamat, linux-wireless,
netdev, linux-kernel
In-Reply-To: <54B15D57.5060709@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> On 01/10/2015 10:24 AM, Rickard Strandqvist wrote:
>> Removes some functions that are not used anywhere:
>> ex_halbtc8821a1ant_periodical() ex_halbtc8821a1ant_pnp_notify()
>> ex_halbtc8821a1ant_halt_notify() ex_halbtc8821a1ant_bt_info_notify()
>> ex_halbtc8821a1ant_special_packet_notify() ex_halbtc8821a1ant_connect_notify()
>> ex_halbtc8821a1ant_scan_notify() ex_halbtc8821a1ant_lps_notify()
>> ex_halbtc8821a1ant_ips_notify() ex_halbtc8821a1ant_display_coex_info()
>> ex_halbtc8821a1ant_init_coex_dm() ex_halbtc8821a1ant_init_hwconfig()
>>
>> This was partially found by using a static code analysis program called cppcheck.
>>
>> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
>
> NACK!!!!!!!!!
>
> I told you to stay away from these routines until I finish my update.
> Not only might you remove some functions that I will be needing later,
> but you run the risk of merge complications.
>
> Kalle: Please ignore EVERYTHING from this person. Obviously, he is
> incapable of understanding even the simplest instructions.
Yeah, I have to agree with that. I think he is just too fixated creating
the patches automatically.
I have dropped the patches.
--
Kalle Valo
^ permalink raw reply
* [PATCH 1/2] csiostor:Remove T4 FCoE support.
From: Praveen Madhavan @ 2015-01-15 13:45 UTC (permalink / raw)
To: netdev, linux-scsi; +Cc: davem, JBottomley, hch, hariprasad, praveenm, varun
In-Reply-To: <cover.1421328605.git.praveenm@chelsio.com>
This patch removes FCoE support for chelsio T4 adapters.
and claims only physical function 6 for chelsio T5 adapters.
Signed-off-by: Praveen Madhavan <praveenm@chelsio.com>
---
drivers/scsi/csiostor/csio_hw.c | 61 +++++++++---------------------------
drivers/scsi/csiostor/csio_hw_chip.h | 43 -------------------------
drivers/scsi/csiostor/csio_init.c | 6 ++--
drivers/scsi/csiostor/csio_wr.c | 15 +++++----
4 files changed, 24 insertions(+), 101 deletions(-)
diff --git a/drivers/scsi/csiostor/csio_hw.c b/drivers/scsi/csiostor/csio_hw.c
index 5c31fa6..35c5f83 100644
--- a/drivers/scsi/csiostor/csio_hw.c
+++ b/drivers/scsi/csiostor/csio_hw.c
@@ -60,37 +60,10 @@ int csio_msi = 2;
static int dev_num;
/* FCoE Adapter types & its description */
-static const struct csio_adap_desc csio_t4_fcoe_adapters[] = {
- {"T440-Dbg 10G", "Chelsio T440-Dbg 10G [FCoE]"},
- {"T420-CR 10G", "Chelsio T420-CR 10G [FCoE]"},
- {"T422-CR 10G/1G", "Chelsio T422-CR 10G/1G [FCoE]"},
- {"T440-CR 10G", "Chelsio T440-CR 10G [FCoE]"},
- {"T420-BCH 10G", "Chelsio T420-BCH 10G [FCoE]"},
- {"T440-BCH 10G", "Chelsio T440-BCH 10G [FCoE]"},
- {"T440-CH 10G", "Chelsio T440-CH 10G [FCoE]"},
- {"T420-SO 10G", "Chelsio T420-SO 10G [FCoE]"},
- {"T420-CX4 10G", "Chelsio T420-CX4 10G [FCoE]"},
- {"T420-BT 10G", "Chelsio T420-BT 10G [FCoE]"},
- {"T404-BT 1G", "Chelsio T404-BT 1G [FCoE]"},
- {"B420-SR 10G", "Chelsio B420-SR 10G [FCoE]"},
- {"B404-BT 1G", "Chelsio B404-BT 1G [FCoE]"},
- {"T480-CR 10G", "Chelsio T480-CR 10G [FCoE]"},
- {"T440-LP-CR 10G", "Chelsio T440-LP-CR 10G [FCoE]"},
- {"AMSTERDAM 10G", "Chelsio AMSTERDAM 10G [FCoE]"},
- {"HUAWEI T480 10G", "Chelsio HUAWEI T480 10G [FCoE]"},
- {"HUAWEI T440 10G", "Chelsio HUAWEI T440 10G [FCoE]"},
- {"HUAWEI STG 10G", "Chelsio HUAWEI STG 10G [FCoE]"},
- {"ACROMAG XAUI 10G", "Chelsio ACROMAG XAUI 10G [FCoE]"},
- {"ACROMAG SFP+ 10G", "Chelsio ACROMAG SFP+ 10G [FCoE]"},
- {"QUANTA SFP+ 10G", "Chelsio QUANTA SFP+ 10G [FCoE]"},
- {"HUAWEI 10Gbase-T", "Chelsio HUAWEI 10Gbase-T [FCoE]"},
- {"HUAWEI T4TOE 10G", "Chelsio HUAWEI T4TOE 10G [FCoE]"}
-};
-
static const struct csio_adap_desc csio_t5_fcoe_adapters[] = {
{"T580-Dbg 10G", "Chelsio T580-Dbg 10G [FCoE]"},
{"T520-CR 10G", "Chelsio T520-CR 10G [FCoE]"},
- {"T522-CR 10G/1G", "Chelsio T452-CR 10G/1G [FCoE]"},
+ {"T522-CR 10G/1G", "Chelsio T522-CR 10G/1G [FCoE]"},
{"T540-CR 10G", "Chelsio T540-CR 10G [FCoE]"},
{"T520-BCH 10G", "Chelsio T520-BCH 10G [FCoE]"},
{"T540-BCH 10G", "Chelsio T540-BCH 10G [FCoE]"},
@@ -107,7 +80,9 @@ static const struct csio_adap_desc csio_t5_fcoe_adapters[] = {
{"T580-LP-CR 40G", "Chelsio T580-LP-CR 40G [FCoE]"},
{"T520-LL-CR 10G", "Chelsio T520-LL-CR 10G [FCoE]"},
{"T560-CR 40G", "Chelsio T560-CR 40G [FCoE]"},
- {"T580-CR 40G", "Chelsio T580-CR 40G [FCoE]"}
+ {"T580-CR 40G", "Chelsio T580-CR 40G [FCoE]"},
+ {"T580-SO 40G", "Chelsio T580-SO 40G [FCoE]"},
+ {"T502-BT 1G", "Chelsio T502-BT 1G [FCoE]"}
};
static void csio_mgmtm_cleanup(struct csio_mgmtm *);
@@ -1716,9 +1691,9 @@ csio_hw_flash_config(struct csio_hw *hw, u32 *fw_cfg_param, char *path)
uint32_t *cfg_data;
int value_to_add = 0;
- if (request_firmware(&cf, CSIO_CF_FNAME(hw), dev) < 0) {
+ if (request_firmware(&cf, FW_CFG_NAME_T5, dev) < 0) {
csio_err(hw, "could not find config file %s, err: %d\n",
- CSIO_CF_FNAME(hw), ret);
+ FW_CFG_NAME_T5, ret);
return -ENOENT;
}
@@ -1758,8 +1733,8 @@ csio_hw_flash_config(struct csio_hw *hw, u32 *fw_cfg_param, char *path)
}
if (ret == 0) {
csio_info(hw, "config file upgraded to %s\n",
- CSIO_CF_FNAME(hw));
- snprintf(path, 64, "%s%s", "/lib/firmware/", CSIO_CF_FNAME(hw));
+ FW_CFG_NAME_T5);
+ snprintf(path, 64, "%s%s", "/lib/firmware/", FW_CFG_NAME_T5);
}
leave:
@@ -2123,9 +2098,9 @@ csio_hw_flash_fw(struct csio_hw *hw, int *reset)
return -EINVAL;
}
- if (request_firmware(&fw, CSIO_FW_FNAME(hw), dev) < 0) {
+ if (request_firmware(&fw, FW_FNAME_T5, dev) < 0) {
csio_err(hw, "could not find firmware image %s, err: %d\n",
- CSIO_FW_FNAME(hw), ret);
+ FW_FNAME_T5, ret);
return -EINVAL;
}
@@ -3207,7 +3182,7 @@ static void csio_ncsi_intr_handler(struct csio_hw *hw)
*/
static void csio_xgmac_intr_handler(struct csio_hw *hw, int port)
{
- uint32_t v = csio_rd_reg32(hw, CSIO_MAC_INT_CAUSE_REG(hw, port));
+ uint32_t v = csio_rd_reg32(hw, T5_PORT_REG(port, MAC_PORT_INT_CAUSE_A));
v &= TXFIFO_PRTY_ERR_F | RXFIFO_PRTY_ERR_F;
if (!v)
@@ -3217,7 +3192,7 @@ static void csio_xgmac_intr_handler(struct csio_hw *hw, int port)
csio_fatal(hw, "XGMAC %d Tx FIFO parity error\n", port);
if (v & RXFIFO_PRTY_ERR_F)
csio_fatal(hw, "XGMAC %d Rx FIFO parity error\n", port);
- csio_wr_reg32(hw, v, CSIO_MAC_INT_CAUSE_REG(hw, port));
+ csio_wr_reg32(hw, v, T5_PORT_REG(port, MAC_PORT_INT_CAUSE_A));
csio_hw_fatal_err(hw);
}
@@ -3966,13 +3941,7 @@ csio_hw_set_description(struct csio_hw *hw, uint16_t ven_id, uint16_t dev_id)
prot_type = (dev_id & CSIO_ASIC_DEVID_PROTO_MASK);
adap_type = (dev_id & CSIO_ASIC_DEVID_TYPE_MASK);
- if (prot_type == CSIO_T4_FCOE_ASIC) {
- memcpy(hw->hw_ver,
- csio_t4_fcoe_adapters[adap_type].model_no, 16);
- memcpy(hw->model_desc,
- csio_t4_fcoe_adapters[adap_type].description,
- 32);
- } else if (prot_type == CSIO_T5_FCOE_ASIC) {
+ if (prot_type == CSIO_T5_FCOE_ASIC) {
memcpy(hw->hw_ver,
csio_t5_fcoe_adapters[adap_type].model_no, 16);
memcpy(hw->model_desc,
@@ -4009,8 +3978,8 @@ csio_hw_init(struct csio_hw *hw)
strcpy(hw->name, CSIO_HW_NAME);
- /* Initialize the HW chip ops with T4/T5 specific ops */
- hw->chip_ops = csio_is_t4(hw->chip_id) ? &t4_ops : &t5_ops;
+ /* Initialize the HW chip ops T5 specific ops */
+ hw->chip_ops = &t5_ops;
/* Set the model & its description */
diff --git a/drivers/scsi/csiostor/csio_hw_chip.h b/drivers/scsi/csiostor/csio_hw_chip.h
index eec98f5..e962d3d 100644
--- a/drivers/scsi/csiostor/csio_hw_chip.h
+++ b/drivers/scsi/csiostor/csio_hw_chip.h
@@ -37,24 +37,14 @@
#include "csio_defs.h"
/* Define MACRO values */
-#define CSIO_HW_T4 0x4000
-#define CSIO_T4_FCOE_ASIC 0x4600
#define CSIO_HW_T5 0x5000
#define CSIO_T5_FCOE_ASIC 0x5600
#define CSIO_HW_CHIP_MASK 0xF000
-#define T4_REGMAP_SIZE (160 * 1024)
#define T5_REGMAP_SIZE (332 * 1024)
-#define FW_FNAME_T4 "cxgb4/t4fw.bin"
#define FW_FNAME_T5 "cxgb4/t5fw.bin"
-#define FW_CFG_NAME_T4 "cxgb4/t4-config.txt"
#define FW_CFG_NAME_T5 "cxgb4/t5-config.txt"
-#define T4FW_VERSION_MAJOR 0x01
-#define T4FW_VERSION_MINOR 0x0B
-#define T4FW_VERSION_MICRO 0x1B
-#define T4FW_VERSION_BUILD 0x00
-
#define T5FW_VERSION_MAJOR 0x01
#define T5FW_VERSION_MINOR 0x0B
#define T5FW_VERSION_MICRO 0x1B
@@ -65,27 +55,15 @@
#define CHELSIO_CHIP_VERSION(code) (((code) >> 12) & 0xf)
#define CHELSIO_CHIP_RELEASE(code) ((code) & 0xf)
-#define CHELSIO_T4 0x4
#define CHELSIO_T5 0x5
enum chip_type {
- T4_A1 = CHELSIO_CHIP_CODE(CHELSIO_T4, 1),
- T4_A2 = CHELSIO_CHIP_CODE(CHELSIO_T4, 2),
- T4_FIRST_REV = T4_A1,
- T4_LAST_REV = T4_A2,
-
T5_A0 = CHELSIO_CHIP_CODE(CHELSIO_T5, 0),
T5_A1 = CHELSIO_CHIP_CODE(CHELSIO_T5, 1),
T5_FIRST_REV = T5_A0,
T5_LAST_REV = T5_A1,
};
-/* Define static functions */
-static inline int csio_is_t4(uint16_t chip)
-{
- return (chip == CSIO_HW_T4);
-}
-
static inline int csio_is_t5(uint16_t chip)
{
return (chip == CSIO_HW_T5);
@@ -95,21 +73,6 @@ static inline int csio_is_t5(uint16_t chip)
#define CSIO_DEVICE(devid, idx) \
{ PCI_VENDOR_ID_CHELSIO, (devid), PCI_ANY_ID, PCI_ANY_ID, 0, 0, (idx) }
-#define CSIO_HW_PIDX(hw, index) \
- (csio_is_t4(hw->chip_id) ? (PIDX_V(index)) : \
- (PIDX_T5_G(index) | DBTYPE_F))
-
-#define CSIO_HW_LP_INT_THRESH(hw, val) \
- (csio_is_t4(hw->chip_id) ? (LP_INT_THRESH_V(val)) : \
- (LP_INT_THRESH_T5_V(val)))
-
-#define CSIO_HW_M_LP_INT_THRESH(hw) \
- (csio_is_t4(hw->chip_id) ? (LP_INT_THRESH_M) : (LP_INT_THRESH_T5_M))
-
-#define CSIO_MAC_INT_CAUSE_REG(hw, port) \
- (csio_is_t4(hw->chip_id) ? (PORT_REG(port, XGMAC_PORT_INT_CAUSE_A)) : \
- (T5_PORT_REG(port, MAC_PORT_INT_CAUSE_A)))
-
#include "t4fw_api.h"
#define FW_VERSION(chip) ( \
@@ -125,11 +88,6 @@ struct fw_info {
char *fw_mod_name;
struct fw_hdr fw_hdr;
};
-#define CSIO_FW_FNAME(hw) \
- (csio_is_t4(hw->chip_id) ? FW_FNAME_T4 : FW_FNAME_T5)
-
-#define CSIO_CF_FNAME(hw) \
- (csio_is_t4(hw->chip_id) ? FW_CFG_NAME_T4 : FW_CFG_NAME_T5)
/* Declare ENUMS */
enum { MEM_EDC0, MEM_EDC1, MEM_MC, MEM_MC0 = MEM_MC, MEM_MC1 };
@@ -163,7 +121,6 @@ struct csio_hw_chip_ops {
void (*chip_dfs_create_ext_mem)(struct csio_hw *);
};
-extern struct csio_hw_chip_ops t4_ops;
extern struct csio_hw_chip_ops t5_ops;
#endif /* #ifndef __CSIO_HW_CHIP_H__ */
diff --git a/drivers/scsi/csiostor/csio_init.c b/drivers/scsi/csiostor/csio_init.c
index 34d20cc..9b9794d 100644
--- a/drivers/scsi/csiostor/csio_init.c
+++ b/drivers/scsi/csiostor/csio_init.c
@@ -1176,9 +1176,8 @@ static struct pci_error_handlers csio_err_handler = {
*/
#define CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN \
static struct pci_device_id csio_pci_tbl[] = {
-/* Define for iSCSI uses PF5, FCoE uses PF6 */
-#define CH_PCI_DEVICE_ID_FUNCTION 0x5
-#define CH_PCI_DEVICE_ID_FUNCTION2 0x6
+/* Define for FCoE uses PF6 */
+#define CH_PCI_DEVICE_ID_FUNCTION 0x6
#define CH_PCI_ID_TABLE_ENTRY(devid) \
{ PCI_VDEVICE(CHELSIO, (devid)), 0 }
@@ -1256,5 +1255,4 @@ MODULE_DESCRIPTION(CSIO_DRV_DESC);
MODULE_LICENSE(CSIO_DRV_LICENSE);
MODULE_DEVICE_TABLE(pci, csio_pci_tbl);
MODULE_VERSION(CSIO_DRV_VERSION);
-MODULE_FIRMWARE(FW_FNAME_T4);
MODULE_FIRMWARE(FW_FNAME_T5);
diff --git a/drivers/scsi/csiostor/csio_wr.c b/drivers/scsi/csiostor/csio_wr.c
index b47ea33..e8f1817 100644
--- a/drivers/scsi/csiostor/csio_wr.c
+++ b/drivers/scsi/csiostor/csio_wr.c
@@ -85,7 +85,7 @@ csio_wr_ring_fldb(struct csio_hw *hw, struct csio_q *flq)
*/
if (flq->inc_idx >= 8) {
csio_wr_reg32(hw, DBPRIO_F | QID_V(flq->un.fl.flid) |
- CSIO_HW_PIDX(hw, flq->inc_idx / 8),
+ PIDX_T5_V(flq->inc_idx / 8) | DBTYPE_F,
MYPF_REG(SGE_PF_KDOORBELL_A));
flq->inc_idx &= 7;
}
@@ -983,7 +983,7 @@ csio_wr_issue(struct csio_hw *hw, int qidx, bool prio)
wmb();
/* Ring SGE Doorbell writing q->pidx into it */
csio_wr_reg32(hw, DBPRIO_V(prio) | QID_V(q->un.eq.physeqid) |
- CSIO_HW_PIDX(hw, q->inc_idx),
+ PIDX_T5_V(q->inc_idx) | DBTYPE_F,
MYPF_REG(SGE_PF_KDOORBELL_A));
q->inc_idx = 0;
@@ -1467,12 +1467,11 @@ csio_wr_set_sge(struct csio_hw *hw)
* and generate an interrupt when this occurs so we can recover.
*/
csio_set_reg_field(hw, SGE_DBFIFO_STATUS_A,
- HP_INT_THRESH_V(HP_INT_THRESH_M) |
- CSIO_HW_LP_INT_THRESH(hw,
- CSIO_HW_M_LP_INT_THRESH(hw)),
- HP_INT_THRESH_V(CSIO_SGE_DBFIFO_INT_THRESH) |
- CSIO_HW_LP_INT_THRESH(hw,
- CSIO_SGE_DBFIFO_INT_THRESH));
+ LP_INT_THRESH_T5_V(LP_INT_THRESH_T5_M),
+ LP_INT_THRESH_T5_V(CSIO_SGE_DBFIFO_INT_THRESH));
+ csio_set_reg_field(hw, SGE_DBFIFO_STATUS2_A,
+ HP_INT_THRESH_T5_V(LP_INT_THRESH_T5_M),
+ HP_INT_THRESH_T5_V(CSIO_SGE_DBFIFO_INT_THRESH));
csio_set_reg_field(hw, SGE_DOORBELL_CONTROL_A, ENABLE_DROP_F,
ENABLE_DROP_F);
--
2.0.2
^ permalink raw reply related
* [PATCH 2/2] csiostor:Removed file csio_hw_t4.c
From: Praveen Madhavan @ 2015-01-15 13:45 UTC (permalink / raw)
To: netdev, linux-scsi; +Cc: davem, JBottomley, hch, hariprasad, praveenm, varun
In-Reply-To: <cover.1421328605.git.praveenm@chelsio.com>
Signed-off-by: Praveen Madhavan <praveenm@chelsio.com>
---
drivers/scsi/csiostor/Makefile | 2 +-
drivers/scsi/csiostor/csio_hw_t4.c | 404 -------------------------------------
2 files changed, 1 insertion(+), 405 deletions(-)
delete mode 100644 drivers/scsi/csiostor/csio_hw_t4.c
diff --git a/drivers/scsi/csiostor/Makefile b/drivers/scsi/csiostor/Makefile
index 913b9a9..3681a3f 100644
--- a/drivers/scsi/csiostor/Makefile
+++ b/drivers/scsi/csiostor/Makefile
@@ -8,5 +8,5 @@ ccflags-y += -I$(srctree)/drivers/net/ethernet/chelsio/cxgb4
obj-$(CONFIG_SCSI_CHELSIO_FCOE) += csiostor.o
csiostor-objs := csio_attr.o csio_init.o csio_lnode.o csio_scsi.o \
- csio_hw.o csio_hw_t4.o csio_hw_t5.o csio_isr.o \
+ csio_hw.o csio_hw_t5.o csio_isr.o \
csio_mb.o csio_rnode.o csio_wr.o
diff --git a/drivers/scsi/csiostor/csio_hw_t4.c b/drivers/scsi/csiostor/csio_hw_t4.c
deleted file mode 100644
index 14884e4..0000000
--- a/drivers/scsi/csiostor/csio_hw_t4.c
+++ /dev/null
@@ -1,404 +0,0 @@
-/*
- * This file is part of the Chelsio FCoE driver for Linux.
- *
- * Copyright (c) 2008-2013 Chelsio Communications, Inc. All rights reserved.
- *
- * This software is available to you under a choice of one of two
- * licenses. You may choose to be licensed under the terms of the GNU
- * General Public License (GPL) Version 2, available from the file
- * OpenIB.org BSD license below:
- *
- * Redistribution and use in source and binary forms, with or
- * without modification, are permitted provided that the following
- * conditions are met:
- *
- * - Redistributions of source code must retain the above
- * copyright notice, this list of conditions and the following
- * - Redistributions in binary form must reproduce the above
- * copyright notice, this list of conditions and the following
- * disclaimer in the documentation and/or other materials
- * provided with the distribution.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
- * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
- * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
- * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
- * SOFTWARE.
- */
-
-#include "csio_hw.h"
-#include "csio_init.h"
-
-/*
- * Return the specified PCI-E Configuration Space register from our Physical
- * Function. We try first via a Firmware LDST Command since we prefer to let
- * the firmware own all of these registers, but if that fails we go for it
- * directly ourselves.
- */
-static uint32_t
-csio_t4_read_pcie_cfg4(struct csio_hw *hw, int reg)
-{
- u32 val = 0;
- struct csio_mb *mbp;
- int rv;
- struct fw_ldst_cmd *ldst_cmd;
-
- mbp = mempool_alloc(hw->mb_mempool, GFP_ATOMIC);
- if (!mbp) {
- CSIO_INC_STATS(hw, n_err_nomem);
- pci_read_config_dword(hw->pdev, reg, &val);
- return val;
- }
-
- csio_mb_ldst(hw, mbp, CSIO_MB_DEFAULT_TMO, reg);
- rv = csio_mb_issue(hw, mbp);
-
- /*
- * If the LDST Command suucceeded, exctract the returned register
- * value. Otherwise read it directly ourself.
- */
- if (rv == 0) {
- ldst_cmd = (struct fw_ldst_cmd *)(mbp->mb);
- val = ntohl(ldst_cmd->u.pcie.data[0]);
- } else
- pci_read_config_dword(hw->pdev, reg, &val);
-
- mempool_free(mbp, hw->mb_mempool);
-
- return val;
-}
-
-static int
-csio_t4_set_mem_win(struct csio_hw *hw, uint32_t win)
-{
- u32 bar0;
- u32 mem_win_base;
-
- /*
- * Truncation intentional: we only read the bottom 32-bits of the
- * 64-bit BAR0/BAR1 ... We use the hardware backdoor mechanism to
- * read BAR0 instead of using pci_resource_start() because we could be
- * operating from within a Virtual Machine which is trapping our
- * accesses to our Configuration Space and we need to set up the PCI-E
- * Memory Window decoders with the actual addresses which will be
- * coming across the PCI-E link.
- */
- bar0 = csio_t4_read_pcie_cfg4(hw, PCI_BASE_ADDRESS_0);
- bar0 &= PCI_BASE_ADDRESS_MEM_MASK;
-
- mem_win_base = bar0 + MEMWIN_BASE;
-
- /*
- * Set up memory window for accessing adapter memory ranges. (Read
- * back MA register to ensure that changes propagate before we attempt
- * to use the new values.)
- */
- csio_wr_reg32(hw, mem_win_base | BIR_V(0) |
- WINDOW_V(ilog2(MEMWIN_APERTURE) - 10),
- PCIE_MEM_ACCESS_REG(PCIE_MEM_ACCESS_BASE_WIN_A, win));
- csio_rd_reg32(hw,
- PCIE_MEM_ACCESS_REG(PCIE_MEM_ACCESS_BASE_WIN_A, win));
- return 0;
-}
-
-/*
- * Interrupt handler for the PCIE module.
- */
-static void
-csio_t4_pcie_intr_handler(struct csio_hw *hw)
-{
- static struct intr_info sysbus_intr_info[] = {
- { RNPP_F, "RXNP array parity error", -1, 1 },
- { RPCP_F, "RXPC array parity error", -1, 1 },
- { RCIP_F, "RXCIF array parity error", -1, 1 },
- { RCCP_F, "Rx completions control array parity error", -1, 1 },
- { RFTP_F, "RXFT array parity error", -1, 1 },
- { 0, NULL, 0, 0 }
- };
- static struct intr_info pcie_port_intr_info[] = {
- { TPCP_F, "TXPC array parity error", -1, 1 },
- { TNPP_F, "TXNP array parity error", -1, 1 },
- { TFTP_F, "TXFT array parity error", -1, 1 },
- { TCAP_F, "TXCA array parity error", -1, 1 },
- { TCIP_F, "TXCIF array parity error", -1, 1 },
- { RCAP_F, "RXCA array parity error", -1, 1 },
- { OTDD_F, "outbound request TLP discarded", -1, 1 },
- { RDPE_F, "Rx data parity error", -1, 1 },
- { TDUE_F, "Tx uncorrectable data error", -1, 1 },
- { 0, NULL, 0, 0 }
- };
-
- static struct intr_info pcie_intr_info[] = {
- { MSIADDRLPERR_F, "MSI AddrL parity error", -1, 1 },
- { MSIADDRHPERR_F, "MSI AddrH parity error", -1, 1 },
- { MSIDATAPERR_F, "MSI data parity error", -1, 1 },
- { MSIXADDRLPERR_F, "MSI-X AddrL parity error", -1, 1 },
- { MSIXADDRHPERR_F, "MSI-X AddrH parity error", -1, 1 },
- { MSIXDATAPERR_F, "MSI-X data parity error", -1, 1 },
- { MSIXDIPERR_F, "MSI-X DI parity error", -1, 1 },
- { PIOCPLPERR_F, "PCI PIO completion FIFO parity error", -1, 1 },
- { PIOREQPERR_F, "PCI PIO request FIFO parity error", -1, 1 },
- { TARTAGPERR_F, "PCI PCI target tag FIFO parity error", -1, 1 },
- { CCNTPERR_F, "PCI CMD channel count parity error", -1, 1 },
- { CREQPERR_F, "PCI CMD channel request parity error", -1, 1 },
- { CRSPPERR_F, "PCI CMD channel response parity error", -1, 1 },
- { DCNTPERR_F, "PCI DMA channel count parity error", -1, 1 },
- { DREQPERR_F, "PCI DMA channel request parity error", -1, 1 },
- { DRSPPERR_F, "PCI DMA channel response parity error", -1, 1 },
- { HCNTPERR_F, "PCI HMA channel count parity error", -1, 1 },
- { HREQPERR_F, "PCI HMA channel request parity error", -1, 1 },
- { HRSPPERR_F, "PCI HMA channel response parity error", -1, 1 },
- { CFGSNPPERR_F, "PCI config snoop FIFO parity error", -1, 1 },
- { FIDPERR_F, "PCI FID parity error", -1, 1 },
- { INTXCLRPERR_F, "PCI INTx clear parity error", -1, 1 },
- { MATAGPERR_F, "PCI MA tag parity error", -1, 1 },
- { PIOTAGPERR_F, "PCI PIO tag parity error", -1, 1 },
- { RXCPLPERR_F, "PCI Rx completion parity error", -1, 1 },
- { RXWRPERR_F, "PCI Rx write parity error", -1, 1 },
- { RPLPERR_F, "PCI replay buffer parity error", -1, 1 },
- { PCIESINT_F, "PCI core secondary fault", -1, 1 },
- { PCIEPINT_F, "PCI core primary fault", -1, 1 },
- { UNXSPLCPLERR_F, "PCI unexpected split completion error", -1,
- 0 },
- { 0, NULL, 0, 0 }
- };
-
- int fat;
- fat = csio_handle_intr_status(hw,
- PCIE_CORE_UTL_SYSTEM_BUS_AGENT_STATUS_A,
- sysbus_intr_info) +
- csio_handle_intr_status(hw,
- PCIE_CORE_UTL_PCI_EXPRESS_PORT_STATUS_A,
- pcie_port_intr_info) +
- csio_handle_intr_status(hw, PCIE_INT_CAUSE_A, pcie_intr_info);
- if (fat)
- csio_hw_fatal_err(hw);
-}
-
-/*
- * csio_t4_flash_cfg_addr - return the address of the flash configuration file
- * @hw: the HW module
- *
- * Return the address within the flash where the Firmware Configuration
- * File is stored.
- */
-static unsigned int
-csio_t4_flash_cfg_addr(struct csio_hw *hw)
-{
- return FLASH_CFG_OFFSET;
-}
-
-/*
- * csio_t4_mc_read - read from MC through backdoor accesses
- * @hw: the hw module
- * @idx: not used for T4 adapter
- * @addr: address of first byte requested
- * @data: 64 bytes of data containing the requested address
- * @ecc: where to store the corresponding 64-bit ECC word
- *
- * Read 64 bytes of data from MC starting at a 64-byte-aligned address
- * that covers the requested address @addr. If @parity is not %NULL it
- * is assigned the 64-bit ECC word for the read data.
- */
-static int
-csio_t4_mc_read(struct csio_hw *hw, int idx, uint32_t addr, __be32 *data,
- uint64_t *ecc)
-{
- int i;
-
- if (csio_rd_reg32(hw, MC_BIST_CMD_A) & START_BIST_F)
- return -EBUSY;
- csio_wr_reg32(hw, addr & ~0x3fU, MC_BIST_CMD_ADDR_A);
- csio_wr_reg32(hw, 64, MC_BIST_CMD_LEN_A);
- csio_wr_reg32(hw, 0xc, MC_BIST_DATA_PATTERN_A);
- csio_wr_reg32(hw, BIST_OPCODE_V(1) | START_BIST_F | BIST_CMD_GAP_V(1),
- MC_BIST_CMD_A);
- i = csio_hw_wait_op_done_val(hw, MC_BIST_CMD_A, START_BIST_F,
- 0, 10, 1, NULL);
- if (i)
- return i;
-
-#define MC_DATA(i) MC_BIST_STATUS_REG(MC_BIST_STATUS_RDATA_A, i)
-
- for (i = 15; i >= 0; i--)
- *data++ = htonl(csio_rd_reg32(hw, MC_DATA(i)));
- if (ecc)
- *ecc = csio_rd_reg64(hw, MC_DATA(16));
-#undef MC_DATA
- return 0;
-}
-
-/*
- * csio_t4_edc_read - read from EDC through backdoor accesses
- * @hw: the hw module
- * @idx: which EDC to access
- * @addr: address of first byte requested
- * @data: 64 bytes of data containing the requested address
- * @ecc: where to store the corresponding 64-bit ECC word
- *
- * Read 64 bytes of data from EDC starting at a 64-byte-aligned address
- * that covers the requested address @addr. If @parity is not %NULL it
- * is assigned the 64-bit ECC word for the read data.
- */
-static int
-csio_t4_edc_read(struct csio_hw *hw, int idx, uint32_t addr, __be32 *data,
- uint64_t *ecc)
-{
- int i;
-
- idx *= EDC_STRIDE;
- if (csio_rd_reg32(hw, EDC_BIST_CMD_A + idx) & START_BIST_F)
- return -EBUSY;
- csio_wr_reg32(hw, addr & ~0x3fU, EDC_BIST_CMD_ADDR_A + idx);
- csio_wr_reg32(hw, 64, EDC_BIST_CMD_LEN_A + idx);
- csio_wr_reg32(hw, 0xc, EDC_BIST_DATA_PATTERN_A + idx);
- csio_wr_reg32(hw, BIST_OPCODE_V(1) | BIST_CMD_GAP_V(1) | START_BIST_F,
- EDC_BIST_CMD_A + idx);
- i = csio_hw_wait_op_done_val(hw, EDC_BIST_CMD_A + idx, START_BIST_F,
- 0, 10, 1, NULL);
- if (i)
- return i;
-
-#define EDC_DATA(i) (EDC_BIST_STATUS_REG(EDC_BIST_STATUS_RDATA_A, i) + idx)
-
- for (i = 15; i >= 0; i--)
- *data++ = htonl(csio_rd_reg32(hw, EDC_DATA(i)));
- if (ecc)
- *ecc = csio_rd_reg64(hw, EDC_DATA(16));
-#undef EDC_DATA
- return 0;
-}
-
-/*
- * csio_t4_memory_rw - read/write EDC 0, EDC 1 or MC via PCIE memory window
- * @hw: the csio_hw
- * @win: PCI-E memory Window to use
- * @mtype: memory type: MEM_EDC0, MEM_EDC1, MEM_MC0 (or MEM_MC) or MEM_MC1
- * @addr: address within indicated memory type
- * @len: amount of memory to transfer
- * @buf: host memory buffer
- * @dir: direction of transfer 1 => read, 0 => write
- *
- * Reads/writes an [almost] arbitrary memory region in the firmware: the
- * firmware memory address, length and host buffer must be aligned on
- * 32-bit boudaries. The memory is transferred as a raw byte sequence
- * from/to the firmware's memory. If this memory contains data
- * structures which contain multi-byte integers, it's the callers
- * responsibility to perform appropriate byte order conversions.
- */
-static int
-csio_t4_memory_rw(struct csio_hw *hw, u32 win, int mtype, u32 addr,
- u32 len, uint32_t *buf, int dir)
-{
- u32 pos, start, offset, memoffset, bar0;
- u32 edc_size, mc_size, mem_reg, mem_aperture, mem_base;
-
- /*
- * Argument sanity checks ...
- */
- if ((addr & 0x3) || (len & 0x3))
- return -EINVAL;
-
- /* Offset into the region of memory which is being accessed
- * MEM_EDC0 = 0
- * MEM_EDC1 = 1
- * MEM_MC = 2 -- T4
- */
- edc_size = EDRAM0_SIZE_G(csio_rd_reg32(hw, MA_EDRAM0_BAR_A));
- if (mtype != MEM_MC1)
- memoffset = (mtype * (edc_size * 1024 * 1024));
- else {
- mc_size = EXT_MEM_SIZE_G(csio_rd_reg32(hw,
- MA_EXT_MEMORY_BAR_A));
- memoffset = (MEM_MC0 * edc_size + mc_size) * 1024 * 1024;
- }
-
- /* Determine the PCIE_MEM_ACCESS_OFFSET */
- addr = addr + memoffset;
-
- /*
- * Each PCI-E Memory Window is programmed with a window size -- or
- * "aperture" -- which controls the granularity of its mapping onto
- * adapter memory. We need to grab that aperture in order to know
- * how to use the specified window. The window is also programmed
- * with the base address of the Memory Window in BAR0's address
- * space. For T4 this is an absolute PCI-E Bus Address. For T5
- * the address is relative to BAR0.
- */
- mem_reg = csio_rd_reg32(hw,
- PCIE_MEM_ACCESS_REG(PCIE_MEM_ACCESS_BASE_WIN_A, win));
- mem_aperture = 1 << (WINDOW_V(mem_reg) + 10);
- mem_base = PCIEOFST_G(mem_reg) << 10;
-
- bar0 = csio_t4_read_pcie_cfg4(hw, PCI_BASE_ADDRESS_0);
- bar0 &= PCI_BASE_ADDRESS_MEM_MASK;
- mem_base -= bar0;
-
- start = addr & ~(mem_aperture-1);
- offset = addr - start;
-
- csio_dbg(hw, "csio_t4_memory_rw: mem_reg: 0x%x, mem_aperture: 0x%x\n",
- mem_reg, mem_aperture);
- csio_dbg(hw, "csio_t4_memory_rw: mem_base: 0x%x, mem_offset: 0x%x\n",
- mem_base, memoffset);
- csio_dbg(hw, "csio_t4_memory_rw: bar0: 0x%x, start:0x%x, offset:0x%x\n",
- bar0, start, offset);
- csio_dbg(hw, "csio_t4_memory_rw: mtype: %d, addr: 0x%x, len: %d\n",
- mtype, addr, len);
-
- for (pos = start; len > 0; pos += mem_aperture, offset = 0) {
- /*
- * Move PCI-E Memory Window to our current transfer
- * position. Read it back to ensure that changes propagate
- * before we attempt to use the new value.
- */
- csio_wr_reg32(hw, pos,
- PCIE_MEM_ACCESS_REG(PCIE_MEM_ACCESS_OFFSET_A, win));
- csio_rd_reg32(hw,
- PCIE_MEM_ACCESS_REG(PCIE_MEM_ACCESS_OFFSET_A, win));
-
- while (offset < mem_aperture && len > 0) {
- if (dir)
- *buf++ = csio_rd_reg32(hw, mem_base + offset);
- else
- csio_wr_reg32(hw, *buf++, mem_base + offset);
-
- offset += sizeof(__be32);
- len -= sizeof(__be32);
- }
- }
- return 0;
-}
-
-/*
- * csio_t4_dfs_create_ext_mem - setup debugfs for MC to read the values
- * @hw: the csio_hw
- *
- * This function creates files in the debugfs with external memory region MC.
- */
-static void
-csio_t4_dfs_create_ext_mem(struct csio_hw *hw)
-{
- u32 size;
- int i = csio_rd_reg32(hw, MA_TARGET_MEM_ENABLE_A);
-
- if (i & EXT_MEM_ENABLE_F) {
- size = csio_rd_reg32(hw, MA_EXT_MEMORY_BAR_A);
- csio_add_debugfs_mem(hw, "mc", MEM_MC,
- EXT_MEM_SIZE_G(size));
- }
-}
-
-/* T4 adapter specific function */
-struct csio_hw_chip_ops t4_ops = {
- .chip_set_mem_win = csio_t4_set_mem_win,
- .chip_pcie_intr_handler = csio_t4_pcie_intr_handler,
- .chip_flash_cfg_addr = csio_t4_flash_cfg_addr,
- .chip_mc_read = csio_t4_mc_read,
- .chip_edc_read = csio_t4_edc_read,
- .chip_memory_rw = csio_t4_memory_rw,
- .chip_dfs_create_ext_mem = csio_t4_dfs_create_ext_mem,
-};
--
2.0.2
^ permalink raw reply related
* [PATCH 0/2] Remove T4 FCoE support
From: Praveen Madhavan @ 2015-01-15 13:45 UTC (permalink / raw)
To: netdev, linux-scsi; +Cc: davem, JBottomley, hch, hariprasad, praveenm, varun
These patches removes FCoE support for chelsio T4 adapter.
Please apply on net-next since depends on previous commits.
Praveen Madhavan (2):
csiostor:Remove T4 FCoE support.
csiostor:Removed file csio_hw_t4.c
drivers/scsi/csiostor/Makefile | 2 +-
drivers/scsi/csiostor/csio_hw.c | 61 ++----
drivers/scsi/csiostor/csio_hw_chip.h | 43 ----
drivers/scsi/csiostor/csio_hw_t4.c | 404 -----------------------------------
drivers/scsi/csiostor/csio_init.c | 6 +-
drivers/scsi/csiostor/csio_wr.c | 15 +-
6 files changed, 25 insertions(+), 506 deletions(-)
delete mode 100644 drivers/scsi/csiostor/csio_hw_t4.c
--
2.0.2
^ permalink raw reply
* Re: Compile-time warnings on mlx4/net-next
From: Or Gerlitz @ 2015-01-15 13:20 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: netdev
In-Reply-To: <54B7BB17.8090308@redhat.com>
On 1/15/2015 3:05 PM, Marcelo Ricardo Leitner wrote:
> Hi Or,
>
> Building net-next.git from today, 4e7a84b1a5bc8094522fd11f628b00c4b4e78b4d,
> I'm seeing these warnings on mlx4:
>
> drivers/net/ethernet/mellanox/mlx4/fw.c: In function ‘mlx4_config_dev_retrieval’:
> drivers/net/ethernet/mellanox/mlx4/fw.c:2136:12: warning: ‘config_dev.rx_checksum_val’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> csum_mask = (config_dev.rx_checksum_val >> CONFIG_DEV_RX_CSUM_MODE_PORT2_BIT_OFFSET) &
> ^
BTW in net-next.git this is line 2155 .. it's 2136 on net.git
> In file included from include/linux/swab.h:4:0,
> from include/uapi/linux/byteorder/little_endian.h:12,
> from include/linux/byteorder/little_endian.h:4,
> from ./arch/x86/include/uapi/asm/byteorder.h:4,
> from include/asm-generic/bitops/le.h:5,
> from ./arch/x86/include/asm/bitops.h:504,
> from include/linux/bitops.h:36,
> from include/linux/kernel.h:10,
> from include/linux/skbuff.h:17,
> from include/linux/if_ether.h:23,
> from include/linux/etherdevice.h:25,
> from drivers/net/ethernet/mellanox/mlx4/fw.c:35:
> include/uapi/linux/swab.h:106:23: warning: ‘config_dev.vxlan_udp_dport’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> (__builtin_constant_p((__u16)(x)) ? \
> ^
> drivers/net/ethernet/mellanox/mlx4/fw.c:2114:25: note: ‘config_dev.vxlan_udp_dport’ was declared here
> struct mlx4_config_dev config_dev;
> ^
>
> Do you see them too?
using $ make W=1 -j 20 SUBDIRS=./drivers/net/ethernet/mellanox/mlx4 with
gcc 4.8.2 I don't see that, but I'll look there,
thanks for the report.
Or.
^ permalink raw reply
* Re: non-OVS based vxlan config broken on 3.19-rc ?!
From: Or Gerlitz @ 2015-01-15 13:25 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: thomas Graf, tom Herbert, Jesse Gross, netdev@vger.kernel.org
In-Reply-To: <54B7B086.7080208@redhat.com>
On 1/15/2015 2:20 PM, Marcelo Ricardo Leitner wrote:
> Just tested your commands on two virtual machines running virtio (same
> host), Linus' commit fb005c47f7b72edac50342b6af490af09854381b (which
> is 3.19.0-rc4+) and it worked just fine for me. That is, ping went
> through both ways without issues. I'll still try with net.git..
thanks for looking on that.
> Did you try dropwatch? If you add a neigh entry for the remote peer
> and ping flood it, you may spot it on dropwatch.
Will try it out, for the time being I managed to have an environment to
test that fix I was working on recently...
Or.
^ permalink raw reply
* Re: [PATCH] e100: Don't enable WoL by default on Toshiba devices
From: Ondrej Zary @ 2015-01-15 13:40 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: David Miller, e1000-devel, netdev, linux-kernel
In-Reply-To: <1415849927.2454.14.camel@jtkirshe-mobl>
On Thursday 13 November 2014, Jeff Kirsher wrote:
> On Wed, 2014-11-12 at 18:18 -0500, David Miller wrote:
> > From: Ondrej Zary <linux@rainbow-software.org>
> > Date: Wed, 12 Nov 2014 23:47:25 +0100
> >
> > > Enabling WoL on some Toshiba laptops (such as Portege R100) causes
> > > battery drain after shutdown (WoL is active even on battery). These
> > > laptops have the WoL bit set in EEPROM ID, causing e100 driver to
> > > enable WoL by default.
> > >
> > > Check subsystem vendor ID and if it's Toshiba, don't enable WoL by
> > > default from EEPROM settings.
> > >
> > > Fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/110784
> > >
> > > Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
> >
> > Jeff, are you gonna pick this up?
>
> Yes, sorry I did not catch it earlier.
What happened to this patch? I don't see it in net.git or net-next.git
(checked both davem's and jkirsher's)
--
Ondrej Zary
^ permalink raw reply
* Re: Compile-time warnings on mlx4/net-next
From: Marcelo Ricardo Leitner @ 2015-01-15 13:38 UTC (permalink / raw)
To: Or Gerlitz; +Cc: netdev
In-Reply-To: <54B7BEAF.6000406@mellanox.com>
On 15-01-2015 11:20, Or Gerlitz wrote:
> On 1/15/2015 3:05 PM, Marcelo Ricardo Leitner wrote:
>> Hi Or,
>>
>> Building net-next.git from today, 4e7a84b1a5bc8094522fd11f628b00c4b4e78b4d,
>> I'm seeing these warnings on mlx4:
>>
>> drivers/net/ethernet/mellanox/mlx4/fw.c: In function
>> ‘mlx4_config_dev_retrieval’:
>> drivers/net/ethernet/mellanox/mlx4/fw.c:2136:12: warning:
>> ‘config_dev.rx_checksum_val’ may be used uninitialized in this function
>> [-Wmaybe-uninitialized]
>> csum_mask = (config_dev.rx_checksum_val >>
>> CONFIG_DEV_RX_CSUM_MODE_PORT2_BIT_OFFSET) &
>> ^
> BTW in net-next.git this is line 2155 .. it's 2136 on net.git
sure?
https://kernel.googlesource.com/pub/scm/linux/kernel/git/davem/net-next/+/4e7a84b1a5bc8094522fd11f628b00c4b4e78b4d/drivers/net/ethernet/mellanox/mlx4/fw.c
or
https://kernel.googlesource.com/pub/scm/linux/kernel/git/davem/net-next/+/master/drivers/net/ethernet/mellanox/mlx4/fw.c
says line 2136 for net-next too
>> In file included from include/linux/swab.h:4:0,
>> from include/uapi/linux/byteorder/little_endian.h:12,
>> from include/linux/byteorder/little_endian.h:4,
>> from ./arch/x86/include/uapi/asm/byteorder.h:4,
>> from include/asm-generic/bitops/le.h:5,
>> from ./arch/x86/include/asm/bitops.h:504,
>> from include/linux/bitops.h:36,
>> from include/linux/kernel.h:10,
>> from include/linux/skbuff.h:17,
>> from include/linux/if_ether.h:23,
>> from include/linux/etherdevice.h:25,
>> from drivers/net/ethernet/mellanox/mlx4/fw.c:35:
>> include/uapi/linux/swab.h:106:23: warning: ‘config_dev.vxlan_udp_dport’ may
>> be used uninitialized in this function [-Wmaybe-uninitialized]
>> (__builtin_constant_p((__u16)(x)) ? \
>> ^
>> drivers/net/ethernet/mellanox/mlx4/fw.c:2114:25: note:
>> ‘config_dev.vxlan_udp_dport’ was declared here
>> struct mlx4_config_dev config_dev;
>> ^
>>
>> Do you see them too?
>
> using $ make W=1 -j 20 SUBDIRS=./drivers/net/ethernet/mellanox/mlx4 with gcc
> 4.8.2 I don't see that, but I'll look there,
> thanks for the report.
Aye, thanks.
Marcelo
^ permalink raw reply
* Re: non-OVS based vxlan config broken on 3.19-rc ?!
From: Marcelo Ricardo Leitner @ 2015-01-15 13:31 UTC (permalink / raw)
To: Or Gerlitz; +Cc: thomas Graf, tom Herbert, Jesse Gross, netdev@vger.kernel.org
In-Reply-To: <54B7BFC9.8070306@mellanox.com>
On 15-01-2015 11:25, Or Gerlitz wrote:
> On 1/15/2015 2:20 PM, Marcelo Ricardo Leitner wrote:
>> Just tested your commands on two virtual machines running virtio (same
>> host), Linus' commit fb005c47f7b72edac50342b6af490af09854381b (which is
>> 3.19.0-rc4+) and it worked just fine for me. That is, ping went through both
>> ways without issues. I'll still try with net.git..
>
> thanks for looking on that.
np. Test based on 4ccce02eb31b847dd6bf8486f037ba1db39403c5 (net.git from a few
hours..) also worked.
>> Did you try dropwatch? If you add a neigh entry for the remote peer and ping
>> flood it, you may spot it on dropwatch.
>
> Will try it out, for the time being I managed to have an environment to test
> that fix I was working on recently...
Cool
Marcelo
^ permalink raw reply
* [PATCH net] net/mlx4: Don't disable vxlan offloads under DMFS-A0 optimized steering
From: Or Gerlitz @ 2015-01-15 13:28 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Matan Barak, Amir Vadai, Or Gerlitz
Except for VXLAN steering rules, all offloads should work as they were
under plain DMFS mode. Fix that by enabling all the offloads under
DMFS-A0 mode, except for VXLAN steering rules.
Fixes: d57febe1a478 "net/mlx4: Add A0 hybrid steering"
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/infiniband/hw/mlx4/main.c | 3 ++-
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 3 ++-
drivers/net/ethernet/mellanox/mlx4/main.c | 3 +--
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c
index 57ecc5b..9117b7a 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -1114,7 +1114,8 @@ static int mlx4_ib_tunnel_steer_add(struct ib_qp *qp, struct ib_flow_attr *flow_
struct mlx4_dev *dev = to_mdev(qp->device)->dev;
int err = 0;
- if (dev->caps.tunnel_offload_mode != MLX4_TUNNEL_OFFLOAD_MODE_VXLAN)
+ if (dev->caps.tunnel_offload_mode != MLX4_TUNNEL_OFFLOAD_MODE_VXLAN ||
+ dev->caps.dmfs_high_steer_mode == MLX4_STEERING_DMFS_A0_STATIC)
return 0; /* do nothing */
ib_flow = flow_attr + 1;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index d0d6dc1..ac6a8f1 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -475,7 +475,8 @@ static int mlx4_en_tunnel_steer_add(struct mlx4_en_priv *priv, unsigned char *ad
{
int err;
- if (priv->mdev->dev->caps.tunnel_offload_mode != MLX4_TUNNEL_OFFLOAD_MODE_VXLAN)
+ if (priv->mdev->dev->caps.tunnel_offload_mode != MLX4_TUNNEL_OFFLOAD_MODE_VXLAN ||
+ priv->mdev->dev->caps.dmfs_high_steer_mode == MLX4_STEERING_DMFS_A0_STATIC)
return 0; /* do nothing */
err = mlx4_tunnel_steer_add(priv->mdev->dev, addr, priv->port, qpn,
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index 5798355..37a1235 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -1745,8 +1745,7 @@ static void choose_tunnel_offload_mode(struct mlx4_dev *dev,
struct mlx4_dev_cap *dev_cap)
{
if (dev->caps.steering_mode == MLX4_STEERING_MODE_DEVICE_MANAGED &&
- dev_cap->flags2 & MLX4_DEV_CAP_FLAG2_VXLAN_OFFLOADS &&
- dev->caps.dmfs_high_steer_mode != MLX4_STEERING_DMFS_A0_STATIC)
+ dev_cap->flags2 & MLX4_DEV_CAP_FLAG2_VXLAN_OFFLOADS)
dev->caps.tunnel_offload_mode = MLX4_TUNNEL_OFFLOAD_MODE_VXLAN;
else
dev->caps.tunnel_offload_mode = MLX4_TUNNEL_OFFLOAD_MODE_NONE;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH RESEND 2/2] wlcore: align member-assigns in a structure-copy block
From: Kalle Valo @ 2015-01-15 13:23 UTC (permalink / raw)
To: Eliad Peller
Cc: Giel van Schijndel, LKML, John W. Linville, Arik Nemtsov,
open list:TI WILINK WIRELES..., open list:NETWORKING DRIVERS
In-Reply-To: <CAB3XZEcm4+=dYC-8_m_7YRdET_wPkWUYHcDuy9mCKdxkCFEnQA@mail.gmail.com>
Eliad Peller <eliad@wizery.com> writes:
> On Fri, Jan 9, 2015 at 7:03 PM, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Giel van Schijndel <me@mortis.eu> writes:
>>
>>> This highlights the differences (e.g. the bug fixed in the previous
>>> commit).
>>>
>>> Signed-off-by: Giel van Schijndel <me@mortis.eu>
>>> ---
>>> drivers/net/wireless/ti/wlcore/acx.c | 22 +++++++++++-----------
>>> 1 file changed, 11 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ti/wlcore/acx.c b/drivers/net/wireless/ti/wlcore/acx.c
>>> index f28fa3b..93a2fa8 100644
>>> --- a/drivers/net/wireless/ti/wlcore/acx.c
>>> +++ b/drivers/net/wireless/ti/wlcore/acx.c
>>> @@ -1715,17 +1715,17 @@ int wl12xx_acx_config_hangover(struct wl1271 *wl)
>>> goto out;
>>> }
>>>
>>> - acx->recover_time = cpu_to_le32(conf->recover_time);
>>> - acx->hangover_period = conf->hangover_period;
>>> - acx->dynamic_mode = conf->dynamic_mode;
>>> - acx->early_termination_mode = conf->early_termination_mode;
>>> - acx->max_period = conf->max_period;
>>> - acx->min_period = conf->min_period;
>>> - acx->increase_delta = conf->increase_delta;
>>> - acx->decrease_delta = conf->decrease_delta;
>>> - acx->quiet_time = conf->quiet_time;
>>> - acx->increase_time = conf->increase_time;
>>> - acx->window_size = conf->window_size;
>>> + acx->recover_time = cpu_to_le32(conf->recover_time);
>>> + acx->hangover_period = conf->hangover_period;
>>> + acx->dynamic_mode = conf->dynamic_mode;
>>> + acx->early_termination_mode = conf->early_termination_mode;
>>> + acx->max_period = conf->max_period;
>>> + acx->min_period = conf->min_period;
>>> + acx->increase_delta = conf->increase_delta;
>>> + acx->decrease_delta = conf->decrease_delta;
>>> + acx->quiet_time = conf->quiet_time;
>>> + acx->increase_time = conf->increase_time;
>>> + acx->window_size = conf->window_size;
>>
>> I would like to get an ACK from one of the wlcore developers if I should
>> apply this (or not).
>
> I don't have a strong opinion here. However, it looks pretty much
> redundant to take a random blob (which was just fixed by a correct
> patch) and re-indent it. The rest of the file doesn't follow this
> style, so i don't see a good reason to apply it here.
Yeah, this should be a driver decision and not just a single change in
one function. Hence I'm dropping patch 2.
--
Kalle Valo
^ permalink raw reply
* [PATCH] net: smc91x: Add Atari EtherNAT support
From: Geert Uytterhoeven @ 2015-01-15 13:06 UTC (permalink / raw)
To: Nicolas Pitre, David S. Miller
Cc: netdev, linux-m68k, Michael Schmitz, Michael Schmitz,
Geert Uytterhoeven
From: Michael Schmitz <schmitzmic@gmail.com>
Add Atari specific code to the smc91x Ethernet driver. This code is used
on the EtherNAT adapter card for the Atari Falcon extension port.
Signed-off-by: Michael Schmitz <schmitz@debian.org>
Tested-by: Christian Steigies <cts@debian.org>
[geert: Sort Kconfig entries, split in hard and soft dependencies]
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
drivers/net/ethernet/smsc/Kconfig | 10 ++++++----
drivers/net/ethernet/smsc/smc91x.h | 21 +++++++++++++++++++++
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/smsc/Kconfig b/drivers/net/ethernet/smsc/Kconfig
index 9468e64e6007bd2e..3e97a8b43147cc7c 100644
--- a/drivers/net/ethernet/smsc/Kconfig
+++ b/drivers/net/ethernet/smsc/Kconfig
@@ -5,8 +5,9 @@
config NET_VENDOR_SMSC
bool "SMC (SMSC)/Western Digital devices"
default y
- depends on ARM || ISA || MAC || ARM64 || MIPS || M32R || SUPERH || \
- BLACKFIN || MN10300 || COLDFIRE || XTENSA || NIOS2 || PCI || PCMCIA
+ depends on ARM || ARM64 || ATARI_ETHERNAT || BLACKFIN || COLDFIRE || \
+ ISA || M32R || MAC || MIPS || MN10300 || NIOS2 || PCI || \
+ PCMCIA || SUPERH || XTENSA
---help---
If you have a network (Ethernet) card belonging to this class, say Y
and read the Ethernet-HOWTO, available from
@@ -38,8 +39,9 @@ config SMC91X
tristate "SMC 91C9x/91C1xxx support"
select CRC32
select MII
- depends on (ARM || M32R || SUPERH || MIPS || BLACKFIN || \
- MN10300 || COLDFIRE || ARM64 || XTENSA || NIOS2) && (!OF || GPIOLIB)
+ depends on !OF || GPIOLIB
+ depends on ARM || ARM64 || ATARI_ETHERNAT || BLACKFIN || COLDFIRE || \
+ M32R || MIPS || MN10300 || NIOS2 || SUPERH || XTENSA
---help---
This is a driver for SMC's 91x series of Ethernet chipsets,
including the SMC91C94 and the SMC91C111. Say Y if you want it
diff --git a/drivers/net/ethernet/smsc/smc91x.h b/drivers/net/ethernet/smsc/smc91x.h
index 2a38dacbbd27fba4..be67baf5f6778d08 100644
--- a/drivers/net/ethernet/smsc/smc91x.h
+++ b/drivers/net/ethernet/smsc/smc91x.h
@@ -216,6 +216,27 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg)
#include <unit/smc91111.h>
+#elif defined(CONFIG_ATARI)
+
+#define SMC_CAN_USE_8BIT 1
+#define SMC_CAN_USE_16BIT 1
+#define SMC_CAN_USE_32BIT 1
+#define SMC_NOWAIT 1
+
+#define SMC_inb(a, r) readb((a) + (r))
+#define SMC_inw(a, r) readw((a) + (r))
+#define SMC_inl(a, r) readl((a) + (r))
+#define SMC_outb(v, a, r) writeb(v, (a) + (r))
+#define SMC_outw(v, a, r) writew(v, (a) + (r))
+#define SMC_outl(v, a, r) writel(v, (a) + (r))
+#define SMC_insw(a, r, p, l) readsw((a) + (r), p, l)
+#define SMC_outsw(a, r, p, l) writesw((a) + (r), p, l)
+#define SMC_insl(a, r, p, l) readsl((a) + (r), p, l)
+#define SMC_outsl(a, r, p, l) writesl((a) + (r), p, l)
+
+#define RPC_LSA_DEFAULT RPC_LED_100_10
+#define RPC_LSB_DEFAULT RPC_LED_TX_RX
+
#elif defined(CONFIG_ARCH_MSM)
#define SMC_CAN_USE_8BIT 0
--
1.9.1
^ permalink raw reply related
* Compile-time warnings on mlx4/net-next
From: Marcelo Ricardo Leitner @ 2015-01-15 13:05 UTC (permalink / raw)
To: Or Gerlitz; +Cc: netdev
Hi Or,
Building net-next.git from today, 4e7a84b1a5bc8094522fd11f628b00c4b4e78b4d,
I'm seeing these warnings on mlx4:
drivers/net/ethernet/mellanox/mlx4/fw.c: In function ‘mlx4_config_dev_retrieval’:
drivers/net/ethernet/mellanox/mlx4/fw.c:2136:12: warning: ‘config_dev.rx_checksum_val’ may be used uninitialized in this function [-Wmaybe-uninitialized]
csum_mask = (config_dev.rx_checksum_val >> CONFIG_DEV_RX_CSUM_MODE_PORT2_BIT_OFFSET) &
^
In file included from include/linux/swab.h:4:0,
from include/uapi/linux/byteorder/little_endian.h:12,
from include/linux/byteorder/little_endian.h:4,
from ./arch/x86/include/uapi/asm/byteorder.h:4,
from include/asm-generic/bitops/le.h:5,
from ./arch/x86/include/asm/bitops.h:504,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/skbuff.h:17,
from include/linux/if_ether.h:23,
from include/linux/etherdevice.h:25,
from drivers/net/ethernet/mellanox/mlx4/fw.c:35:
include/uapi/linux/swab.h:106:23: warning: ‘config_dev.vxlan_udp_dport’ may be used uninitialized in this function [-Wmaybe-uninitialized]
(__builtin_constant_p((__u16)(x)) ? \
^
drivers/net/ethernet/mellanox/mlx4/fw.c:2114:25: note: ‘config_dev.vxlan_udp_dport’ was declared here
struct mlx4_config_dev config_dev;
^
Do you see them too?
Marcelo
^ permalink raw reply
* Re: [ 2375.793397] WARNING: CPU: 0 PID: 1149 at net/netlink/genetlink.c:1037 genl_unbind+0xc0/0xd0()
From: Johannes Berg @ 2015-01-15 13:01 UTC (permalink / raw)
To: Jeff Layton; +Cc: netdev
In-Reply-To: <20150115074956.4e5617cd@tlielax.poochiereds.net>
On Thu, 2015-01-15 at 07:49 -0500, Jeff Layton wrote:
> It may have. I just recently started playing with trinity, so I don't
> know much about what it does. I do see these sorts of messages in the
> logs that imply that it's opening netlink sockets:
>
> [main] fd[661] = domain:16 (PF_NETLINK) type:0x2 protocol:10
> [main] fd[675] = domain:16 (PF_NETLINK) type:0x2 protocol:0
>
> ...and then it does random I/Os on those fds.
Yes. We're looking for generic netlink, so one of these (protocol 16):
[main] fd[427] = domain:16 (PF_NETLINK) type:0x3 protocol:16
[main] fd[442] = domain:16 (PF_NETLINK) type:0x2 protocol:16
[main] fd[774] = domain:16 (PF_NETLINK) type:0x2 protocol:16
However, I didn't see much happening on these fds, and even if it
wouldn't have recorded the kind of messages.
OTOH, multicast group stuff is done with setsockopt() and/or bind, which
I didn't really find here?
> FWIW, it tries to call delete_module, but I was running this as an
> unprivileged user so I don't think that can succeed.
Ok.
johannes
^ permalink raw reply
* Re: [PATCH net-next v13 0/3] add hisilicon hip04 ethernet driver
From: Ding Tianhong @ 2015-01-15 12:56 UTC (permalink / raw)
To: Alexander Graf, Arnd Bergmann
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-lFZ/pmaqli7XmaaqVzeoHQ
In-Reply-To: <54B7B4E7.8030108-l3A5Bk7waGM@public.gmane.org>
On 2015/1/15 20:39, Alexander Graf wrote:
>
>
> On 15.01.15 10:42, Arnd Bergmann wrote:
>> On Thursday 15 January 2015 16:37:23 Ding Tianhong wrote:
>>> On 2015/1/14 18:19, Alexander Graf wrote:
>>>>
>>>> >From a 10000 feet perspective it looks like two problems to me
>>>>
>>>> 1) Allocation failure doesn't get handled properly somewhere
>>
>> This is the bug that Eric pointed out as well.
>>
>>>> 2) We fail to allocate with order=0 - I don't see why
>>
>> GFP_ATOMIC. When allocating from a the napi poll function in softirq
>> context, you have to use nonblocking allocations, which occasionally
>> fail. This should not cause any harm other than dropped packets.
>>
>>> is it easy to repetition this bug? how big is your memory on your board,
>>> is it happened in your previous hip04 driver?
>>
>> It should be independent of memory size, but may be more likely if you
>> don't have swap space configured.
>
> With the previous driver I was unable to get this far - I ended up in
> random memory corruption and had a ~90% packet loss after about an hour
> of uptime.
>
> I'm not sure whether it's easy to reproduce, I merely started up a few
> VMs, did some disk I/O and started to compile QEMU in the background ;).
>
> I'll happily give your follow up patch that's going to fix the memory
> allocation problems a try though.
>
Thanks for your work, I am sure we could make it much more better:)
Ding
>
> Alex
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
From: Kalle Valo @ 2015-01-15 12:52 UTC (permalink / raw)
To: Arend van Spriel
Cc: Fu, Zhonghui, brudley-dY08KVG/lbpWk0Htik3J/w, Franky Lin,
meuleman-dY08KVG/lbpWk0Htik3J/w, linville-2XuSBdqkA4R54TAoqtyWWQ,
pieterpg-dY08KVG/lbpWk0Htik3J/w, hdegoede-H+wXaHxf7aLQT0dZR+AlfA,
wens-jdAy2FN1RRM, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-kernel@vger.kernel.org
In-Reply-To: <54B39B59.8000907-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Arend van Spriel <arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> writes:
> On 01/12/15 07:41, Fu, Zhonghui wrote:
>> From 8685c3c2746b4275fc808d9db23c364b2f54b52a Mon Sep 17 00:00:00 2001
>> From: Zhonghui Fu<zhonghui.fu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> Date: Mon, 12 Jan 2015 14:25:46 +0800
>> Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
>>
>> WiFi chip has 2 SDIO functions, and PM core will trigger
>> twice suspend/resume operations for one WiFi chip to do
>> the same things. This patch avoid this case.
>>
>> Acked-by: Arend van Spriel<arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>> Acked-by: Sergei Shtylyov<sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
>> Signed-off-by: Zhonghui Fu<zhonghui.fu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>
> This patch needs to be rebased.
>
> Kalle,
>
> Please drop this one.
Ok, dropped. I'll wait for the rebase.
--
Kalle Valo
--
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: [ 2375.793397] WARNING: CPU: 0 PID: 1149 at net/netlink/genetlink.c:1037 genl_unbind+0xc0/0xd0()
From: Jeff Layton @ 2015-01-15 12:49 UTC (permalink / raw)
To: Johannes Berg; +Cc: Jeff Layton, netdev
In-Reply-To: <1421324985.1962.5.camel@sipsolutions.net>
On Thu, 15 Jan 2015 13:29:45 +0100
Johannes Berg <johannes@sipsolutions.net> wrote:
> On Thu, 2015-01-15 at 07:14 -0500, Jeff Layton wrote:
>
> > I was able to reproduce it again this morning. This time it generated
> > 28 warnings (all with similar stack traces to the one I posted
> > yesterday).
>
> Thanks. I just took a look at this, and it seems that sadly it doesn't
> include netlink messages in the log? At least I didn't find them - so I
> don't really know what happened. What I was thinking happened would
> (mostly) play out over netlink messages.
>
(re-cc'ing netdev -- I sent Johannes the log in a private email as
it was 12M compressed)
It may have. I just recently started playing with trinity, so I don't
know much about what it does. I do see these sorts of messages in the
logs that imply that it's opening netlink sockets:
[main] fd[661] = domain:16 (PF_NETLINK) type:0x2 protocol:10
[main] fd[675] = domain:16 (PF_NETLINK) type:0x2 protocol:0
...and then it does random I/Os on those fds.
> > I haven't tested your patchset out yet, but I can try to do that
> > later.
>
> You won't be able to reproduce the warning with it since I removed it
> there. I'm reasonably certain though that you triggered one of the two
> cases I found, more likely the former that doesn't involve removing
> genetlink families (don't see how you could have done that with trinity
> unless it randomly loads and unloads modules?)
>
Ok, sounds good.
FWIW, it tries to call delete_module, but I was running this as an
unprivileged user so I don't think that can succeed.
--
Jeff Layton <jlayton@primarydata.com>
^ permalink raw reply
* pull-request: mac80211 2015-01-15
From: Johannes Berg @ 2015-01-15 12:48 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi,
Hope it's not too late for 3.19 - we found two more issues, pull request
below.
Thanks,
johannes
The following changes since commit 1e359a5de861a57aa04d92bb620f52a5c1d7f8b1:
Revert "mac80211: Fix accounting of the tailroom-needed counter" (2015-01-05 10:33:46 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2015-01-15
for you to fetch changes up to 20658702e08ecd693236b443837d28863b93e872:
cfg80211: fix deadlock during reg chan check (2015-01-07 14:53:46 +0100)
----------------------------------------------------------------
Just two fixes - one for an uninialized variable and
one for a deadlock in regulatory processing.
----------------------------------------------------------------
Arik Nemtsov (1):
cfg80211: fix deadlock during reg chan check
John Linville (1):
mac80211: uninitialized return val in __ieee80211_sta_handle_tspec_ac_params
net/mac80211/mlme.c | 2 +-
net/wireless/reg.c | 56 ++++++++++++++++++++++++++++++++---------------------
2 files changed, 35 insertions(+), 23 deletions(-)
--
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: [PATCH 6/8] adm8211: fix error return code
From: Kalle Valo @ 2015-01-15 12:45 UTC (permalink / raw)
To: Julia Lawall; +Cc: kernel-janitors, linux-wireless, netdev, linux-kernel
In-Reply-To: <1419872683-32709-7-git-send-email-Julia.Lawall@lip6.fr>
Julia Lawall <Julia.Lawall@lip6.fr> writes:
> Return a negative error code on failure.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> identifier ret; expression e1,e2;
> @@
> (
> if (\(ret < 0\|ret != 0\))
> { ... return ret; }
> |
> ret = 0
> )
> ... when != ret = e1
> when != &ret
> *if(...)
> {
> ... when != ret = e2
> when forall
> return ret;
> }
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Thanks, applied to wireless-drivers-next.git.
--
Kalle Valo
^ permalink raw reply
* pull-request: mac80211-next 2015-01-15
From: Johannes Berg @ 2015-01-15 12:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi,
My first pull request for -next, sorry I dragged my feet on this.
I merged mac80211.git to avoid some conflicts, but the content was in
net-next already anyway.
Let me know if there's any issue or any format changes you'd like to make.
Thanks,
johannes
The following changes since commit 28a9bc68124c319b2b3dc861e80828a8865fd1ba:
mac80211: free management frame keys when removing station (2014-12-17 14:00:17 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2015-01-15
for you to fetch changes up to baf1b99ba169bdd3324ac9d99bc2a00c25534429:
cfg80211: docs: remove station_info_flags (2015-01-14 13:57:36 +0100)
----------------------------------------------------------------
Here's a big pile of changes for this round.
We have
* a lot of regulatory code changes to deal with the
way newer Intel devices handle this
* a change to drop packets while disconnecting from
an AP instead of trying to wait for them
* a new attempt at improving the tailroom accounting
to not kick in too much for performance reasons
* improvements in wireless link statistics
* many other small improvements and small fixes that
didn't seem necessary for 3.19 (e.g. in hwsim which
is testing only code)
----------------------------------------------------------------
Andrew Clausen (1):
rfkill: document rfkill module parameters
Arik Nemtsov (8):
cfg80211: allow usermode to query wiphy specific regdom
cfg80211: return private regdom for self-managed devices
cfg80211: avoid intersection when applying self-managed reg
nl80211: increase the max number of rules in regdomain
mac80211: skip disabled channels in VHT check
mac80211: add TDLS supported channels correctly
cfg80211: introduce sync regdom set API for self-managed
cfg80211: avoid reg-hints in self-managed only systems
Chaya Rachel Ivgi (1):
mac80211: Fix ignored HT override configurations
Eliad Peller (6):
mac80211: update sta bw on ht chanwidth action frame
mac80211: avoid reconfig if no interfaces are up
mac80211: fix dot11MulticastTransmittedFrameCount tested address
mac80211: remove local->radar_detect_enabled
mac80211: consider only relevant vifs for radar_required calculation
mac80211: don't defer scans in case of radar detection
Emmanuel Grumbach (1):
mac80211: let flush() drop packets when possible
Felix Fietkau (1):
mac80211: minstrel: reduce size of struct minstrel_rate_stats
Gautam Kumar Shukla (1):
cfg80211: add extensible feature flag attribute
Ido Yariv (1):
mac80211: Re-fix accounting of the tailroom-needed counter
Janusz Dziedzic (1):
mac80211: notify NSS changed when IBSS and HT
Johannes Berg (22):
cfg80211: use __force __rcu to suppress sparse warning
mac80211: ask driver to look at power level when starting AP
mac80211: move U-APSD enablement to vif flags
mac80211_hwsim: fix check for custom world regdom array size
Revert "mac80211: Fix accounting of the tailroom-needed counter"
nl80211: document NL80211_BSS_STATUS_AUTHENTICATED isn't used
nl80211: define multicast group names in header
Merge branch 'mac80211' into mac80211-next
cfg80211: remove "channel" from survey names
cfg80211: allow survey data to return global data
cfg80211: add scan time to survey data
cfg80211: allow including station info in delete event
mac80211: send statistics with delete station event
mac80211: allow drivers to provide most station statistics
cfg80211: remove enum station_info_flags
cfg80211: add nl80211 beacon-only statistics
nl80211: clarify packet statistics descriptions
nl80211: support per-TID station statistics
mac80211: provide per-TID RX/TX MSDU counters
mac80211_hwsim: fix PS debugfs file locking
mac80211: fix handling TIM IE when stations disconnect
cfg80211: docs: remove station_info_flags
Jonathan Doron (1):
cfg80211: allow wiphy specific regdomain management
Jukka Rissanen (2):
nl80211: Convert sched_scan_req pointer to RCU pointer
nl80211: Stop scheduled scan if netlink client disappears
Luciano Coelho (3):
mac80211: notify channel switch at the end of ieee80211_chswitch_post_beacon()
mac80211: remove unused variable in ieee80211_parse_ch_switch_ie()
nl80211: send netdetect configuration info in NL80211_CMD_GET_WOWLAN
Moshe Benji (1):
mac80211: handle power constraint and country IEs in RRM
Nishikawa, Kenzoh (1):
mac80211: keep sending peer candidate events while in listen state
Sujith Manoharan (2):
mac80211: Move IEEE80211_TX_CTL_PS_RESPONSE
mac80211: Fix accounting of multicast frames
Vadim Kochan (1):
wireless: Support of IFLA_INFO_KIND rtnl attribute
Documentation/DocBook/80211.tmpl | 1 -
Documentation/kernel-parameters.txt | 12 +
Documentation/rfkill.txt | 3 +
drivers/net/wireless/ath/ath10k/mac.c | 3 +-
drivers/net/wireless/ath/ath10k/wmi.c | 8 +-
drivers/net/wireless/ath/ath5k/mac80211-ops.c | 16 +-
drivers/net/wireless/ath/ath6kl/cfg80211.c | 14 +-
drivers/net/wireless/ath/ath6kl/main.c | 1 -
drivers/net/wireless/ath/ath9k/link.c | 16 +-
drivers/net/wireless/ath/ath9k/xmit.c | 6 +-
drivers/net/wireless/ath/carl9170/cmd.c | 12 +-
drivers/net/wireless/ath/carl9170/main.c | 6 +-
drivers/net/wireless/ath/wil6210/cfg80211.c | 18 +-
drivers/net/wireless/ath/wil6210/wmi.c | 1 -
drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 11 +-
drivers/net/wireless/cw1200/main.c | 1 -
drivers/net/wireless/cw1200/sta.c | 4 +-
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 13 +-
drivers/net/wireless/libertas/cfg.c | 12 +-
drivers/net/wireless/mac80211_hwsim.c | 30 +-
drivers/net/wireless/mwifiex/cfg80211.c | 17 +-
drivers/net/wireless/mwifiex/uap_event.c | 1 -
drivers/net/wireless/mwl8k.c | 12 +-
drivers/net/wireless/p54/eeprom.c | 6 +-
drivers/net/wireless/p54/main.c | 10 +-
drivers/net/wireless/p54/txrx.c | 12 +-
drivers/net/wireless/rndis_wlan.c | 4 +-
drivers/net/wireless/rt2x00/rt2800lib.c | 12 +-
drivers/net/wireless/ti/wl1251/main.c | 5 +-
drivers/net/wireless/ti/wlcore/main.c | 22 +-
drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c | 9 +-
drivers/staging/wlan-ng/cfg80211.c | 4 +-
include/net/cfg80211.h | 253 +++++----
include/net/mac80211.h | 48 +-
include/net/regulatory.h | 19 +
include/uapi/linux/nl80211.h | 176 +++++-
net/mac80211/cfg.c | 7 +-
net/mac80211/chan.c | 37 +-
net/mac80211/debugfs.c | 2 -
net/mac80211/driver-ops.h | 30 +-
net/mac80211/ethtool.c | 26 +-
net/mac80211/ibss.c | 11 +-
net/mac80211/ieee80211_i.h | 8 +-
net/mac80211/iface.c | 2 +-
net/mac80211/key.c | 9 +-
net/mac80211/main.c | 4 -
net/mac80211/mesh_plink.c | 7 +
net/mac80211/mlme.c | 81 ++-
net/mac80211/offchannel.c | 4 +-
net/mac80211/pm.c | 2 +-
net/mac80211/rc80211_minstrel.c | 6 +-
net/mac80211/rc80211_minstrel.h | 15 +-
net/mac80211/rx.c | 20 +-
net/mac80211/scan.c | 8 +-
net/mac80211/spectmgmt.c | 4 -
net/mac80211/sta_info.c | 175 ++++--
net/mac80211/sta_info.h | 12 +
net/mac80211/status.c | 26 +-
net/mac80211/tdls.c | 32 +-
net/mac80211/trace.h | 33 +-
net/mac80211/tx.c | 5 +-
net/mac80211/util.c | 29 +-
net/mac80211/vht.c | 73 +--
net/wireless/core.c | 40 +-
net/wireless/core.h | 11 +-
net/wireless/nl80211.c | 627 ++++++++++++++-------
net/wireless/nl80211.h | 16 +-
net/wireless/reg.c | 160 +++++-
net/wireless/reg.h | 1 +
net/wireless/scan.c | 13 +-
net/wireless/trace.h | 31 +-
net/wireless/wext-compat.c | 10 +-
72 files changed, 1614 insertions(+), 761 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next v13 0/3] add hisilicon hip04 ethernet driver
From: Alexander Graf @ 2015-01-15 12:39 UTC (permalink / raw)
To: Arnd Bergmann, Ding Tianhong
Cc: robh+dt, davem, grant.likely, sergei.shtylyov, linux-arm-kernel,
eric.dumazet, xuwei5, zhangfei.gao, netdev, devicetree, linux
In-Reply-To: <14674609.dERhba4yMV@wuerfel>
On 15.01.15 10:42, Arnd Bergmann wrote:
> On Thursday 15 January 2015 16:37:23 Ding Tianhong wrote:
>> On 2015/1/14 18:19, Alexander Graf wrote:
>>>
>>> >From a 10000 feet perspective it looks like two problems to me
>>>
>>> 1) Allocation failure doesn't get handled properly somewhere
>
> This is the bug that Eric pointed out as well.
>
>>> 2) We fail to allocate with order=0 - I don't see why
>
> GFP_ATOMIC. When allocating from a the napi poll function in softirq
> context, you have to use nonblocking allocations, which occasionally
> fail. This should not cause any harm other than dropped packets.
>
>> is it easy to repetition this bug? how big is your memory on your board,
>> is it happened in your previous hip04 driver?
>
> It should be independent of memory size, but may be more likely if you
> don't have swap space configured.
With the previous driver I was unable to get this far - I ended up in
random memory corruption and had a ~90% packet loss after about an hour
of uptime.
I'm not sure whether it's easy to reproduce, I merely started up a few
VMs, did some disk I/O and started to compile QEMU in the background ;).
I'll happily give your follow up patch that's going to fix the memory
allocation problems a try though.
Alex
^ permalink raw reply
* RE: [net-next 10/17] i40e: clean up PTP log messages
From: David Laight @ 2015-01-15 12:34 UTC (permalink / raw)
To: 'Jeff Kirsher', davem@davemloft.net
Cc: Shannon Nelson, netdev@vger.kernel.org, nhorman@redhat.com,
sassmann@redhat.com, jogreene@redhat.com, Jacob Keller
In-Reply-To: <1421324368-6860-11-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher
> From: Shannon Nelson <shannon.nelson@intel.com>
>
> The netdev name at init time often defaults to eth0 but later gets changed
> by UDEV, so printing it here is misleading.
Without the interface name you stand zero chance of working out which one it is.
With it, and provided all the interface renames get into dmesg, you stand
at least some chance.
If you have several interfaces that use the same driver, but are subtly
different you can have a hard enough time as it is working out what is
going on.
I know it is too late now, but UDEV should never have been allowed to
rename devices, instead it should have added 'alias' names.
Then you would stand some chance of working out which was which.
> This patch removes the name
> from the log messages, and removes the use of __func__ as we're not using
> that any more in the driver.
I can't remember, do these messages contain the name of the driver (as
well as the device id string).
You might need some help when grepping the kernel source to find where
the messages are coming from.
David
^ permalink raw reply
* Re: [PATCH] ethernet: atheros: Add nss-gmac driver
From: Arnd Bergmann @ 2015-01-15 12:34 UTC (permalink / raw)
To: wstephen
Cc: jcliburn, grant.likely, robh+dt, linux-kernel, netdev, devicetree
In-Reply-To: <bca0eaf2183036ff6a913daea6e09ad9.squirrel@www.codeaurora.org>
On Thursday 15 January 2015 08:12:51 wstephen@codeaurora.org wrote:
>
> The nss-gmac driver is for the internal GMAC IP in the Qualcomm IPQ806x
> SoC. There are 2 ARM cores and 2 NSS cores inside the IPQ806x SoC. The
> main purpose of these NSS cores is to offload the networking stack from
> the ARM cores to achieve high performance at routing/ipsec..etc without
> exhausting the ARM core CPU cycles. There is another nss-drv driver for
> the NSS cores.
I see.
> The nss-gmac driver is designed to work standalone or with the nss-drv
> driver so the switchable data plane overlay was implemented. When it
> worked standalone, the data plane is running on the ARM core as a standard
> networking driver.
How do you decide which way it gets used on a particular system?
> The nss-drv driver can take over the data plane and
> offload it to the NSS cores. The STMicro stmmac driver does not have this
> kind of overlay design so is not suitable for IPQ806x. This is why we
> don't based on the stmmac driver
Which kind of offload is implemented specifically? 'data plane' sounds
fairly generic and could mean anything, and the code isn't readable enough
in its current form for me to find out.
Arnd
^ permalink raw reply
* Re: [PATCH net-next v13 3/3] net: hisilicon: new hip04 ethernet driver
From: Arnd Bergmann @ 2015-01-15 12:30 UTC (permalink / raw)
To: Ding Tianhong
Cc: Eric Dumazet, robh+dt, davem, grant.likely, agraf,
sergei.shtylyov, linux-arm-kernel, xuwei5, zhangfei.gao, netdev,
devicetree, linux
In-Reply-To: <54B796A3.7040200@huawei.com>
On Thursday 15 January 2015 18:29:55 Ding Tianhong wrote:
>
> Yes, thanks, fix them later.
Please note that now that as v13 has now shown up in net-next, I guess
all other patches need to be based on top of what is already merged,
and address one issue at a time.
There is one more issue I saw during build testing, which is the
lack of a MODULE_LICENSE statement for the main driver, although
there is one in the mdio driver.
Arnd
^ permalink raw reply
* Re: non-OVS based vxlan config broken on 3.19-rc ?!
From: Marcelo Ricardo Leitner @ 2015-01-15 12:20 UTC (permalink / raw)
To: Or Gerlitz, thomas Graf
Cc: Or Gerlitz, tom Herbert, Jesse Gross, netdev@vger.kernel.org
In-Reply-To: <CAJ3xEMj+rjTmk2tbVCTMCp+7N0qwXBNf3JsbJEgh2qvq0jHmEg@mail.gmail.com>
On 14-01-2015 18:55, Or Gerlitz wrote:
> On Wed, Jan 14, 2015 at 5:52 PM, thomas Graf <tgraf@suug.ch> wrote:
>> On 01/14/15 at 05:18pm, Or Gerlitz wrote:
>>> Guys, just realized that non-OVS based vxlan config is broken with
>>> 3.19-rc... I see that it works for me on 3.18.2 and breaks on 3.19-rc3
>>> (Linus tree). Tested over mlx4 (both offloaded and non offloaded modes) and
>>> igb, see below the simplest form I can see it breaks on 3.19-rcand works on
>>> 3.18
>>>
>>> Looking on tcpdump and stats, the arp reply arrives to the 3.19-rc host NIC
>>> driver but is dropped along the stack beforehanded to the vxlan driver, not
>>> sure where and why...
>>
>> As additional data point: I tested the VXLAN-GBP with iproute2 based tunnels
>> on net-next and that works fine. Driver used was a e1000 in KVM.
>
>
> mm, so net-next.git (3.20 candidate code) and 3.18 works, but @ least
> for me 3.19-rc doesn't - could you check if net.git works for you on
> iproute2 based tunnels in that env? just vxlan is enough.
>
Hi,
Just tested your commands on two virtual machines running virtio (same host),
Linus' commit fb005c47f7b72edac50342b6af490af09854381b (which is 3.19.0-rc4+)
and it worked just fine for me. That is, ping went through both ways without
issues.
I'll still try with net.git..
Did you try dropwatch? If you add a neigh entry for the remote peer and ping
flood it, you may spot it on dropwatch.
Marcelo
^ 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