* Re: bnx2x + SR-IOV, no internal L2 switching
From: Ben Hutchings @ 2014-02-12 23:10 UTC (permalink / raw)
To: yoann.juet; +Cc: netdev, Ariel Elior
In-Reply-To: <52FB7843.6050601@univ-nantes.fr>
[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]
On Wed, 2014-02-12 at 14:33 +0100, Yoann Juet wrote:
> Hi all,
>
> I'm conducting experiments on SR-IOV with Broadcom and Intel cards on
> debian/unstable with KVM hypervisor. On Broadcom cards (bnx2x module,
> BCM57810 devices), Virtual Functions (VFs) get running, Virtual Machines
> attached to such VFs inherit network connectivity with excellent
> performance.
>
> However, VMs attached to VFs on the Broadcom Physical Functions (PFs)
> behave like they were connected to an ancient hub, not a L2 switch. It
> is as if there was no internal L2 switching on the Broadcom card to
> process VF <-> VF or VF <-> PF communications. As a result, a VM sees
> all inbound/outbound traffic from/to others VMs as well as traffic
> destined to the PF (for instance, the physical ethX has an IP address).
Are you're using the ISC DHCP client, which puts the interface in
promiscuous mode? If the Broadcom NIC supports promiscuous mode on VFs,
that may explain what you're seeing.
> On the other hand, everything works like a charm with Intel cards (ixgbe
> module, 82599EB devices). Traffic between VFs or VF/PF is switched
> internally by the card.
I think these VFs don't support promiscuous mode. Anyway, the ixgbevf
driver silently ignores it.
Ben.
> I found very little literature about SR-IOV on Broadcom devices. I
> wonder if it's a normal behaviour, a misconfiguration on my side or
> perhaps a firmware/driver bug.
>
> Have you seen this issue before ?
>
> ---
> Kernel 3.12.9 (same behaviour with kernels 3.10.x)
> driver: bnx2x
> firmware-version: 7.8.17
> Debian/unstable
> libvirt 1.2.1
> QEMU 1.7.0
> ---
>
> Best regards,
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* [PATCH] staging: rtl8821ae: Fix potential infinite loop
From: Larry Finger @ 2014-02-12 23:10 UTC (permalink / raw)
To: gregkh; +Cc: netdev, devel, Larry Finger
Smatch reports the following:
drivers/staging/rtl8821ae/rtl8821ae/hw.c:153 _rtl8821ae_set_fw_clock_on() info: ignoring unreachable code.
Upon investigation, the code in this region has the capability of creating
an infinite loop.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/staging/rtl8821ae/rtl8821ae/hw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hw.c b/drivers/staging/rtl8821ae/rtl8821ae/hw.c
index 5ed7a11..e8344be 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hw.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hw.c
@@ -147,6 +147,7 @@ static void _rtl8821ae_set_fw_clock_on(struct ieee80211_hw *hw,
} else {
rtlhal->bfw_clk_change_in_progress = false;
spin_unlock_bh(&rtlpriv->locks.fw_ps_lock);
+ break;
}
}
--
1.8.4.5
^ permalink raw reply related
* Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
From: Ben Hutchings @ 2014-02-12 22:52 UTC (permalink / raw)
To: Eric Dumazet
Cc: Sander Eikelenboom, Dan Williams, Konrad Rzeszutek Wilk, Wei Liu,
Francois Romieu, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1392154132.6615.91.camel@edumazet-glaptop2.roam.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]
On Tue, 2014-02-11 at 13:28 -0800, Eric Dumazet wrote:
[...]
> Incoming frames might be taken out of order-3 pages.
>
> With regular Ethernet frames, this is 21 frames per order-3 pages.
>
> ACTIVE_PFN_MAX_OVERLAP seems too small.
>
> Alternative would be to user order-0 only pages if CONFIG_DMA_API_DEBUG
> is set. Not sure if it works if PAGE_SIZE=66536 ....
Indeed, you can get a lot of packet buffers into a 64K page...
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index f589c9af8cbf..1b9995adfd29 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -1924,7 +1924,11 @@ static inline void __skb_queue_purge(struct sk_buff_head *list)
> kfree_skb(skb);
> }
>
> +#if defined(CONFIG_DMA_API_DEBUG)
> +#define NETDEV_FRAG_PAGE_MAX_ORDER 0
> +#else
> #define NETDEV_FRAG_PAGE_MAX_ORDER get_order(32768)
> +#endif
> #define NETDEV_FRAG_PAGE_MAX_SIZE (PAGE_SIZE << NETDEV_FRAG_PAGE_MAX_ORDER)
> #define NETDEV_PAGECNT_MAX_BIAS NETDEV_FRAG_PAGE_MAX_SIZE
>
That may be useful for debugging this particular problem, but please
don't make debugging options change behaviour like this.
Ben.
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: NETIF_F_HIGHDMA?
From: David Miller @ 2014-02-12 22:51 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev
In-Reply-To: <52FBFD03.6000703@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Thu, 13 Feb 2014 02:00:19 +0300
> Hello.
>
> I fail to understand why this flag is needed at
> all. netdev-features.txt says:
>
> * Transmit DMA from high memory
>
> On platforms where this is relevant, NETIF_F_HIGHDMA signals that
> ndo_start_xmit can handle skbs with frags in high memory.
Back when this flag was created we had pretty much no infrastructure
to deal with DMA masks, and furthermore it was not universal that
code accessed high memory pages correctly.
So this was the hack we used, the flag meant that your driver was
able to access high memory pages correctly (ie. didn't assume that
all pages were identity mapped) and that you could handle pages
that potentially had physical addresses above 4GB.
It was a big hammer handling a lack of proper APIs, that's all.
^ permalink raw reply
* Business Proposal
From: Leung W Lok @ 2014-02-12 22:20 UTC (permalink / raw)
To: Recipients
I wish to discuss a very confidential business proposition with you.
^ permalink raw reply
* Re: [PATCH net-next 00/14] ethtool: Improve documentation
From: David Miller @ 2014-02-12 22:36 UTC (permalink / raw)
To: ben; +Cc: netdev
In-Reply-To: <1392243184.15615.4.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Wed, 12 Feb 2014 22:13:04 +0000
> This series converts most comments in <linux/ethtool.h> into kernel-doc
> format, and expands them to describe the semantics as well as I
> understand them. It also fixes some kernel-doc formatting errors.
>
> I started on this at Solarflare, but they graciously allowed me to take
> it away and finish it off.
Series applied, thanks Ben.
^ permalink raw reply
* Re: [PATCH -next] gre: return more precise errno value when adding tunnel fails
From: Ben Hutchings @ 2014-02-12 22:33 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev
In-Reply-To: <1392197311-9676-1-git-send-email-fw@strlen.de>
[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]
On Wed, 2014-02-12 at 10:28 +0100, Florian Westphal wrote:
> Currently this always returns ENOBUFS, because the return value of
> __ip_tunnel_create is discarded.
>
> A more common failure is a duplicate name (EEXIST). Propagate the real
> error code so userspace can display a more meaningful error message.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> ---
> net/ipv4/ip_tunnel.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
> index 90ff957..ef43356 100644
> --- a/net/ipv4/ip_tunnel.c
> +++ b/net/ipv4/ip_tunnel.c
> @@ -393,7 +393,7 @@ static struct ip_tunnel *ip_tunnel_create(struct net *net,
> fbt = netdev_priv(itn->fb_tunnel_dev);
> dev = __ip_tunnel_create(net, itn->fb_tunnel_dev->rtnl_link_ops, parms);
> if (IS_ERR(dev))
> - return NULL;
> + return (void *) dev;
[...]
This should be written as ERR_CAST(dev).
Ben.
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* [PATCH] net: cpsw: catch of_get_phy_mode failing and propagate error
From: Uwe Kleine-König @ 2014-02-12 22:33 UTC (permalink / raw)
To: netdev; +Cc: kernel, Mugunthan V N, David S. Miller
It's wrong if the device tree doesn't provide a phy-mode property for
the cpsw slaves as it is documented to be required in
Documentation/devicetree/bindings/net/cpsw.txt.
Anyhow it's nice to catch that problem, still more as it used to work
without this property up to commit 388367a5a9fb (drivers: net: cpsw: use
cpsw-phy-sel driver to configure phy mode) which is in v3.13-rc1.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/net/ethernet/ti/cpsw.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 1d860ce914ed..542c5114851c 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1896,6 +1896,11 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
memcpy(slave_data->mac_addr, mac_addr, ETH_ALEN);
slave_data->phy_if = of_get_phy_mode(slave_node);
+ if (slave_data->phy_if < 0) {
+ pr_err("Missing or malformed slave[%d] phy-mode property\n",
+ i);
+ return slave_data->phy_if;
+ }
if (data->dual_emac) {
if (of_property_read_u32(slave_node, "dual_emac_res_vlan",
--
1.8.5.3
^ permalink raw reply related
* [PATCH net-next 14/14] ethtool: Fix unwanted section breaks in kernel-doc
From: Ben Hutchings @ 2014-02-12 22:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1392243184.15615.4.camel@deadeye.wl.decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2752 bytes --]
A colon almost unavoidably starts a new section. The script should be
changed to provide a way to avoid this, but for now reword the
comments to avoid using colons.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
include/uapi/linux/ethtool.h | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 24418ac..fd161e9 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -351,17 +351,18 @@ struct ethtool_modinfo {
* @rate_sample_interval: How often to do adaptive coalescing packet rate
* sampling, measured in seconds. Must not be zero.
*
- * Each pair of (usecs, max_frames) fields specifies this exit
- * condition for interrupt coalescing:
+ * Each pair of (usecs, max_frames) fields specifies that interrupts
+ * should be coalesced until
* (usecs > 0 && time_since_first_completion >= usecs) ||
* (max_frames > 0 && completed_frames >= max_frames)
+ *
* It is illegal to set both usecs and max_frames to zero as this
* would cause interrupts to never be generated. To disable
* coalescing, set usecs = 0 and max_frames = 1.
*
* Some implementations ignore the value of max_frames and use the
- * condition:
- * time_since_first_completion >= usecs
+ * condition time_since_first_completion >= usecs
+ *
* This is deprecated. Drivers for hardware that does not support
* counting completions should validate that max_frames == !rx_usecs.
*
@@ -809,7 +810,7 @@ struct ethtool_rx_flow_spec {
* %ETHTOOL_SRXCLSRLINS may add the rule at any suitable unused
* location, and may remove a rule at a later location (lower
* priority) that matches exactly the same set of flows. The special
- * values are: %RX_CLS_LOC_ANY, selecting any location;
+ * values are %RX_CLS_LOC_ANY, selecting any location;
* %RX_CLS_LOC_FIRST, selecting the first suitable location (maximum
* priority); and %RX_CLS_LOC_LAST, selecting the last suitable
* location (minimum priority). Additional special values may be
@@ -949,8 +950,9 @@ struct ethtool_get_features_block {
/**
* struct ethtool_gfeatures - command to get state of device's features
* @cmd: command number = %ETHTOOL_GFEATURES
- * @size: in: number of elements in the features[] array;
- * out: number of elements in features[] needed to hold all features
+ * @size: On entry, the number of elements in the features[] array;
+ * on return, the number of elements in features[] needed to hold
+ * all features
* @features: state of features
*/
struct ethtool_gfeatures {
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related
* [PATCH net-next 13/14] ethtool: Move kernel-doc comment next to struct ethtool_dump definition
From: Ben Hutchings @ 2014-02-12 22:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1392243184.15615.4.camel@deadeye.wl.decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 899 bytes --]
The kernel-doc script does not tolerate the macro definition in between.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
include/uapi/linux/ethtool.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 79be416..24418ac 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -920,9 +920,6 @@ struct ethtool_flash {
* for %ETHTOOL_GET_DUMP_FLAG command
* @data: data collected for get dump data operation
*/
-
-#define ETH_FW_DUMP_DISABLE 0
-
struct ethtool_dump {
__u32 cmd;
__u32 version;
@@ -931,6 +928,8 @@ struct ethtool_dump {
__u8 data[0];
};
+#define ETH_FW_DUMP_DISABLE 0
+
/* for returning and changing feature sets */
/**
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related
* [PATCH net-next 12/14] ethtool: Document the general convention for VLAs in kernel space
From: Ben Hutchings @ 2014-02-12 22:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1392243184.15615.4.camel@deadeye.wl.decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]
Various ethtool command structures are declared with zero-length array
at the end which are intended to be variable-length in userland
(relying on lack of compiler bounds checking). However, in the kernel
the structure and array are always allocated and passed to driver
operations separately. Make that explicit.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
include/linux/ethtool.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index c8e3e7e3..0a114d0 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -183,6 +183,9 @@ static inline u32 ethtool_rxfh_indir_default(u32 index, u32 n_rx_rings)
* hold the RTNL lock.
*
* See the structures used by these operations for further documentation.
+ * Note that for all operations using a structure ending with a zero-
+ * length array, the array is allocated separately in the kernel and
+ * is passed to the driver as an additional parameter.
*
* See &struct net_device and &struct net_device_ops for documentation
* of the generic netdev features interface.
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related
* [PATCH net-next 11/14] ethtool: Expand documentation of struct ethtool_perm_addr
From: Ben Hutchings @ 2014-02-12 22:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1392243184.15615.4.camel@deadeye.wl.decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
include/uapi/linux/ethtool.h | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index e96aec0..79be416 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -614,8 +614,19 @@ struct ethtool_stats {
__u64 data[0];
};
+/**
+ * struct ethtool_perm_addr - permanent hardware address
+ * @cmd: Command number = %ETHTOOL_GPERMADDR
+ * @size: On entry, the size of the buffer. On return, the size of the
+ * address. The command fails if the buffer is too small.
+ * @data: Buffer for the address
+ *
+ * Users must allocate the buffer immediately following this structure.
+ * A buffer size of %MAX_ADDR_LEN should be sufficient for any address
+ * type.
+ */
struct ethtool_perm_addr {
- __u32 cmd; /* ETHTOOL_GPERMADDR */
+ __u32 cmd;
__u32 size;
__u8 data[0];
};
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related
* [PATCH net-next 10/14] ethtool: Expand documentation of struct ethtool_stats
From: Ben Hutchings @ 2014-02-12 22:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1392243184.15615.4.camel@deadeye.wl.decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
include/uapi/linux/ethtool.h | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index f246f37..e96aec0 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -597,10 +597,20 @@ struct ethtool_test {
__u64 data[0];
};
-/* for dumping NIC-specific statistics */
+/**
+ * struct ethtool_stats - device-specific statistics
+ * @cmd: Command number = %ETHTOOL_GSTATS
+ * @n_stats: On return, the number of statistics
+ * @data: Array of statistics
+ *
+ * Users must use %ETHTOOL_GSSET_INFO or %ETHTOOL_GDRVINFO to find the
+ * number of statistics that will be returned. They must allocate a
+ * buffer of the appropriate size (8 * number of statistics)
+ * immediately following this structure.
+ */
struct ethtool_stats {
- __u32 cmd; /* ETHTOOL_GSTATS */
- __u32 n_stats; /* number of u64's being returned */
+ __u32 cmd;
+ __u32 n_stats;
__u64 data[0];
};
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related
* [PATCH net-next 09/14] ethtool: Expand documentation of struct ethtool_test
From: Ben Hutchings @ 2014-02-12 22:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1392243184.15615.4.camel@deadeye.wl.decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
include/uapi/linux/ethtool.h | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index e726340d..f246f37 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -575,12 +575,25 @@ enum ethtool_test_flags {
ETH_TEST_FL_EXTERNAL_LB_DONE = (1 << 3),
};
-/* for requesting NIC test and getting results*/
+/**
+ * struct ethtool_test - device self-test invocation
+ * @cmd: Command number = %ETHTOOL_TEST
+ * @flags: A bitmask of flags from &enum ethtool_test_flags. Some
+ * flags may be set by the user on entry; others may be set by
+ * the driver on return.
+ * @len: On return, the number of test results
+ * @data: Array of test results
+ *
+ * Users must use %ETHTOOL_GSSET_INFO or %ETHTOOL_GDRVINFO to find the
+ * number of test results that will be returned. They must allocate a
+ * buffer of the appropriate size (8 * number of results) immediately
+ * following this structure.
+ */
struct ethtool_test {
- __u32 cmd; /* ETHTOOL_TEST */
- __u32 flags; /* ETH_TEST_FL_xxx */
+ __u32 cmd;
+ __u32 flags;
__u32 reserved;
- __u32 len; /* result length, in number of u64 elements */
+ __u32 len;
__u64 data[0];
};
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related
* [PATCH net-next 08/14] ethtool: Expand documentation of string set types
From: Ben Hutchings @ 2014-02-12 22:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1392243184.15615.4.camel@deadeye.wl.decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 3293 bytes --]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
include/uapi/linux/ethtool.h | 59 +++++++++++++++++++++++++++++++++++---------
1 file changed, 47 insertions(+), 12 deletions(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 8ca2924..e726340d 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -496,31 +496,66 @@ struct ethtool_pauseparam {
};
#define ETH_GSTRING_LEN 32
+
+/**
+ * enum ethtool_stringset - string set ID
+ * @ETH_SS_TEST: Self-test result names, for use with %ETHTOOL_TEST
+ * @ETH_SS_STATS: Statistic names, for use with %ETHTOOL_GSTATS
+ * @ETH_SS_PRIV_FLAGS: Driver private flag names, for use with
+ * %ETHTOOL_GPFLAGS and %ETHTOOL_SPFLAGS
+ * @ETH_SS_NTUPLE_FILTERS: Previously used with %ETHTOOL_GRXNTUPLE;
+ * now deprecated
+ * @ETH_SS_FEATURES: Device feature names
+ */
enum ethtool_stringset {
ETH_SS_TEST = 0,
ETH_SS_STATS,
ETH_SS_PRIV_FLAGS,
- ETH_SS_NTUPLE_FILTERS, /* Do not use, GRXNTUPLE is now deprecated */
+ ETH_SS_NTUPLE_FILTERS,
ETH_SS_FEATURES,
};
-/* for passing string sets for data tagging */
+/**
+ * struct ethtool_gstrings - string set for data tagging
+ * @cmd: Command number = %ETHTOOL_GSTRINGS
+ * @string_set: String set ID; one of &enum ethtool_stringset
+ * @len: On return, the number of strings in the string set
+ * @data: Buffer for strings. Each string is null-padded to a size of
+ * %ETH_GSTRING_LEN.
+ *
+ * Users must use %ETHTOOL_GSSET_INFO to find the number of strings in
+ * the string set. They must allocate a buffer of the appropriate
+ * size immediately following this structure.
+ */
struct ethtool_gstrings {
- __u32 cmd; /* ETHTOOL_GSTRINGS */
- __u32 string_set; /* string set id e.c. ETH_SS_TEST, etc*/
- __u32 len; /* number of strings in the string set */
+ __u32 cmd;
+ __u32 string_set;
+ __u32 len;
__u8 data[0];
};
+/**
+ * struct ethtool_sset_info - string set information
+ * @cmd: Command number = %ETHTOOL_GSSET_INFO
+ * @sset_mask: On entry, a bitmask of string sets to query, with bits
+ * numbered according to &enum ethtool_stringset. On return, a
+ * bitmask of those string sets queried that are supported.
+ * @data: Buffer for string set sizes. On return, this contains the
+ * size of each string set that was queried and supported, in
+ * order of ID.
+ *
+ * Example: The user passes in @sset_mask = 0x7 (sets 0, 1, 2) and on
+ * return @sset_mask == 0x6 (sets 1, 2). Then @data[0] contains the
+ * size of set 1 and @data[1] contains the size of set 2.
+ *
+ * Users must allocate a buffer of the appropriate size (4 * number of
+ * sets queried) immediately following this structure.
+ */
struct ethtool_sset_info {
- __u32 cmd; /* ETHTOOL_GSSET_INFO */
+ __u32 cmd;
__u32 reserved;
- __u64 sset_mask; /* input: each bit selects an sset to query */
- /* output: each bit a returned sset */
- __u32 data[0]; /* ETH_SS_xxx count, in order, based on bits
- in sset_mask. One bit implies one
- __u32, two bits implies two
- __u32's, etc. */
+ __u64 sset_mask;
+ __u32 data[0];
};
/**
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related
* [PATCH] staging: r8188eu: Fix more Smatch warnings and errors
From: Larry Finger @ 2014-02-12 22:14 UTC (permalink / raw)
To: gregkh; +Cc: devel, netdev, Larry Finger
After updating Smatch, the following new errors and warnings are reported:
drivers/staging/rtl8188eu/core/rtw_recv.c:368 recvframe_chkmic() warn: variable dereferenced before check 'psecuritypriv' (see line 364)
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:2642 rtw_wps_start() warn: variable dereferenced before check 'pdata' (see line 2636)
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:4461 rtw_dbg_port() error: we previously assumed 'pregpriv' could be null (see line 4453)
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:4473 rtw_dbg_port() error: we previously assumed 'pregpriv' could be null (see line 4469)
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/staging/rtl8188eu/core/rtw_recv.c | 7 +++----
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 18 +++++++++---------
2 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_recv.c b/drivers/staging/rtl8188eu/core/rtw_recv.c
index 35397bd..bc5baf2 100644
--- a/drivers/staging/rtl8188eu/core/rtw_recv.c
+++ b/drivers/staging/rtl8188eu/core/rtw_recv.c
@@ -361,16 +361,15 @@ static int recvframe_chkmic(struct adapter *adapter, union recv_frame *precvfra
/* calculate mic code */
if (stainfo != NULL) {
if (IS_MCAST(prxattrib->ra)) {
- mickey = &psecuritypriv->dot118021XGrprxmickey[prxattrib->key_index].skey[0];
-
- RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("\n recvframe_chkmic: bcmc key\n"));
-
if (!psecuritypriv) {
res = _FAIL;
RT_TRACE(_module_rtl871x_recv_c_, _drv_err_, ("\n recvframe_chkmic:didn't install group key!!!!!!!!!!\n"));
DBG_88E("\n recvframe_chkmic:didn't install group key!!!!!!!!!!\n");
goto exit;
}
+ mickey = &psecuritypriv->dot118021XGrprxmickey[prxattrib->key_index].skey[0];
+
+ RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("\n recvframe_chkmic: bcmc key\n"));
} else {
mickey = &stainfo->dot11tkiprxmickey.skey[0];
RT_TRACE(_module_rtl871x_recv_c_, _drv_err_, ("\n recvframe_chkmic: unicast key\n"));
diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index 7de8139..3691007 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -2633,13 +2633,13 @@ static int rtw_wps_start(struct net_device *dev,
struct iw_point *pdata = &wrqu->data;
u32 u32wps_start = 0;
- ret = copy_from_user((void *)&u32wps_start, pdata->pointer, 4);
- if (ret) {
+ if ((padapter->bDriverStopped) || (pdata == NULL)) {
ret = -EINVAL;
goto exit;
}
- if ((padapter->bDriverStopped) || (pdata == NULL)) {
+ ret = copy_from_user((void *)&u32wps_start, pdata->pointer, 4);
+ if (ret) {
ret = -EINVAL;
goto exit;
}
@@ -4450,11 +4450,9 @@ static int rtw_dbg_port(struct net_device *dev,
struct registry_priv *pregpriv = &padapter->registrypriv;
/* 0: disable, bit(0):enable 2.4g, bit(1):enable 5g, 0x3: enable both 2.4g and 5g */
/* default is set to enable 2.4GHZ for IOT issue with bufflao's AP at 5GHZ */
- if (pregpriv &&
- (extra_arg == 0 ||
- extra_arg == 1 ||
- extra_arg == 2 ||
- extra_arg == 3)) {
+ if (!pregpriv)
+ break;
+ if (extra_arg >= 0 && extra_arg <= 3) {
pregpriv->rx_stbc = extra_arg;
DBG_88E("set rx_stbc =%d\n", pregpriv->rx_stbc);
} else {
@@ -4466,7 +4464,9 @@ static int rtw_dbg_port(struct net_device *dev,
{
struct registry_priv *pregpriv = &padapter->registrypriv;
/* 0: disable, 0x1:enable (but wifi_spec should be 0), 0x2: force enable (don't care wifi_spec) */
- if (pregpriv && extra_arg >= 0 && extra_arg < 3) {
+ if (!pregpriv)
+ break;
+ if (extra_arg >= 0 && extra_arg < 3) {
pregpriv->ampdu_enable = extra_arg;
DBG_88E("set ampdu_enable =%d\n", pregpriv->ampdu_enable);
} else {
--
1.8.4.5
^ permalink raw reply related
* [PATCH net-next 07/14] ethtool: Update documentation of struct ethtool_pauseparam
From: Ben Hutchings @ 2014-02-12 22:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1392243184.15615.4.camel@deadeye.wl.decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2746 bytes --]
Convert the inline comments to kernel-doc format.
Explicitly specify that non-zero autoneg is an error if link
autonegotiation is disabled.
Specify that pause capabilities should be advertised dependent on link
autonegotiation, not the autoneg flag here. There is no way to
opt-out of pause frame autonegotiation, and this improves behaviour
when the link partner is configured to follow pause frame
autonegotiation and our interface is not.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
include/uapi/linux/ethtool.h | 36 +++++++++++++++++++++++-------------
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index e602cd0..8ca2924 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -466,20 +466,30 @@ struct ethtool_channels {
__u32 combined_count;
};
-/* for configuring link flow control parameters */
+/**
+ * struct ethtool_pauseparam - Ethernet pause (flow control) parameters
+ * @cmd: Command number = %ETHTOOL_GPAUSEPARAM or %ETHTOOL_SPAUSEPARAM
+ * @autoneg: Flag to enable autonegotiation of pause frame use
+ * @rx_pause: Flag to enable reception of pause frames
+ * @tx_pause: Flag to enable transmission of pause frames
+ *
+ * Drivers should reject a non-zero setting of @autoneg when
+ * autoneogotiation is disabled (or not supported) for the link.
+ *
+ * If the link is autonegotiated, drivers should use
+ * mii_advertise_flowctrl() or similar code to set the advertised
+ * pause frame capabilities based on the @rx_pause and @tx_pause flags,
+ * even if @autoneg is zero. They should also allow the advertised
+ * pause frame capabilities to be controlled directly through the
+ * advertising field of &struct ethtool_cmd.
+ *
+ * If @autoneg is non-zero, the MAC is configured to send and/or
+ * receive pause frames according to the result of autonegotiation.
+ * Otherwise, it is configured directly based on the @rx_pause and
+ * @tx_pause flags.
+ */
struct ethtool_pauseparam {
- __u32 cmd; /* ETHTOOL_{G,S}PAUSEPARAM */
-
- /* If the link is being auto-negotiated (via ethtool_cmd.autoneg
- * being true) the user may set 'autoneg' here non-zero to have the
- * pause parameters be auto-negotiated too. In such a case, the
- * {rx,tx}_pause values below determine what capabilities are
- * advertised.
- *
- * If 'autoneg' is zero or the link is not being auto-negotiated,
- * then {rx,tx}_pause force the driver to use/not-use pause
- * flow control.
- */
+ __u32 cmd;
__u32 autoneg;
__u32 rx_pause;
__u32 tx_pause;
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related
* [PATCH net-next 06/14] ethtool: Expand documentation of struct ethtool_ringparam
From: Ben Hutchings @ 2014-02-12 22:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1392243184.15615.4.camel@deadeye.wl.decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2271 bytes --]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
include/uapi/linux/ethtool.h | 37 ++++++++++++++++++++++++++-----------
1 file changed, 26 insertions(+), 11 deletions(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index d5a0d20..e602cd0 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -401,22 +401,37 @@ struct ethtool_coalesce {
__u32 rate_sample_interval;
};
-/* for configuring RX/TX ring parameters */
+/**
+ * struct ethtool_ringparam - RX/TX ring parameters
+ * @cmd: Command number = %ETHTOOL_GRINGPARAM or %ETHTOOL_SRINGPARAM
+ * @rx_max_pending: Maximum supported number of pending entries per
+ * RX ring. Read-only.
+ * @rx_mini_max_pending: Maximum supported number of pending entries
+ * per RX mini ring. Read-only.
+ * @rx_jumbo_max_pending: Maximum supported number of pending entries
+ * per RX jumbo ring. Read-only.
+ * @tx_max_pending: Maximum supported number of pending entries per
+ * TX ring. Read-only.
+ * @rx_pending: Current maximum number of pending entries per RX ring
+ * @rx_mini_pending: Current maximum number of pending entries per RX
+ * mini ring
+ * @rx_jumbo_pending: Current maximum number of pending entries per RX
+ * jumbo ring
+ * @tx_pending: Current maximum supported number of pending entries
+ * per TX ring
+ *
+ * If the interface does not have separate RX mini and/or jumbo rings,
+ * @rx_mini_max_pending and/or @rx_jumbo_max_pending will be 0.
+ *
+ * There may also be driver-dependent minimum values for the number
+ * of entries per ring.
+ */
struct ethtool_ringparam {
- __u32 cmd; /* ETHTOOL_{G,S}RINGPARAM */
-
- /* Read only attributes. These indicate the maximum number
- * of pending RX/TX ring entries the driver will allow the
- * user to set.
- */
+ __u32 cmd;
__u32 rx_max_pending;
__u32 rx_mini_max_pending;
__u32 rx_jumbo_max_pending;
__u32 tx_max_pending;
-
- /* Values changeable by the user. The valid values are
- * in the range 1 to the "*_max_pending" counterpart above.
- */
__u32 rx_pending;
__u32 rx_mini_pending;
__u32 rx_jumbo_pending;
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related
* [PATCH net-next 05/14] ethtool: Expand documentation of struct ethtool_eeprom
From: Ben Hutchings @ 2014-02-12 22:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1392243184.15615.4.camel@deadeye.wl.decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
include/uapi/linux/ethtool.h | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 441bd31..d5a0d20 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -231,12 +231,29 @@ struct ethtool_regs {
__u8 data[0];
};
-/* for passing EEPROM chunks */
+/**
+ * struct ethtool_eeprom - EEPROM dump
+ * @cmd: Command number = %ETHTOOL_GEEPROM, %ETHTOOL_GMODULEEEPROM or
+ * %ETHTOOL_SEEPROM
+ * @magic: A 'magic cookie' value to guard against accidental changes.
+ * The value passed in to %ETHTOOL_SEEPROM must match the value
+ * returned by %ETHTOOL_GEEPROM for the same device. This is
+ * unused when @cmd is %ETHTOOL_GMODULEEEPROM.
+ * @offset: Offset within the EEPROM to begin reading/writing, in bytes
+ * @len: On entry, number of bytes to read/write. On successful
+ * return, number of bytes actually read/written. In case of
+ * error, this may indicate at what point the error occurred.
+ * @data: Buffer to read/write from
+ *
+ * Users may use %ETHTOOL_GDRVINFO or %ETHTOOL_GMODULEINFO to find
+ * the length of an on-board or module EEPROM, respectively. They
+ * must allocate the buffer immediately following this structure.
+ */
struct ethtool_eeprom {
__u32 cmd;
__u32 magic;
- __u32 offset; /* in bytes */
- __u32 len; /* in bytes */
+ __u32 offset;
+ __u32 len;
__u8 data[0];
};
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related
* [PATCH net-next 04/14] ethtool: Expand documentation of struct ethtool_regs
From: Ben Hutchings @ 2014-02-12 22:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1392243184.15615.4.camel@deadeye.wl.decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
include/uapi/linux/ethtool.h | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 15a42de..441bd31 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -209,11 +209,25 @@ struct ethtool_value {
__u32 data;
};
-/* for passing big chunks of data */
+/**
+ * struct ethtool_regs - hardware register dump
+ * @cmd: Command number = %ETHTOOL_GREGS
+ * @version: Dump format version. This is driver-specific and may
+ * distinguish different chips/revisions. Drivers must use new
+ * version numbers whenever the dump format changes in an
+ * incompatible way.
+ * @len: On entry, the real length of @data. On return, the number of
+ * bytes used.
+ * @data: Buffer for the register dump
+ *
+ * Users should use %ETHTOOL_GDRVINFO to find the maximum length of
+ * a register dump for the interface. They must allocate the buffer
+ * immediately following this structure.
+ */
struct ethtool_regs {
__u32 cmd;
- __u32 version; /* driver-specific, indicates different chips/revs */
- __u32 len; /* bytes */
+ __u32 version;
+ __u32 len;
__u8 data[0];
};
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related
* [PATCH net-next 03/14] ethtool: Expand documentation of struct ethtool_wol
From: Ben Hutchings @ 2014-02-12 22:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1392243184.15615.4.camel@deadeye.wl.decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
include/uapi/linux/ethtool.h | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index cc523cb..15a42de 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -186,12 +186,21 @@ struct ethtool_drvinfo {
};
#define SOPASS_MAX 6
-/* wake-on-lan settings */
+
+/**
+ * struct ethtool_wolinfo - Wake-On-Lan configuration
+ * @cmd: Command number = %ETHTOOL_GWOL or %ETHTOOL_SWOL
+ * @supported: Bitmask of %WAKE_* flags for supported Wake-On-Lan modes.
+ * Read-only.
+ * @wolopts: Bitmask of %WAKE_* flags for enabled Wake-On-Lan modes.
+ * @sopass: SecureOn(tm) password; meaningful only if %WAKE_MAGICSECURE
+ * is set in @wolopts.
+ */
struct ethtool_wolinfo {
__u32 cmd;
__u32 supported;
__u32 wolopts;
- __u8 sopass[SOPASS_MAX]; /* SecureOn(tm) password */
+ __u8 sopass[SOPASS_MAX];
};
/* for passing single values */
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related
* [PATCH net-next 02/14] ethtool: Expand documentation of struct ethtool_drvinfo
From: Ben Hutchings @ 2014-02-12 22:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1392243184.15615.4.camel@deadeye.wl.decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 3803 bytes --]
Replace the inline comments (and some others below) with a full
explanation of the semantics, in kernel-doc format. Specify which
strings may be empty. Document the relationship with other commands.
Replace the 'deprecation' of some fields with a proper explanation of
the conversion to generalised string sets, as userland programs may
not be able to assume that ETHTOOL_GSSET_INFO is available.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
include/uapi/linux/ethtool.h | 56 ++++++++++++++++++++++++++++++--------------
1 file changed, 39 insertions(+), 17 deletions(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index c4d5eb2..cc523cb 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -139,28 +139,50 @@ static inline __u32 ethtool_cmd_speed(const struct ethtool_cmd *ep)
#define ETHTOOL_FWVERS_LEN 32
#define ETHTOOL_BUSINFO_LEN 32
-/* these strings are set to whatever the driver author decides... */
+
+/**
+ * struct ethtool_drvinfo - general driver and device information
+ * @cmd: Command number = %ETHTOOL_GDRVINFO
+ * @driver: Driver short name. This should normally match the name
+ * in its bus driver structure (e.g. pci_driver::name). Must
+ * not be an empty string.
+ * @version: Driver version string; may be an empty string
+ * @fw_version: Firmware 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.
+ * @n_priv_flags: Number of flags valid for %ETHTOOL_GPFLAGS and
+ * %ETHTOOL_SPFLAGS commands; also the number of strings in the
+ * %ETH_SS_PRIV_FLAGS set
+ * @n_stats: Number of u64 statistics returned by the %ETHTOOL_GSTATS
+ * command; also the number of strings in the %ETH_SS_STATS set
+ * @testinfo_len: Number of results returned by the %ETHTOOL_TEST
+ * command; also the number of strings in the %ETH_SS_TEST set
+ * @eedump_len: Size of EEPROM accessible through the %ETHTOOL_GEEPROM
+ * and %ETHTOOL_SEEPROM commands, in bytes
+ * @regdump_len: Size of register dump returned by the %ETHTOOL_GREGS
+ * command, in bytes
+ *
+ * Users can use the %ETHTOOL_GSSET_INFO command to get the number of
+ * strings in any string set (from Linux 2.6.34).
+ *
+ * Drivers should set at most @driver, @version, @fw_version and
+ * @bus_info in their get_drvinfo() implementation. The ethtool
+ * core fills in the other fields using other driver operations.
+ */
struct ethtool_drvinfo {
__u32 cmd;
- char driver[32]; /* driver short name, "tulip", "eepro100" */
- char version[32]; /* driver version string */
- char fw_version[ETHTOOL_FWVERS_LEN]; /* firmware version string */
- char bus_info[ETHTOOL_BUSINFO_LEN]; /* Bus info for this IF. */
- /* For PCI devices, use pci_name(pci_dev). */
+ char driver[32];
+ char version[32];
+ char fw_version[ETHTOOL_FWVERS_LEN];
+ char bus_info[ETHTOOL_BUSINFO_LEN];
char reserved1[32];
char reserved2[12];
- /*
- * Some struct members below are filled in
- * using ops->get_sset_count(). Obtaining
- * this info from ethtool_drvinfo is now
- * deprecated; Use ETHTOOL_GSSET_INFO
- * instead.
- */
- __u32 n_priv_flags; /* number of flags valid in ETHTOOL_GPFLAGS */
- __u32 n_stats; /* number of u64's from ETHTOOL_GSTATS */
+ __u32 n_priv_flags;
+ __u32 n_stats;
__u32 testinfo_len;
- __u32 eedump_len; /* Size of data from ETHTOOL_GEEPROM (bytes) */
- __u32 regdump_len; /* Size of data from ETHTOOL_GREGS (bytes) */
+ __u32 eedump_len;
+ __u32 regdump_len;
};
#define SOPASS_MAX 6
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related
* [PATCH net-next 01/14] ethtool: Expand documentation of struct ethtool_cmd
From: Ben Hutchings @ 2014-02-12 22:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1392243184.15615.4.camel@deadeye.wl.decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 7514 bytes --]
struct ethtool_cmd has very limited documentation; it contains
several obscure or obsolete fields and several with non-obvious
interpretation.
Replace the inline comments (and some others below) with a full
explanation of the semantics as well as I understand them, in
kernel-doc format. Formally deprecate some fields that seem to be of
historical use only.
Extend the comment about 32/64-bit compatibility to cover all
ethtool structures.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
include/uapi/linux/ethtool.h | 124 +++++++++++++++++++++++++++++++------------
1 file changed, 90 insertions(+), 34 deletions(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 38dbafa..c4d5eb2 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -16,37 +16,97 @@
#include <linux/types.h>
#include <linux/if_ether.h>
-/* This should work for both 32 and 64 bit userland. */
+/* All structures exposed to userland should be defined such that they
+ * have the same layout for 32-bit and 64-bit userland.
+ */
+
+/**
+ * struct ethtool_cmd - link control and status
+ * @cmd: Command number = %ETHTOOL_GSET or %ETHTOOL_SSET
+ * @supported: Bitmask of %SUPPORTED_* flags for the link modes,
+ * physical connectors and other link features for which the
+ * interface supports autonegotiation or auto-detection.
+ * Read-only.
+ * @advertising: Bitmask of %ADVERTISED_* flags for the link modes,
+ * physical connectors and other link features that are
+ * advertised through autonegotiation or enabled for
+ * auto-detection.
+ * @speed: Low bits of the speed
+ * @duplex: Duplex mode; one of %DUPLEX_*
+ * @port: Physical connector type; one of %PORT_*
+ * @phy_address: MDIO address of PHY (transceiver); 0 or 255 if not
+ * applicable. For clause 45 PHYs this is the PRTAD.
+ * @transceiver: Historically used to distinguish different possible
+ * PHY types, but not in a consistent way. Deprecated.
+ * @autoneg: Enable/disable autonegotiation and auto-detection;
+ * either %AUTONEG_DISABLE or %AUTONEG_ENABLE
+ * @mdio_support: Bitmask of %ETH_MDIO_SUPPORTS_* flags for the MDIO
+ * protocols supported by the interface; 0 if unknown.
+ * Read-only.
+ * @maxtxpkt: Historically used to report TX IRQ coalescing; now
+ * obsoleted by &struct ethtool_coalesce. Read-only; deprecated.
+ * @maxrxpkt: Historically used to report RX IRQ coalescing; now
+ * obsoleted by &struct ethtool_coalesce. Read-only; deprecated.
+ * @speed_hi: High bits of the speed
+ * @eth_tp_mdix: Ethernet twisted-pair MDI(-X) status; one of
+ * %ETH_TP_MDI_*. If the status is unknown or not applicable, the
+ * value will be %ETH_TP_MDI_INVALID. Read-only.
+ * @eth_tp_mdix_ctrl: Ethernet twisted pair MDI(-X) control; one of
+ * %ETH_TP_MDI_*. If MDI(-X) control is not implemented, reads
+ * yield %ETH_TP_MDI_INVALID and writes may be ignored or rejected.
+ * When written successfully, the link should be renegotiated if
+ * necessary.
+ * @lp_advertising: Bitmask of %ADVERTISED_* flags for the link modes
+ * and other link features that the link partner advertised
+ * through autonegotiation; 0 if unknown or not applicable.
+ * Read-only.
+ *
+ * The link speed in Mbps is split between @speed and @speed_hi. Use
+ * the ethtool_cmd_speed() and ethtool_cmd_speed_set() functions to
+ * access it.
+ *
+ * If autonegotiation is disabled, the speed and @duplex represent the
+ * fixed link mode and are writable if the driver supports multiple
+ * link modes. If it is enabled then they are read-only; if the link
+ * is up they represent the negotiated link mode; if the link is down,
+ * the speed is 0, %SPEED_UNKNOWN or the highest enabled speed and
+ * @duplex is %DUPLEX_UNKNOWN or the best enabled duplex mode.
+ *
+ * Some hardware interfaces may have multiple PHYs and/or physical
+ * connectors fitted or do not allow the driver to detect which are
+ * fitted. For these interfaces @port and/or @phy_address may be
+ * writable, possibly dependent on @autoneg being %AUTONEG_DISABLE.
+ * Otherwise, attempts to write different values may be ignored or
+ * rejected.
+ *
+ * Users should assume that all fields not marked read-only are
+ * writable and subject to validation by the driver. They should use
+ * %ETHTOOL_GSET to get the current values before making specific
+ * changes and then applying them with %ETHTOOL_SSET.
+ *
+ * Drivers that implement set_settings() should validate all fields
+ * other than @cmd that are not described as read-only or deprecated,
+ * and must ignore all fields described as read-only.
+ *
+ * Deprecated fields should be ignored by both users and drivers.
+ */
struct ethtool_cmd {
__u32 cmd;
- __u32 supported; /* Features this interface supports */
- __u32 advertising; /* Features this interface advertises */
- __u16 speed; /* The forced speed (lower bits) in
- * Mbps. Please use
- * ethtool_cmd_speed()/_set() to
- * access it */
- __u8 duplex; /* Duplex, half or full */
- __u8 port; /* Which connector port */
- __u8 phy_address; /* MDIO PHY address (PRTAD for clause 45).
- * May be read-only or read-write
- * depending on the driver.
- */
- __u8 transceiver; /* Which transceiver to use */
- __u8 autoneg; /* Enable or disable autonegotiation */
- __u8 mdio_support; /* MDIO protocols supported. Read-only.
- * Not set by all drivers.
- */
- __u32 maxtxpkt; /* Tx pkts before generating tx int */
- __u32 maxrxpkt; /* Rx pkts before generating rx int */
- __u16 speed_hi; /* The forced speed (upper
- * bits) in Mbps. Please use
- * ethtool_cmd_speed()/_set() to
- * access it */
- __u8 eth_tp_mdix; /* twisted pair MDI-X status */
- __u8 eth_tp_mdix_ctrl; /* twisted pair MDI-X control, when set,
- * link should be renegotiated if necessary
- */
- __u32 lp_advertising; /* Features the link partner advertises */
+ __u32 supported;
+ __u32 advertising;
+ __u16 speed;
+ __u8 duplex;
+ __u8 port;
+ __u8 phy_address;
+ __u8 transceiver;
+ __u8 autoneg;
+ __u8 mdio_support;
+ __u32 maxtxpkt;
+ __u32 maxrxpkt;
+ __u16 speed_hi;
+ __u8 eth_tp_mdix;
+ __u8 eth_tp_mdix_ctrl;
+ __u32 lp_advertising;
__u32 reserved[2];
};
@@ -905,7 +965,6 @@ enum ethtool_sfeatures_retval_bits {
#define SPARC_ETH_GSET ETHTOOL_GSET
#define SPARC_ETH_SSET ETHTOOL_SSET
-/* Indicates what features are supported by the interface. */
#define SUPPORTED_10baseT_Half (1 << 0)
#define SUPPORTED_10baseT_Full (1 << 1)
#define SUPPORTED_100baseT_Half (1 << 2)
@@ -934,7 +993,6 @@ enum ethtool_sfeatures_retval_bits {
#define SUPPORTED_40000baseSR4_Full (1 << 25)
#define SUPPORTED_40000baseLR4_Full (1 << 26)
-/* Indicates what features are advertised by the interface. */
#define ADVERTISED_10baseT_Half (1 << 0)
#define ADVERTISED_10baseT_Full (1 << 1)
#define ADVERTISED_100baseT_Half (1 << 2)
@@ -999,9 +1057,7 @@ enum ethtool_sfeatures_retval_bits {
#define XCVR_DUMMY2 0x03
#define XCVR_DUMMY3 0x04
-/* Enable or disable autonegotiation. If this is set to enable,
- * the forced link modes above are completely ignored.
- */
+/* Enable or disable autonegotiation. */
#define AUTONEG_DISABLE 0x00
#define AUTONEG_ENABLE 0x01
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related
* [PATCH net-next 00/14] ethtool: Improve documentation
From: Ben Hutchings @ 2014-02-12 22:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]
This series converts most comments in <linux/ethtool.h> into kernel-doc
format, and expands them to describe the semantics as well as I
understand them. It also fixes some kernel-doc formatting errors.
I started on this at Solarflare, but they graciously allowed me to take
it away and finish it off.
Ben.
Ben Hutchings (14):
ethtool: Expand documentation of struct ethtool_cmd
ethtool: Expand documentation of struct ethtool_drvinfo
ethtool: Expand documentation of struct ethtool_wol
ethtool: Expand documentation of struct ethtool_regs
ethtool: Expand documentation of struct ethtool_eeprom
ethtool: Expand documentation of struct ethtool_ringparam
ethtool: Update documentation of struct ethtool_pauseparam
ethtool: Expand documentation of string set types
ethtool: Expand documentation of struct ethtool_test
ethtool: Expand documentation of struct ethtool_stats
ethtool: Expand documentation of struct ethtool_perm_addr
ethtool: Document the general convention for VLAs in kernel space
ethtool: Move kernel-doc comment next to struct ethtool_dump
definition
ethtool: Fix unwanted section breaks in kernel-doc
include/linux/ethtool.h | 3 +
include/uapi/linux/ethtool.h | 439 ++++++++++++++++++++++++++++++++-----------
2 files changed, 329 insertions(+), 113 deletions(-)
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address
From: Luis R. Rodriguez @ 2014-02-12 22:05 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev@vger.kernel.org, xen-devel, Paul Durrant, Wei Liu, kvm,
linux-kernel@vger.kernel.org
In-Reply-To: <1392203708.13563.50.camel@kazak.uk.xensource.com>
On Wed, Feb 12, 2014 at 3:15 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2014-02-11 at 13:53 -0800, Luis R. Rodriguez wrote:
>> Cc'ing kvm folks as they may have a shared interest on the shared
>> physical case with the bridge (non NAT).
>>
>> On Tue, Feb 11, 2014 at 12:43 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
>> >> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>> >>
>> >> Although the xen-netback interfaces do not participate in the
>> >> link as a typical Ethernet device interfaces for them are
>> >> still required under the current archtitecture. IPv6 addresses
>> >> do not need to be created or assigned on the xen-netback interfaces
>> >> however, even if the frontend devices do need them, so clear the
>> >> multicast flag to ensure the net core does not initiate IPv6
>> >> Stateless Address Autoconfiguration.
>> >
>> > How does disabling SAA flow from the absence of multicast?
>>
>> See patch 1 in this series [0], but I explain the issue I see with
>> this on the cover letter [1].
>
> Oop, I felt like I'd missed some context. Thanks for pointing out that
> it was right under my nose.
>
>> In summary the RFCs on IPv6 make it
>> clear you need multicast for Stateless address autoconfiguration
>> (SLAAC is the preferred acronym) and DAD,
>
> That seems reasonable, but I think is the opposite to what I was trying
> to get at.
>
> Why is it not possible to disable SLAAC and/or DAD even if multicast is
> present?
Even if you set your IP address manually you still need to send router
solicitations using multicast, you also need to do DAD.
> IOW -- enabling/disabling multicast seems to me to be an odd proxy for
> disabling SLAAC or DAD and AIUI your patch fixes the opposite case,
> which is to avoid SLAAC and DAD on interfaces which don't do multicast
> (which makes sense since those protocols involve multicast).
Agreed :)
>> however the net core has not
>> made this a requirement, and hence the patch. The caveat which I
>> address on the cover letter needs to be seriously considered though.
>>
>> [0] http://marc.info/?l=linux-netdev&m=139207142110535&w=2
>> [1] http://marc.info/?l=linux-netdev&m=139207142110536&w=2
>>
>> > Surely these should be controlled logically independently even if there is some
>> > notional linkage.
>>
>> When a node hops on a network it will query its network by sending a
>> router solicitation multicast request for its configuration
>> parameters, the router can respond with router advertisements to
>> disable SLAAC.
>
> Surely it should be possible for an interface to be explicitly not ipv6
> enabled, in which case it doesn't want to do any solicitation at all.
There are run time configuration options, but not net_device flags.
More on this below.
>> Apart from that we have no other means to disable SLAAC neatly, and as
>> I gather that would be counter to the IPv6 RFCs anyway, and that makes
>> sense.
>
> In your[0] post you say:
> it should be noted that RFC4682 Section 5.4
> makes it clear that DAD *MUST* be performed on all unicast
> addresses prior to assigning them to an interface
>
> is that what you mean by counter to the RFCs?
Yeap.
> In my reading this "must do DAD" requirement only comes into affect if
> you are trying to assign a unicast address to an interface. It should be
> possible to simply not do that for an interface.
That is correct, why enable ipv6 then on that interfaces then? We have
the loopback for local stuff.
>> > Can SAA not be disabled directly?
>>
>> Nope. The ipv6 core assumes all device want ipv6
>
> IMHO it is entirely reasonable for an admin to desire that an interface
> has nothing at all to do with IPv6. At which point all of the
> requirements for multicast which flow from enabling IPv6 disappear.
Agreed.
>> >> since using this can create an issue if a user
>> >> decides to enable multicast on the backend interfaces
>> >
>> > Please explain what this issue is.
>>
>> I explained this on the cover letter but should have elaborated more
>> here. The *known* and *reported* issue is that xen-backend interfaces
>> can end up SLAAC and you'd obviously end up in some situations where
>> the MAC address and IP address clash, despite the architecture of IPv6
>> to randomize time requests for neighbor solicitations, and DAD.
>> Ultimately a series of services can end up filling your log messages
>> with tons of warnings.
>
> Right, this makes sense, but it seems like the solution should be to
> stop SLAAC from happening directly and not by playing tricks with
> multicast that happen to have the side effect of disabling SLAAC.
Agreed, however as I see it since yesterday the requirement for
multicast for IPv6 should likely become a requirement for dev->type
ether, there however is a module parameter to disable autoconf
completely though so I believe there may be some ether dev->type
devices out there with IPv6 without multicast, and while that seems
counter to the requirements on the RFCs it is something to consider.
At this point I consider the above a separate discussion (but one I'll
follow up with an RFCv2 patch), given that it seems we are in
agreement we should *consider* the ability to disable ipv6 all
together from a net_device. More on this below.
>> Another not reported issue, but I suspect critical and it can bite
>> both xen and kvm in the ass is described on Appendex A on RFC 4862 [2]
>> which considers the issues of getting duplicates of packets on the
>> same link with the same link layer address. I think to address that we
>> can also consider dev->type into all the different cases.
>
> We should never actually be generating any traffic with this address
> FWIW, all the generated traffic will have the guest's actual MAC. (at
> least in the bridging case, perhaps with with routing or NAT things are
> different, but I think in that case the traffic would appear to come
> from the hosts outgoing interface, not the vif device)
Which leads me to believe that creating a regular interface for a
backend interface seems overkill. I'm evaluating the minimal
requirements on the xen-backend case for an interface and believe this
can likely be shared with as a type of interface with kvm. Furthermore
the bridging could then be extended to not use its MAC address for the
root port even if STP were enabled.
>> My preference, rather than trying to simply disable ipv6 is actually
>> seeing how xen-netback interfaces (and kvm TAP topology) can be
>> simplified further). As I see it there is tons of code which could
>> trigger being used on these xen-netback interfaces (and TAP for kvm)
>> which is simply not needed for the use case of just doing sending data
>> back and forth between host and guest: ipv6 is not needed at all, and
>> I tried to test removing ipv4, but ran into issues.
>
> Bridging is not the only way to provide VM network connectivity. It
> should also be possible to do routing and even NAT by configuring
> appropriate p2p links and routing tables in the host. For that to work I
> think the tap and vif devices do need some sort of IPv[46] capability,
We have to be careful for sure, I'll try to test all cases including
kvm, but architecturally as I see it so far these things are simply
exchanging over data through their respective backend channels, I know
ipv6 interfaces are unused and I'm going to dig further to see why at
least one ipv4 interfaces is needed. I cannot fathom why either of
these interfaces would be required. I'll do a bit more digging.
The TAP interface requirements may be different, I haven't yet dug into that.
> so you can't just nuke that stuff completely. (Maybe/likely it also
> requires them to have a sensible MAC address, I'm not sure).
I'll dig.
>> [2] http://tools.ietf.org/html/rfc4862#appendix-A
>> [3[ https://gitorious.org/opensuse/kernel-source/source/8e16582178a29b03e850468004a47e7be5ed3005:patches.xen/ipv6-no-autoconf
>>
>> > Also how can a user enable multicast on the b/e?
>>
>> ip set multicast on dev <devname>
>> ip set multicast off dev <devname>
>>
>> > AFAIK only Solaris ever
>> > implemented the m/c bits of the Xen PV network protocol (not that I
>> > wouldn't welcome attempts to add it to other platforms)
>>
>> Do you mean kernel configuration multicast ? Or networking ?
>
> I meant the PV protocol extension which allows guests (netfront) to
> register to receive multicast frames across the PV ring -- i.e. for
> multicast to work from the guests PoV.
Not quite sure I understand, ipv6 works on guests so multicast works,
so its unclear what you mean by multicast frames across the PV ring.
Is there any code or or documents I can look at ?
> (maybe that was just an optimisation though and the default is to flood
> everything, it was a long time ago)
>From a networking perspective everything is being flooded as I've seen
it so far.
Luis
^ 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