user/sven/linux.git/include/linux/ethtool.h, branch v3.2.83

bonding: comparing a u8 with -1 is always false

2011-11-04T22:37:23Z

slave->duplex is a u8 type so the in bond_info_show_slave() when we check "if (slave->duplex == -1)", it's always false. Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller

ethtool: Update ethtool_rxnfc::rule_cnt on return from ETHTOOL_GRXCLSRLALL

2011-09-16T23:25:10Z

A user-space process must use ETHTOOL_GRXCLSRLCNT to find the number of classification rules, then allocate a buffer of the right size, then use ETHTOOL_GRXCLSRLALL to fill the buffer. If some other process inserts or deletes a rule between those two operations, the user buffer might turn out to be the wrong size. If it's too small, the return value will be -EMSGSIZE. But if it's too large, there is no indication of this. Fix this by updating the rule_cnt field on return. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller

ethtool: Clean up definitions of rule location arrays in RX NFC

2011-09-16T23:25:10Z

Correct the description of ethtool_rxnfc::rule_locs; it is an array of currently used locations, not all possible valid locations. Add note that drivers must not use ethtool_rxnfc::rule_locs. The rule_locs argument to ethtool_ops::get_rxnfc is either NULL or a pointer to an array of u32, so change the parameter type accordingly. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller

ethtool: Explicitly state that RX NFC rule locations are priorities

2011-09-16T23:25:10Z

The location of an RX flow classification rule is needed to identify it for retrieval, replacement or deletion. However it also defines the priority of the rule in the case that a flow is matched by multiple rules. This is what I intended to imply by referring to the use of a TCAM, commonly used to implement that behaviour. However there are other ways this can be done, and it is better to specify this explicitly. Further, I want to add the option for automatic selection of rule locations. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller

ethtool: Make struct ethtool_rxnfc kernel-doc more self-consistent

2011-09-16T23:25:10Z

Refer consistently to 'classification rules' or just 'rules' rather than 'filter specifications' or 'filter rules'. Refer consistently to rule 'locations' and not 'indices'. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller

net: consolidate and fix ethtool_ops->get_settings calling

2011-09-15T21:32:26Z

This patch does several things: - introduces __ethtool_get_settings which is called from ethtool code and from drivers as well. Put ASSERT_RTNL there. - dev_ethtool_get_settings() is replaced by __ethtool_get_settings() - changes calling in drivers so rtnl locking is respected. In iboe_get_rate was previously ->get_settings() called unlocked. This fixes it. Also prb_calc_retire_blk_tmo() in af_packet.c had the same problem. Also fixed by calling __dev_get_by_index() instead of dev_get_by_index() and holding rtnl_lock for both calls. - introduces rtnl_lock in bnx2fc_vport_create() and fcoe_vport_create() so bnx2fc_if_create() and fcoe_if_create() are called locked as they are from other places. - use __ethtool_get_settings() in bonding code Signed-off-by: Jiri Pirko v2->v3: -removed dev_ethtool_get_settings() -added ASSERT_RTNL into __ethtool_get_settings() -prb_calc_retire_blk_tmo - use __dev_get_by_index() and lock around it and __ethtool_get_settings() call v1->v2: add missing export_symbol Reviewed-by: Ben Hutchings [except FCoE bits] Acked-by: Ralf Baechle Signed-off-by: David S. Miller

ethtool: Note common alternate exit condition for interrupt coalescing

2011-08-16T23:36:15Z

Many implementations ignore the value of max_frames and do not treat usecs == 0 as special. Document this as deprecated. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller

ethtool: Explicitly state the exit condition for interrupt coalescing

2011-08-16T23:36:15Z

Also explicitly state how to disable interrupt coalescing. Remove the now-redundant text from field descriptions. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller

ethtool: Correct description of 'max_coalesced_frames' fields

2011-08-16T23:36:14Z

The current descriptions state that these fields specify 'How many packets to delay ... after a packet ...' which implies that the hardware should wait for (max_coalesced_frames + 1) completions before generating an interrupt. It is also stated that setting both this field and the corresponding 'coalesce_usecs' field to 0 is invalid. Together, this implies that the hardware must always be configured to delay a completion IRQ for at least 1 usec or 1 more completion. I believe that the addition of 1 is not intended, and David Miller confirms that the original implementation (in tg3) does not do this. Clarify the descriptions of these fields to avoid this interpretation. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller

ethtool: Specify what kind of coalescing struct ethtool_coalesce covers

2011-08-16T23:36:14Z

Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller