On 1/22/15, 2:53 PM, "Rasmus Villemoes" <li...@rasmusvillemoes.dk> wrote:
>The comment explains the intention, but vid has type u16. Before the >inner shift, it is promoted to int, which has plenty of space for all >vid's bits, so nothing is dropped. Use a simple mask instead. > >Signed-off-by: Rasmus Villemoes <li...@rasmusvillemoes.dk> >--- > drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_pf.c >b/drivers/net/ethernet/intel/fm10k/fm10k_pf.c >index 275423d4f777..b1c57d0166a9 100644 >--- a/drivers/net/ethernet/intel/fm10k/fm10k_pf.c >+++ b/drivers/net/ethernet/intel/fm10k/fm10k_pf.c >@@ -335,7 +335,7 @@ static s32 fm10k_update_xc_addr_pf(struct fm10k_hw >*hw, u16 glort, > return FM10K_ERR_PARAM; > > /* drop upper 4 bits of VLAN ID */ >- vid = (vid << 4) >> 4; >+ vid &= 0x0fff; > > /* record fields */ > mac_update.mac_lower = cpu_to_le32(((u32)mac[2] << 24) | Good catch! I noticed this too and was getting a patch together to address this. The difference is that I was planning on not silently accepting an invalid VLAN ID to begin with and returning FM10K_ERR_PARAM if the VLAN was invalid, which I think is a better approach for this situation. If it's alright with you, I'll generate the patch shortly and credit you via your Reported-by. Cheers, Matthew ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
