* [PATCH net-next 0/3] Add support in ethtool to get expansion ROM version
From: Hariprasad Shenai @ 2015-02-04 12:49 UTC (permalink / raw)
To: netdev; +Cc: davem, ben, leedom, anish, nirranjan, kumaras, Hariprasad Shenai
Hi
This series adds support to get expansion ROM version via ethtool getdrvinfo.
PATCH 1/3 ("ethtool: rename reserved1 memeber in ethtool_drvinfo for expansion
ROM version") is created against net-next tree.
PATCH 2/3 ("cxgb4: Add support in cxgb4 to get expansion rom version via
ethtool") is created against net-next tree.
PATCH 3/3 ("ethtool: Add support to get expansion ROM version in ethtool
getdrvinfo") is created against ethtool tree.
We have included all the maintainers of respective trees. Kindly review the
change and let us know in case of any review comments.
Thanks
Hariprasad Shenai (3):
ethtool: rename reserved1 memeber in ethtool_drvinfo for expansion
ROM version
cxgb4: Add support in cxgb4 to get expansion rom version via ethtool
ethtool: Add support to get expansion ROM version in ethtool getdrvinfo
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 9 +++++
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 37 +++++++++++++++++++++++
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 8 +++++
include/uapi/linux/ethtool.h | 3 +-
5 files changed, 57 insertions(+), 1 deletions(-)
---
ethtool-copy.h | 3 ++-
ethtool.c | 2 ++
2 files changed, 4 insertions(+), 1 deletions(-)
^ permalink raw reply
* [PATCH net-next 1/3] ethtool: rename reserved1 memeber in ethtool_drvinfo for expansion ROM version
From: Hariprasad Shenai @ 2015-02-04 12:49 UTC (permalink / raw)
To: netdev; +Cc: davem, ben, leedom, anish, nirranjan, kumaras, Hariprasad Shenai
In-Reply-To: <1423054176-26420-1-git-send-email-hariprasad@chelsio.com>
Renamed the reserved1 member of struct ethtool_drvinfo to erom_version to get
expansion/option ROM version of the adapter if present.
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
include/uapi/linux/ethtool.h | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 5f66d9c..bd80f0f 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -148,6 +148,7 @@ static inline __u32 ethtool_cmd_speed(const struct ethtool_cmd *ep)
* not be an empty string.
* @version: Driver version string; may be an empty string
* @fw_version: Firmware version string; may be an empty string
+ * @erom_version: Expansion ROM version string; may be an empty string
* @bus_info: Device bus address. This should match the dev_name()
* string for the underlying bus device, if there is one. May be
* an empty string.
@@ -176,7 +177,7 @@ struct ethtool_drvinfo {
char version[32];
char fw_version[ETHTOOL_FWVERS_LEN];
char bus_info[ETHTOOL_BUSINFO_LEN];
- char reserved1[32];
+ char erom_version[32];
char reserved2[12];
__u32 n_priv_flags;
__u32 n_stats;
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 2/3] cxgb4: Add support in cxgb4 to get expansion rom version via ethtool
From: Hariprasad Shenai @ 2015-02-04 12:49 UTC (permalink / raw)
To: netdev; +Cc: davem, ben, leedom, anish, nirranjan, kumaras, Hariprasad Shenai
In-Reply-To: <1423054176-26420-1-git-send-email-hariprasad@chelsio.com>
Add support to get option/expansion rom version flashed in the adapter via
ethtool getdrvinfo function.
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 9 +++++
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 37 +++++++++++++++++++++++
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 8 +++++
4 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 55019c9..63231bf 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -1120,6 +1120,7 @@ int t4_fw_upgrade(struct adapter *adap, unsigned int mbox,
unsigned int t4_flash_cfg_addr(struct adapter *adapter);
int t4_get_fw_version(struct adapter *adapter, u32 *vers);
int t4_get_tp_version(struct adapter *adapter, u32 *vers);
+int t4_get_exprom_version(struct adapter *adapter, u32 *vers);
int t4_prep_fw(struct adapter *adap, struct fw_info *fw_info,
const u8 *fw_data, unsigned int fw_size,
struct fw_hdr *card_fw, enum dev_state state, int *reset);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 041742b..16639c7 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -1419,6 +1419,7 @@ static int get_eeprom_len(struct net_device *dev)
static void get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
{
struct adapter *adapter = netdev2adap(dev);
+ u32 exprom_vers;
strlcpy(info->driver, KBUILD_MODNAME, sizeof(info->driver));
strlcpy(info->version, DRV_VERSION, sizeof(info->version));
@@ -1436,6 +1437,14 @@ static void get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
FW_HDR_FW_VER_MINOR_G(adapter->params.tp_vers),
FW_HDR_FW_VER_MICRO_G(adapter->params.tp_vers),
FW_HDR_FW_VER_BUILD_G(adapter->params.tp_vers));
+
+ if (!t4_get_exprom_version(adapter, &exprom_vers))
+ snprintf(info->erom_version, sizeof(info->erom_version),
+ "%u.%u.%u.%u",
+ FW_HDR_FW_VER_MAJOR_G(exprom_vers),
+ FW_HDR_FW_VER_MINOR_G(exprom_vers),
+ FW_HDR_FW_VER_MICRO_G(exprom_vers),
+ FW_HDR_FW_VER_BUILD_G(exprom_vers));
}
static void get_strings(struct net_device *dev, u32 stringset, u8 *data)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index ea16c62..ae69796 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -948,6 +948,43 @@ int t4_get_tp_version(struct adapter *adapter, u32 *vers)
1, vers, 0);
}
+/**
+ * t4_get_exprom_version - return the Expansion ROM version (if any)
+ * @adapter: the adapter
+ * @vers: where to place the version
+ *
+ * Reads the Expansion ROM header from FLASH and returns the version
+ * number (if present) through the @vers return value pointer. We return
+ * this in the Firmware Version Format since it's convenient. Return
+ * 0 on success, -ENOENT if no Expansion ROM is present.
+ */
+int t4_get_exprom_version(struct adapter *adap, u32 *vers)
+{
+ struct exprom_header {
+ unsigned char hdr_arr[16]; /* must start with 0x55aa */
+ unsigned char hdr_ver[4]; /* Expansion ROM version */
+ } *hdr;
+ u32 exprom_header_buf[DIV_ROUND_UP(sizeof(struct exprom_header),
+ sizeof(u32))];
+ int ret;
+
+ ret = t4_read_flash(adap, FLASH_EXP_ROM_START,
+ ARRAY_SIZE(exprom_header_buf), exprom_header_buf,
+ 0);
+ if (ret)
+ return ret;
+
+ hdr = (struct exprom_header *)exprom_header_buf;
+ if (hdr->hdr_arr[0] != 0x55 || hdr->hdr_arr[1] != 0xaa)
+ return -ENOENT;
+
+ *vers = (FW_HDR_FW_VER_MAJOR_V(hdr->hdr_ver[0]) |
+ FW_HDR_FW_VER_MINOR_V(hdr->hdr_ver[1]) |
+ FW_HDR_FW_VER_MICRO_V(hdr->hdr_ver[2]) |
+ FW_HDR_FW_VER_BUILD_V(hdr->hdr_ver[3]));
+ return 0;
+}
+
/* Is the given firmware API compatible with the one the driver was compiled
* with?
*/
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
index 1e72cda..c009627 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
@@ -3012,21 +3012,29 @@ enum fw_hdr_chip {
#define FW_HDR_FW_VER_MAJOR_S 24
#define FW_HDR_FW_VER_MAJOR_M 0xff
+#define FW_HDR_FW_VER_MAJOR_V(x) \
+ ((x) << FW_HDR_FW_VER_MAJOR_S)
#define FW_HDR_FW_VER_MAJOR_G(x) \
(((x) >> FW_HDR_FW_VER_MAJOR_S) & FW_HDR_FW_VER_MAJOR_M)
#define FW_HDR_FW_VER_MINOR_S 16
#define FW_HDR_FW_VER_MINOR_M 0xff
+#define FW_HDR_FW_VER_MINOR_V(x) \
+ ((x) << FW_HDR_FW_VER_MINOR_S)
#define FW_HDR_FW_VER_MINOR_G(x) \
(((x) >> FW_HDR_FW_VER_MINOR_S) & FW_HDR_FW_VER_MINOR_M)
#define FW_HDR_FW_VER_MICRO_S 8
#define FW_HDR_FW_VER_MICRO_M 0xff
+#define FW_HDR_FW_VER_MICRO_V(x) \
+ ((x) << FW_HDR_FW_VER_MICRO_S)
#define FW_HDR_FW_VER_MICRO_G(x) \
(((x) >> FW_HDR_FW_VER_MICRO_S) & FW_HDR_FW_VER_MICRO_M)
#define FW_HDR_FW_VER_BUILD_S 0
#define FW_HDR_FW_VER_BUILD_M 0xff
+#define FW_HDR_FW_VER_BUILD_V(x) \
+ ((x) << FW_HDR_FW_VER_BUILD_S)
#define FW_HDR_FW_VER_BUILD_G(x) \
(((x) >> FW_HDR_FW_VER_BUILD_S) & FW_HDR_FW_VER_BUILD_M)
--
1.7.1
^ permalink raw reply related
* [PATCH 3/3] ethtool: Add support to get expansion ROM version in ethtool getdrvinfo
From: Hariprasad Shenai @ 2015-02-04 12:49 UTC (permalink / raw)
To: netdev; +Cc: davem, ben, leedom, anish, nirranjan, kumaras, Hariprasad Shenai
In-Reply-To: <1423054176-26420-1-git-send-email-hariprasad@chelsio.com>
Rename the reserved1 field of ethtool_drvinfo to erom_version, and use it to get
the expansion ROM version of the adapter.
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
ethtool-copy.h | 3 ++-
ethtool.c | 2 ++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 61b78fc..e2df0e5 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -148,6 +148,7 @@ static __inline__ __u32 ethtool_cmd_speed(const struct ethtool_cmd *ep)
* not be an empty string.
* @version: Driver version string; may be an empty string
* @fw_version: Firmware version string; may be an empty string
+ * @erom_version: Expansion ROM version string; may be an empty string
* @bus_info: Device bus address. This should match the dev_name()
* string for the underlying bus device, if there is one. May be
* an empty string.
@@ -176,7 +177,7 @@ struct ethtool_drvinfo {
char version[32];
char fw_version[ETHTOOL_FWVERS_LEN];
char bus_info[ETHTOOL_BUSINFO_LEN];
- char reserved1[32];
+ char erom_version[32];
char reserved2[12];
__u32 n_priv_flags;
__u32 n_stats;
diff --git a/ethtool.c b/ethtool.c
index bf583f3..b7d2206 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -701,6 +701,7 @@ static int dump_drvinfo(struct ethtool_drvinfo *info)
"driver: %.*s\n"
"version: %.*s\n"
"firmware-version: %.*s\n"
+ "expansion-rom-version: %.*s\n"
"bus-info: %.*s\n"
"supports-statistics: %s\n"
"supports-test: %s\n"
@@ -710,6 +711,7 @@ static int dump_drvinfo(struct ethtool_drvinfo *info)
(int)sizeof(info->driver), info->driver,
(int)sizeof(info->version), info->version,
(int)sizeof(info->fw_version), info->fw_version,
+ (int)sizeof(info->erom_version), info->erom_version,
(int)sizeof(info->bus_info), info->bus_info,
info->n_stats ? "yes" : "no",
info->testinfo_len ? "yes" : "no",
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] net: core/dev: fix sparse warning
From: Lad, Prabhakar @ 2015-02-04 12:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev, LKML, Eric Dumazet
In-Reply-To: <1423053695.907.117.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, Feb 4, 2015 at 12:41 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2015-02-04 at 12:25 +0000, Lad Prabhakar wrote:
>> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>>
>> this patch fixes following sparse warning:
>> net/core/dev.c: In function 'validate_xmit_skb_list':
>> net/core/dev.c:2720: warning: 'tail' may be used uninitialized in this function
>>
>> Although its a false positive, as head is assigned to NULL in the
>> beginning, due which later in the loop tail is assigned to skb->prev.
>>
>> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
>> ---
>> net/core/dev.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 8ce0d1a..c736467 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -2717,7 +2717,7 @@ out_null:
>>
>> struct sk_buff *validate_xmit_skb_list(struct sk_buff *skb, struct net_device *dev)
>> {
>> - struct sk_buff *next, *head = NULL, *tail;
>> + struct sk_buff *next, *head = NULL, *tail = NULL;
>>
>> for (; skb != NULL; skb = next) {
>> next = skb->next;
>
> Which gcc/sparse versions are you using ?
>
I tried it on gcc 4.3.3 and sparse with 0.4.5-rc1 version.
Regards,
--Prabhakar Lad
^ permalink raw reply
* Re: Throughput regression with `tcp: refine TSO autosizing`
From: Michal Kazior @ 2015-02-04 12:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-wireless, Network Development, eyalpe
In-Reply-To: <1423053531.907.115.camel@edumazet-glaptop2.roam.corp.google.com>
On 4 February 2015 at 13:38, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2015-02-04 at 13:22 +0100, Michal Kazior wrote:
>> On 4 February 2015 at 12:57, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>>
>> > To disable gso you would have to use :
>> >
>> > ethtool -K wlan1 gso off
>>
>> Oh, thanks! This works. However I can't turn it on:
>>
>> ; ethtool -K wlan1 gso on
>> Could not change any device features
>>
>> ..so I guess it makes no sense to re-run tests because:
>>
>> ; ethtool -k wlan1 | grep generic
>> tx-checksum-ip-generic: on [fixed]
>> generic-segmentation-offload: off [requested on]
>> generic-receive-offload: on
>>
>> And this seems to never change.
>
> GSO requires SG (Scatter Gather)
>
> Are you sure this hardware has no SG support ?
The hardware itself seems to be capable. The firmware is a problem
though. I'm also not sure if mac80211 can handle this as is. No 802.11
driver seems to support SG except wil6210 which uses cfg80211 and
netdevs directly.
Michał
^ permalink raw reply
* Re: Throughput regression with `tcp: refine TSO autosizing`
From: Johannes Berg @ 2015-02-04 12:55 UTC (permalink / raw)
To: Michal Kazior; +Cc: Eric Dumazet, linux-wireless, Network Development, eyalpe
In-Reply-To: <CA+BoTQ=qmCZz4CmSOvCOzMLowrDEG12XBffkTcYxjGqVD9604g@mail.gmail.com>
On Wed, 2015-02-04 at 13:53 +0100, Michal Kazior wrote:
> The hardware itself seems to be capable. The firmware is a problem
> though. I'm also not sure if mac80211 can handle this as is. No 802.11
> driver seems to support SG except wil6210 which uses cfg80211 and
> netdevs directly.
mac80211 cannot deal with this right now. This would make a good topic
for the workshop since there's interest elsewhere in this as well. It's
probably not terribly hard to do as far as mac80211 is concerned.
How much offload do you really have though? Sometimes people just want
to build A-MSDUs.
johannes
^ permalink raw reply
* Re: [E1000-devel] [PATCH 1/3] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode
From: Jeff Kirsher @ 2015-02-04 12:57 UTC (permalink / raw)
To: Hiroshi Shimamoto
Cc: Alexander Duyck, Skidmore, Donald C, Bjørn Mork,
e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Choi, Sy Jong, linux-kernel@vger.kernel.org, David Laight,
Hayato Momma
In-Reply-To: <7F861DC0615E0C47A872E6F3C5FCDDBD05E1908D@BPXM14GP.gisp.nec.co.jp>
[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]
On Fri, 2015-01-30 at 11:37 +0000, Hiroshi Shimamoto wrote:
> From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
>
> The limitation of the number of multicast address for VF is not enough
> for the large scale server with SR-IOV feature.
> IPv6 requires the multicast MAC address for each IP address to handle
> the Neighbor Solicitation message.
> We couldn't assign over 30 IPv6 addresses to a single VF interface.
>
> The easy way to solve this is enabling multicast promiscuous mode.
> It is good to have a functionality to enable multicast promiscuous
> mode
> for each VF from VF driver.
>
> This patch introduces the new mbox API, IXGBE_VF_SET_MC_PROMISC, to
> enable/disable multicast promiscuous mode in VF. If multicast
> promiscuous
> mode is enabled the VF can receive all multicast packets.
>
> With this patch, the ixgbevf driver automatically enable multicast
> promiscuous mode when the number of multicast addresses is over than
> 30
> if possible.
>
> This also bump the API version up to 1.2 to check whether the API,
> IXGBE_VF_SET_MC_PROMISC is available.
>
> Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
> Reviewed-by: Hayato Momma <h-momma@ce.jp.nec.com>
> CC: Choi, Sy Jong <sy.jong.choi@intel.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 +
> drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 4 +
> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 89
> ++++++++++++++++++++++-
> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 13 +++-
> drivers/net/ethernet/intel/ixgbevf/mbx.h | 4 +
> drivers/net/ethernet/intel/ixgbevf/vf.c | 29 +++++++-
> drivers/net/ethernet/intel/ixgbevf/vf.h | 1 +
> 7 files changed, 137 insertions(+), 4 deletions(-)
Hiroshi, I tried to apply your patches to my queue but they do not apply
cleanly and they are in a DOS file format, not UNIX. I also noted
several checkpatch.pl issues with your patches, so please fix those up
as well.
Can you please fix up your patches based on my tree:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/queue.git
This my queue of all community patches against the Intel LAN drivers and
will be where I queue up your patches while they are under review and
testing.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* pull-request: can-next 2015-02-04
From: Marc Kleine-Budde @ 2015-02-04 13:09 UTC (permalink / raw)
To: netdev; +Cc: David Miller, kernel@pengutronix.de, linux-can@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]
Hello David,
this is a pull request of 2 patches for net-next/master.
Nicholas Mc Guire contributes a patch for the janz-ican3 driver to fix
a mismatch in an assignment. Ahmed S. Darwish contributes a patch for
the kvaser_usb driver, to make the driver more robust during the
bus-off handling.
Marc
---
The following changes since commit 7e8acbb69ee2b855288afc61e3794a30e3582977:
Merge branch 'netlabel-next' (2015-02-03 16:22:20 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git tags/linux-can-next-for-3.20-20150204
for you to fetch changes up to a9ca6e13d66042b3ac18d1352b88b7cd0da8fc21:
can: kvaser_usb: Ignore spurious error events after a busoff (2015-02-04 14:07:03 +0100)
----------------------------------------------------------------
linux-can-next-for-3.20-20150204
----------------------------------------------------------------
Ahmed S. Darwish (1):
can: kvaser_usb: Ignore spurious error events after a busoff
Nicholas Mc Guire (1):
can: janz-ican3: fix type mismatch in assignment
drivers/net/can/janz-ican3.c | 6 ++----
drivers/net/can/usb/kvaser_usb.c | 19 ++++++++++---------
2 files changed, 12 insertions(+), 13 deletions(-)
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] qlogic: Deletion of unnecessary checks before two function calls
From: SF Markus Elfring @ 2015-02-04 13:13 UTC (permalink / raw)
To: Shahed Shaikh, Dept-GELinuxNICDev, netdev
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <5317A59D.4@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 4 Feb 2015 14:07:56 +0100
The functions kfree() and vfree() perform also input parameter validation.
Thus the test around their calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 24 ++++++++--------------
.../net/ethernet/qlogic/qlcnic/qlcnic_minidump.c | 3 +--
2 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
index 2528c3f..a430a34a 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
@@ -294,9 +294,7 @@ int qlcnic_alloc_sds_rings(struct qlcnic_recv_context *recv_ctx, int count)
void qlcnic_free_sds_rings(struct qlcnic_recv_context *recv_ctx)
{
- if (recv_ctx->sds_rings != NULL)
- kfree(recv_ctx->sds_rings);
-
+ kfree(recv_ctx->sds_rings);
recv_ctx->sds_rings = NULL;
}
@@ -1257,8 +1255,7 @@ qlcnic_check_options(struct qlcnic_adapter *adapter)
if (ahw->op_mode != QLCNIC_NON_PRIV_FUNC) {
if (fw_dump->tmpl_hdr == NULL ||
adapter->fw_version > prev_fw_version) {
- if (fw_dump->tmpl_hdr)
- vfree(fw_dump->tmpl_hdr);
+ vfree(fw_dump->tmpl_hdr);
if (!qlcnic_fw_cmd_get_minidump_temp(adapter))
dev_info(&pdev->dev,
"Supports FW dump capability\n");
@@ -2374,13 +2371,12 @@ void qlcnic_free_tx_rings(struct qlcnic_adapter *adapter)
for (ring = 0; ring < adapter->drv_tx_rings; ring++) {
tx_ring = &adapter->tx_ring[ring];
- if (tx_ring && tx_ring->cmd_buf_arr != NULL) {
+ if (tx_ring) {
vfree(tx_ring->cmd_buf_arr);
tx_ring->cmd_buf_arr = NULL;
}
}
- if (adapter->tx_ring != NULL)
- kfree(adapter->tx_ring);
+ kfree(adapter->tx_ring);
}
int qlcnic_alloc_tx_rings(struct qlcnic_adapter *adapter,
@@ -2758,13 +2754,9 @@ static void qlcnic_remove(struct pci_dev *pdev)
}
qlcnic_dcb_free(adapter->dcb);
-
qlcnic_detach(adapter);
-
- if (adapter->npars != NULL)
- kfree(adapter->npars);
- if (adapter->eswitch != NULL)
- kfree(adapter->eswitch);
+ kfree(adapter->npars);
+ kfree(adapter->eswitch);
if (qlcnic_82xx_check(adapter))
qlcnic_clr_all_drv_state(adapter, 0);
@@ -2932,13 +2924,13 @@ void qlcnic_alloc_lb_filters_mem(struct qlcnic_adapter *adapter)
static void qlcnic_free_lb_filters_mem(struct qlcnic_adapter *adapter)
{
- if (adapter->fhash.fmax && adapter->fhash.fhead)
+ if (adapter->fhash.fmax)
kfree(adapter->fhash.fhead);
adapter->fhash.fhead = NULL;
adapter->fhash.fmax = 0;
- if (adapter->rx_fhash.fmax && adapter->rx_fhash.fhead)
+ if (adapter->rx_fhash.fmax)
kfree(adapter->rx_fhash.fhead);
adapter->rx_fhash.fmax = 0;
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_minidump.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_minidump.c
index c9f57fb..332bb8a 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_minidump.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_minidump.c
@@ -1407,8 +1407,7 @@ void qlcnic_83xx_get_minidump_template(struct qlcnic_adapter *adapter)
current_version = qlcnic_83xx_get_fw_version(adapter);
if (fw_dump->tmpl_hdr == NULL || current_version > prev_version) {
- if (fw_dump->tmpl_hdr)
- vfree(fw_dump->tmpl_hdr);
+ vfree(fw_dump->tmpl_hdr);
if (!qlcnic_fw_cmd_get_minidump_temp(adapter))
dev_info(&pdev->dev, "Supports FW dump capability\n");
}
--
2.2.2
^ permalink raw reply related
* Re: Throughput regression with `tcp: refine TSO autosizing`
From: Eric Dumazet @ 2015-02-04 13:16 UTC (permalink / raw)
To: Michal Kazior, Neal Cardwell; +Cc: linux-wireless, Network Development, eyalpe
In-Reply-To: <CA+BoTQ=qmCZz4CmSOvCOzMLowrDEG12XBffkTcYxjGqVD9604g@mail.gmail.com>
OK guys
Using a mlx4 testbed I can reproduce the problem by pushing coalescing
settings and disabling SG (thus disabling GSO)
ethtool -K eth0 sg off
Actual changes:
scatter-gather: off
tx-scatter-gather: off
generic-segmentation-offload: off [requested on]
ethtool -C eth0 tx-usecs 1024 tx-frames 64
Meaning that NIC waits one ms before sending the TX IRQ,
and can accumulate 64 frames before forcing the interrupt.
We probably have a bug in cwnd expansion logic :
lpaa23:~# DUMP_TCP_INFO=1 ./netperf -H 10.246.7.152 -Cc
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.246.7.152 () port 0 AF_INET
rto=201000 ato=0 pmtu=1500 rcv_ssthresh=29200 rtt=230 rttvar=30 snd_ssthresh=41 cwnd=59 reordering=3 total_retrans=1 ca_state=0 pacing_rate=5943.1 Mbits
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 16384 16384 10.00 530.39 0.40 0.32 2.965 2.398
-> final cwnd=59 which is not enough to avoid the 1ms delay between each
burst.
So sender sends ~60 packets, then has to wait 1ms (to get NIC TX IRQ)
before sending the following burst.
I am CCing Neal, he probably can help to root cause the problem.
Thanks
^ permalink raw reply
* Re: [PATCH] net: core/dev: fix sparse warning
From: Eric Dumazet @ 2015-02-04 13:21 UTC (permalink / raw)
To: Lad, Prabhakar; +Cc: David S. Miller, netdev, LKML, Eric Dumazet
In-Reply-To: <CA+V-a8vSfY79pqOoSr=F-Am8g4jmhM_DfC2f-SNaiNt9qu7hEA@mail.gmail.com>
On Wed, 2015-02-04 at 12:50 +0000, Lad, Prabhakar wrote:
> I tried it on gcc 4.3.3 and sparse with 0.4.5-rc1 version.
gcc-4.3.3 is 6 years old...
^ permalink raw reply
* [RFC] NAPI behavior when (work < weight)
From: Vladimir Kondratiev @ 2015-02-04 13:22 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Herbert Xu, Eric Dumazet, Tom Herbert,
Vlad Yasevich, Jiri Pirko, John Fastabend, Joe Perches
Hi
I am observing that if driver does not calls napi_complete() when
less than full budget consumed, various strange things happen.
For example, if driver going to napi_disable(), it may wait forever
in the loop:
while (test_and_set_bit(NAPI_STATE_SCHED, &n->state))
msleep(1);
if last NAPI consumed less then full budget, because bit
NAPI_STATE_SCHED never cleared.
Is it expected that driver calls napi_complete() when less than full
budget consumed? Documentation does not say so.
What is intended behavior in case above?
Thanks, Vladimir
^ permalink raw reply
* Re: Throughput regression with `tcp: refine TSO autosizing`
From: Eric Dumazet @ 2015-02-04 13:29 UTC (permalink / raw)
To: Michal Kazior; +Cc: Neal Cardwell, linux-wireless, Network Development, eyalpe
In-Reply-To: <1423055810.907.125.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, 2015-02-04 at 05:16 -0800, Eric Dumazet wrote:
> OK guys
>
> Using a mlx4 testbed I can reproduce the problem by pushing coalescing
> settings and disabling SG (thus disabling GSO)
>
> ethtool -K eth0 sg off
> Actual changes:
> scatter-gather: off
> tx-scatter-gather: off
> generic-segmentation-offload: off [requested on]
>
> ethtool -C eth0 tx-usecs 1024 tx-frames 64
>
> Meaning that NIC waits one ms before sending the TX IRQ,
> and can accumulate 64 frames before forcing the interrupt.
>
> We probably have a bug in cwnd expansion logic :
>
> lpaa23:~# DUMP_TCP_INFO=1 ./netperf -H 10.246.7.152 -Cc
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.246.7.152 () port 0 AF_INET
> rto=201000 ato=0 pmtu=1500 rcv_ssthresh=29200 rtt=230 rttvar=30 snd_ssthresh=41 cwnd=59 reordering=3 total_retrans=1 ca_state=0 pacing_rate=5943.1 Mbits
> Recv Send Send Utilization Service Demand
> Socket Socket Message Elapsed Send Recv Send Recv
> Size Size Size Time Throughput local remote local remote
> bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
>
> 87380 16384 16384 10.00 530.39 0.40 0.32 2.965 2.398
>
>
> -> final cwnd=59 which is not enough to avoid the 1ms delay between each
> burst.
>
> So sender sends ~60 packets, then has to wait 1ms (to get NIC TX IRQ)
> before sending the following burst.
>
> I am CCing Neal, he probably can help to root cause the problem.
Arg, this was with net-next, ie not including our recent stretch ack
fixes.
Using David Miller 'net' tree, cwnd seems OK.
Speed is low because of 64 queued frames are exceeding
tcp_limit_output_bytes
lpaa23:~# cat /proc/sys/net/ipv4/tcp_limit_output_bytes
131072
lpaa23:~# DUMP_TCP_INFO=1 ./netperf -H 10.246.7.152 -Cc
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.246.7.152 () port 0 AF_INET
rto=201000 ato=0 pmtu=1500 rcv_ssthresh=29200 rtt=166 rttvar=16 snd_ssthresh=26 cwnd=59 reordering=3 total_retrans=0 ca_state=0 pacing_rate=8203.52 Mbits
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 16384 16384 10.00 569.96 0.52 0.38 3.588 2.625
lpaa23:~# echo 262144 >/proc/sys/net/ipv4/tcp_limit_output_bytes
lpaa23:~# DUMP_TCP_INFO=1 ./netperf -H 10.246.7.152 -Cc
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.246.7.152 () port 0 AF_INET
rto=201000 ato=0 pmtu=1500 rcv_ssthresh=29200 rtt=98 rttvar=18 snd_ssthresh=312 cwnd=313 reordering=3 total_retrans=23 ca_state=0
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 16384 16384 10.00 8518.40 2.60 1.57 1.200 0.727
^ permalink raw reply
* MTU problems with GRE and IPv6
From: Steve Hill @ 2015-02-04 12:31 UTC (permalink / raw)
To: netdev
I'm having some problems related to oversized IPv6 packets on a GRE
tunnel under Scientific Linux 6.6 (Kernel 2.6.32-504.3.3.el6.x86_64).
I have a set of machines set up as follows:
Client
|
Router
|
(Internet)
|
Physical KVM Host
|
Server (KVM virtual machine)
All of these machines have both IPv4 and IPv6 connectivity.
The Client<->Router connection is ethernet with a 1500 octet MTU and the
virtual NIC between the KVM host and the server also has a 1500 octet MTU.
There is a GRE-over-IPv4 tunnel between Router and Server with an MTU of
1476. On Server, normally traffic is routed via the virtual NIC, but
iptables/ip6tables sets a CONNMARK on any traffic arriving over the GRE
tunnel and that mark is used to select a different routing table for the
reply traffic so that it goes back over the GRE tunnel.
From Client, I connect to port 80 on Server (which is running Apache)
using IPv4 over the GRE tunnel and request a large object. tcpdump
shows a TCP packet larger than the GRE tunnel's MTU being sent over GRE,
and with the GRE header this exceeds the virtual NIC's MTU too. The KVM
host drops the oversized GRE packet and replies with a ICMP "need to
frag". The TCP packet is resized and retransmitted and this gets
through, everything works:
ethertype IPv4, length 1530: Server_ipv4 > Router_ipv4: GREv0, proto
IPv4, length 1496: Server_ipv4.http > Client_ipv4.44247: Flags [.], seq
1:1441, ack 51, win 114, options [nop,nop,TS val 607339847 ecr
30576811], length 1440
ethertype IPv4, length 590: KVM_ipv4 > Server_ipv4: ICMP Router_ipv4
unreachable - need to frag (mtu 1500), length 556
ethertype IPv4, length 1506: Server_ipv4 > Router_ipv4: GREv0, proto
IPv4, length 1472: Server_ipv4.http > Client_ipv4.44247: Flags [.], seq
1:1417, ack 51, win 114, options [nop,nop,TS val 607339867 ecr
30577336], length 1416
But doing the same test using IPv6 over the GRE tunnel fails. tcpdump
shows an oversized TCP packet again, and again that gets passed on to
the KVM host as an oversized GRE packet, which gets dropped and an ICMP
"need to frag" returned. However, the TCP packet is never resized and
retransmitted, so the TCP session hangs:
ethertype IPv4, length 1530: Server_ipv4 > Router_ipv4: GREv0, proto
IPv6, length 1496: Server_ipv6.http > Client_ipv6.35711: Flags [.], seq
1:1421, ack 51, win 112, options [nop,nop,TS val 607991929 ecr
31228911], length 1420
ethertype IPv4, length 590: KVM_ipv4 > Server_ipv4: ICMP Router_ipv4
unreachable - need to frag (mtu 1500), length 556
So, it seems to me that initially the TCP packets are sized according to
the virtual NIC's MTU, since that is where the default routing table
says it will go. After being generated, the packets are then sent to
the GRE tunnel instead, which has a lower MTU. My expectation is that:
1. An IPv4 packet that exceeds the GRE tunnel's MTU should be dropped by
the GRE tunnel itself and an ICMP "need to frag" should be sent back to
the TCP stack, which should retransmit a smaller packet.
2. The same should be true for IPv6 - an IPv6 packet that exceeds the
GRE tunnel's MTU should be dropped by the GRE tunnel itself and an
ICMPv6 "packet too big" should be sent up to the TCP stack, which should
retransmit a smaller packet.
3. If a GRE packet causes an upstream router to return a "need to frag",
the GRE tunnel's MTU should be reduced accordingly and (1) or (2) should
happen.
As far as I can see, (1) and (2) aren't happening - oversized GRE
packets containing oversized IP packets are ending up at the KVM host.
(3) only seems to be working for IPv4 - the IPv6 stack never retransmits
a resized TCP packet.
Is this a bug, or am I missing something about how it should work?
Many thanks.
--
- Steve Hill
Technical Director
Opendium Limited http://www.opendium.com
Direct contacts:
Instant messager: xmpp:steve@opendium.com
Email: steve@opendium.com
Phone: sip:steve@opendium.com
Sales / enquiries contacts:
Email: sales@opendium.com
Phone: +44-1792-824568 / sip:sales@opendium.com
Support contacts:
Email: support@opendium.com
Phone: +44-1792-825748 / sip:support@opendium.com
^ permalink raw reply
* Re: [RFC] NAPI behavior when (work < weight)
From: Eric Dumazet @ 2015-02-04 13:37 UTC (permalink / raw)
To: Vladimir Kondratiev
Cc: netdev, David S. Miller, Herbert Xu, Eric Dumazet, Tom Herbert,
Vlad Yasevich, Jiri Pirko, John Fastabend, Joe Perches
In-Reply-To: <2015045.8auvsRvBkK@lx-wigig-72>
On Wed, 2015-02-04 at 15:22 +0200, Vladimir Kondratiev wrote:
> Hi
>
> I am observing that if driver does not calls napi_complete() when
> less than full budget consumed, various strange things happen.
>
> For example, if driver going to napi_disable(), it may wait forever
> in the loop:
>
> while (test_and_set_bit(NAPI_STATE_SCHED, &n->state))
> msleep(1);
>
> if last NAPI consumed less then full budget, because bit
> NAPI_STATE_SCHED never cleared.
>
> Is it expected that driver calls napi_complete() when less than full
> budget consumed? Documentation does not say so.
>
> What is intended behavior in case above?
A driver must call napi_complete() (or better : napi_complete_done() )
when/if returning work_done < budget
Thats because of the way we have to rearm interrupts in the driver,
_after_ calling napi_complete()
^ permalink raw reply
* [PATCH] tun: Use static attribute groups for sysfs entries
From: Takashi Iwai @ 2015-02-04 13:37 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
Instead of manual calls of device_create_file() and
device_remove_files(), assign the static attribute groups to netdev
groups array. This simplifies the code and avoids the possible
races.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/net/tun.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 8c8dc16839a7..662516ed6104 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1566,6 +1566,17 @@ static DEVICE_ATTR(tun_flags, 0444, tun_show_flags, NULL);
static DEVICE_ATTR(owner, 0444, tun_show_owner, NULL);
static DEVICE_ATTR(group, 0444, tun_show_group, NULL);
+static struct attribute *tun_dev_attrs[] = {
+ &dev_attr_tun_flags.attr,
+ &dev_attr_owner.attr,
+ &dev_attr_group.attr,
+ NULL
+};
+
+static const struct attribute_group tun_attr_group = {
+ .attrs = tun_dev_attrs
+};
+
static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
{
struct tun_struct *tun;
@@ -1646,6 +1657,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
dev_net_set(dev, net);
dev->rtnl_link_ops = &tun_link_ops;
dev->ifindex = tfile->ifindex;
+ dev->sysfs_groups[0] = &tun_attr_group;
tun = netdev_priv(dev);
tun->dev = dev;
@@ -1681,11 +1693,6 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
err = register_netdevice(tun->dev);
if (err < 0)
goto err_detach;
-
- if (device_create_file(&tun->dev->dev, &dev_attr_tun_flags) ||
- device_create_file(&tun->dev->dev, &dev_attr_owner) ||
- device_create_file(&tun->dev->dev, &dev_attr_group))
- pr_err("Failed to create tun sysfs files\n");
}
netif_carrier_on(tun->dev);
--
2.2.2
^ permalink raw reply related
* [PATCH] xen-netfront: Use static attribute groups for sysfs entries
From: Takashi Iwai @ 2015-02-04 13:38 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: Boris Ostrovsky, David Vrabel, xen-devel, netdev
Instead of manual calls of device_create_file() and
device_remove_files(), assign the static attribute groups to netdev
groups array. This simplifies the code and avoids the possible
races.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/net/xen-netfront.c | 62 ++++++++++++----------------------------------
1 file changed, 16 insertions(+), 46 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index d8c10764f130..1524d2ee1c21 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -223,11 +223,7 @@ static grant_ref_t xennet_get_rx_ref(struct netfront_queue *queue,
}
#ifdef CONFIG_SYSFS
-static int xennet_sysfs_addif(struct net_device *netdev);
-static void xennet_sysfs_delif(struct net_device *netdev);
-#else /* !CONFIG_SYSFS */
-#define xennet_sysfs_addif(dev) (0)
-#define xennet_sysfs_delif(dev) do { } while (0)
+static const struct attribute_group xennet_dev_group;
#endif
static bool xennet_can_sg(struct net_device *dev)
@@ -1367,20 +1363,15 @@ static int netfront_probe(struct xenbus_device *dev,
info = netdev_priv(netdev);
dev_set_drvdata(&dev->dev, info);
-
+#ifdef CONFIG_SYSFS
+ info->netdev->sysfs_groups[0] = &xennet_dev_group;
+#endif
err = register_netdev(info->netdev);
if (err) {
pr_warn("%s: register_netdev err=%d\n", __func__, err);
goto fail;
}
- err = xennet_sysfs_addif(info->netdev);
- if (err) {
- unregister_netdev(info->netdev);
- pr_warn("%s: add sysfs failed err=%d\n", __func__, err);
- goto fail;
- }
-
return 0;
fail:
@@ -2144,39 +2135,20 @@ static ssize_t store_rxbuf(struct device *dev,
return len;
}
-static struct device_attribute xennet_attrs[] = {
- __ATTR(rxbuf_min, S_IRUGO|S_IWUSR, show_rxbuf, store_rxbuf),
- __ATTR(rxbuf_max, S_IRUGO|S_IWUSR, show_rxbuf, store_rxbuf),
- __ATTR(rxbuf_cur, S_IRUGO, show_rxbuf, NULL),
-};
+static DEVICE_ATTR(rxbuf_min, S_IRUGO|S_IWUSR, show_rxbuf, store_rxbuf);
+static DEVICE_ATTR(rxbuf_max, S_IRUGO|S_IWUSR, show_rxbuf, store_rxbuf);
+static DEVICE_ATTR(rxbuf_cur, S_IRUGO, show_rxbuf, NULL);
-static int xennet_sysfs_addif(struct net_device *netdev)
-{
- int i;
- int err;
-
- for (i = 0; i < ARRAY_SIZE(xennet_attrs); i++) {
- err = device_create_file(&netdev->dev,
- &xennet_attrs[i]);
- if (err)
- goto fail;
- }
- return 0;
-
- fail:
- while (--i >= 0)
- device_remove_file(&netdev->dev, &xennet_attrs[i]);
- return err;
-}
-
-static void xennet_sysfs_delif(struct net_device *netdev)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(xennet_attrs); i++)
- device_remove_file(&netdev->dev, &xennet_attrs[i]);
-}
+static struct attribute *xennet_dev_attrs[] = {
+ &dev_attr_rxbuf_min.attr,
+ &dev_attr_rxbuf_max.attr,
+ &dev_attr_rxbuf_cur.attr,
+ NULL
+};
+static const struct attribute_group xennet_dev_group = {
+ .attrs = xennet_dev_attrs
+};
#endif /* CONFIG_SYSFS */
static int xennet_remove(struct xenbus_device *dev)
@@ -2190,8 +2162,6 @@ static int xennet_remove(struct xenbus_device *dev)
xennet_disconnect_backend(info);
- xennet_sysfs_delif(info->netdev);
-
unregister_netdev(info->netdev);
for (i = 0; i < num_queues; ++i) {
--
2.2.2
^ permalink raw reply related
* [PATCH] hso: Use static attribute groups for sysfs entry
From: Takashi Iwai @ 2015-02-04 13:39 UTC (permalink / raw)
To: Jan Dumon; +Cc: linux-usb, netdev
Pass the static attribute groups and the driver data via
tty_port_register_device_attr() instead of manual device_create_file()
and device_remove_file() calls.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/net/usb/hso.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 9c5aa922a9f4..1ecca185510d 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -533,6 +533,13 @@ static ssize_t hso_sysfs_show_porttype(struct device *dev,
}
static DEVICE_ATTR(hsotype, S_IRUGO, hso_sysfs_show_porttype, NULL);
+static struct attribute *hso_serial_dev_attrs[] = {
+ &dev_attr_hsotype.attr,
+ NULL
+};
+
+ATTRIBUTE_GROUPS(hso_serial_dev);
+
static int hso_urb_to_index(struct hso_serial *serial, struct urb *urb)
{
int idx;
@@ -2232,9 +2239,6 @@ static void hso_serial_common_free(struct hso_serial *serial)
{
int i;
- if (serial->parent->dev)
- device_remove_file(serial->parent->dev, &dev_attr_hsotype);
-
tty_unregister_device(tty_drv, serial->minor);
for (i = 0; i < serial->num_rx_urbs; i++) {
@@ -2264,11 +2268,10 @@ static int hso_serial_common_create(struct hso_serial *serial, int num_urbs,
goto exit;
/* register our minor number */
- serial->parent->dev = tty_port_register_device(&serial->port, tty_drv,
- minor, &serial->parent->interface->dev);
+ serial->parent->dev = tty_port_register_device_attr(&serial->port,
+ tty_drv, minor, &serial->parent->interface->dev,
+ serial->parent, hso_serial_dev_groups);
dev = serial->parent->dev;
- dev_set_drvdata(dev, serial->parent);
- i = device_create_file(dev, &dev_attr_hsotype);
/* fill in specific data for later use */
serial->minor = minor;
--
2.2.2
^ permalink raw reply related
* Re: hyper-v: allow access to vmbus from userspace driver
From: Thomas Monjalon @ 2015-02-04 13:42 UTC (permalink / raw)
To: stephen hemminger; +Cc: K. Y. Srinivasan, Haiyang Zhang, devel, netdev, dev
In-Reply-To: <20150203110345.15c38345@urahara>
Hi Stephen,
2015-02-03 11:03, stephen hemminger:
> Brocade is submitting a hyper-v driver for DPDK <dev@dpdk.org>
> but this driver needs a hook in the hyper-v bus layer
> to allow the additional hv_uio driver to access the shared vmbus
> pages. The hv_uio driver lives in DPDK (like igb_uio) and provides
> userspace access to raw network packets.
>
> Signed-off-by: Stas Egorov <segorov@mirantis.com>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The hyper-v driver for DPDK has not been sent yet to
http://dpdk.org/dev/patchwork
but it would be interesting to better explain this uio mapping.
Thanks
--
Thomas
> --- a/drivers/hv/connection.c 2015-02-03 10:58:51.751752450 -0800
> +++ b/drivers/hv/connection.c 2015-02-03 10:58:51.751752450 -0800
> @@ -64,6 +64,21 @@ static __u32 vmbus_get_next_version(__u3
> }
> }
>
> +static const uuid_le HV_NET_GUID = {
> + .b = {
> + 0x63, 0x51, 0x61, 0xf8, 0x3e, 0xdf, 0xc5, 0x46,
> + 0x91, 0x3f, 0xf2, 0xd2, 0xf9, 0x65, 0xed, 0x0e
> + }
> +};
> +
> +void vmbus_get_pages(unsigned long *int_page, unsigned long monitor_pages[2])
> +{
> + *int_page = (unsigned long)vmbus_connection.int_page;
> + monitor_pages[0] = (unsigned long)vmbus_connection.monitor_pages[0];
> + monitor_pages[1] = (unsigned long)vmbus_connection.monitor_pages[1];
> +}
> +EXPORT_SYMBOL_GPL(vmbus_get_pages);
> +
> static int vmbus_negotiate_version(struct vmbus_channel_msginfo *msginfo,
> __u32 version)
> {
> @@ -347,7 +362,8 @@ static void process_chn_event(u32 relid)
> else
> bytes_to_read = 0;
> } while (read_state && (bytes_to_read != 0));
> - } else {
> + } else if (!memcmp(&channel->device_obj->dev_type, &HV_NET_GUID,
> + sizeof(uuid_le))) {
> pr_err("no channel callback for relid - %u\n", relid);
> }
>
> --- a/include/linux/hyperv.h 2015-02-03 10:58:51.751752450 -0800
> +++ b/include/linux/hyperv.h 2015-02-03 10:58:51.751752450 -0800
> @@ -868,6 +868,9 @@ extern int vmbus_recvpacket_raw(struct v
>
> extern void vmbus_ontimer(unsigned long data);
>
> +extern void vmbus_get_pages(unsigned long *int_page,
> + unsigned long monitor_pages[2]);
> +
> /* Base driver object */
> struct hv_driver {
> const char *name;
^ permalink raw reply
* Re: [Xen-devel] [PATCH] xen-netfront: Use static attribute groups for sysfs entries
From: David Vrabel @ 2015-02-04 13:53 UTC (permalink / raw)
To: Takashi Iwai, Konrad Rzeszutek Wilk
Cc: xen-devel, Boris Ostrovsky, David Vrabel, netdev
In-Reply-To: <1423057135-6939-1-git-send-email-tiwai@suse.de>
On 04/02/15 13:38, Takashi Iwai wrote:
> Instead of manual calls of device_create_file() and
> device_remove_files(), assign the static attribute groups to netdev
> groups array. This simplifies the code and avoids the possible
> races.
Acked-by: David Vrabel <david.vrabel@citrix.com>
David
^ permalink raw reply
* [PATCH] net: Mellanox: Delete unnecessary checks before the function call "vunmap"
From: SF Markus Elfring @ 2015-02-04 14:22 UTC (permalink / raw)
To: Eli Cohen, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall
In-Reply-To: <5317A59D.4-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Date: Wed, 4 Feb 2015 15:17:00 +0100
The vunmap() function performs also input parameter validation.
Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
---
drivers/net/ethernet/mellanox/mlx4/alloc.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/alloc.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/alloc.c b/drivers/net/ethernet/mellanox/mlx4/alloc.c
index 963dd7e..06faa51 100644
--- a/drivers/net/ethernet/mellanox/mlx4/alloc.c
+++ b/drivers/net/ethernet/mellanox/mlx4/alloc.c
@@ -660,7 +660,7 @@ void mlx4_buf_free(struct mlx4_dev *dev, int size, struct mlx4_buf *buf)
dma_free_coherent(&dev->pdev->dev, size, buf->direct.buf,
buf->direct.map);
else {
- if (BITS_PER_LONG == 64 && buf->direct.buf)
+ if (BITS_PER_LONG == 64)
vunmap(buf->direct.buf);
for (i = 0; i < buf->nbufs; ++i)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/alloc.c b/drivers/net/ethernet/mellanox/mlx5/core/alloc.c
index 56779c1..201ca6d 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/alloc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/alloc.c
@@ -121,7 +121,7 @@ void mlx5_buf_free(struct mlx5_core_dev *dev, struct mlx5_buf *buf)
dma_free_coherent(&dev->pdev->dev, buf->size, buf->direct.buf,
buf->direct.map);
else {
- if (BITS_PER_LONG == 64 && buf->direct.buf)
+ if (BITS_PER_LONG == 64)
vunmap(buf->direct.buf);
for (i = 0; i < buf->nbufs; i++)
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 related
* [PATCH net] ip6_gre: fix endianness errors in ip6gre_err
From: Sabrina Dubroca @ 2015-02-04 14:25 UTC (permalink / raw)
To: davem; +Cc: netdev, Sabrina Dubroca
info is in network byte order, change it back to host byte order
before use. In particular, the current code sets the MTU of the tunnel
to a wrong (too big) value.
Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
---
net/ipv6/ip6_gre.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 13cda4c6313b..01ccc28a686f 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -417,7 +417,7 @@ static void ip6gre_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
if (code == ICMPV6_HDR_FIELD)
teli = ip6_tnl_parse_tlv_enc_lim(skb, skb->data);
- if (teli && teli == info - 2) {
+ if (teli && teli == be32_to_cpu(info) - 2) {
tel = (struct ipv6_tlv_tnl_enc_lim *) &skb->data[teli];
if (tel->encap_limit == 0) {
net_warn_ratelimited("%s: Too small encapsulation limit or routing loop in tunnel!\n",
@@ -429,7 +429,7 @@ static void ip6gre_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
}
break;
case ICMPV6_PKT_TOOBIG:
- mtu = info - offset;
+ mtu = be32_to_cpu(info) - offset;
if (mtu < IPV6_MIN_MTU)
mtu = IPV6_MIN_MTU;
t->dev->mtu = mtu;
--
2.2.2
^ permalink raw reply related
* [PATCH net-next] xfrm6: Fix a offset value for network header in _decode_session6
From: Hajime Tazaki @ 2015-02-04 14:31 UTC (permalink / raw)
To: netdev; +Cc: steffen.klassert, herbert
When a network-layer header has multiple IPv6 extension headers, then offset
for mobility header goes wrong. This regression breaks an xfrm policy lookup
for a particular receive packet. Binding update packets of Mobile IPv6
are all discarded without this fix.
Fixes: de3b7a06dfe1 ("xfrm6: Fix transport header offset in _decode_session6.")
Signed-off-by: Hajime Tazaki <tazaki@sfc.wide.ad.jp>
---
net/ipv6/xfrm6_policy.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
index 48bf5a0..8d2d01b 100644
--- a/net/ipv6/xfrm6_policy.c
+++ b/net/ipv6/xfrm6_policy.c
@@ -200,6 +200,7 @@ _decode_session6(struct sk_buff *skb, struct flowi *fl, int reverse)
#if IS_ENABLED(CONFIG_IPV6_MIP6)
case IPPROTO_MH:
+ offset += ipv6_optlen(exthdr);
if (!onlyproto && pskb_may_pull(skb, nh + offset + 3 - skb->data)) {
struct ip6_mh *mh;
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] net: Mellanox: Delete unnecessary checks before the function call "vunmap"
From: Eli Cohen @ 2015-02-04 14:59 UTC (permalink / raw)
To: SF Markus Elfring; +Cc: netdev, linux-rdma, LKML, kernel-janitors, Julia Lawall
In-Reply-To: <54D22B29.3020200@users.sourceforge.net>
Acked-by: Eli Cohen <eli@mellanox.com>
On Wed, Feb 04, 2015 at 03:22:33PM +0100, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Wed, 4 Feb 2015 15:17:00 +0100
>
> The vunmap() function performs also input parameter validation.
> Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
^ 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