enic: fix an endian bug in enic_probe()

"num_vfs" is a u32 but we only use the high 16 bits and the low 16bits
are left as zero.  That isn't a problem for little endian systems but it
will break on big endian ones.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 1 Mar 2012 10:19:54 +0300

> "num_vfs" is a u32 but we only use the high 16 bits and the low 16bits
> are left as zero.  That isn't a problem for little endian systems but it
> will break on big endian ones.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

Applied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thanks Dan, David.

Just one quick comment...
pci_enable_sriov's 2nd input is declared as type int and we
were using u32 instead (for a non negative 16bit value).
With a quick check I noticed that other pci_enable_sriov callers
do something similar and may need to be taken care too:

driver    |  type used
----------+--------------
mlx4      | int
chelsio   | unsigned int
igb       | unsigned int   
igbxe     | unsigned int
emulex    | u32
vxge      | u32


Another option would have been to make all drivers use int
to match pci_enable_sriov (pci_enable_sriov->sriov_enable checks
against negative values).

(BTW, why is pci_enable_sriov prototype using int?)

Thanks
/Chris

> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Thursday, March 01, 2012 2:24 PM
> To: dan.carpenter@oracle.com
> Cc: Roopa Prabhu (roprabhu); Christian Benvenuti (benve); Neel Patel
> (neepatel); Nishank Trivedi (nistrive); netdev@vger.kernel.org;
kernel-
> janitors@vger.kernel.org
> Subject: Re: [patch] enic: fix an endian bug in enic_probe()
> 
> From: Dan Carpenter <dan.carpenter@oracle.com>
> Date: Thu, 1 Mar 2012 10:19:54 +0300
> 
> > "num_vfs" is a u32 but we only use the high 16 bits and the low
> 16bits
> > are left as zero.  That isn't a problem for little endian systems
but
> it
> > will break on big endian ones.
> >
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> 
> Applied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, Mar 01, 2012 at 07:23:45PM -0600, Christian Benvenuti (benve) wrote:
> Thanks Dan, David.
> 
> Just one quick comment...
> pci_enable_sriov's 2nd input is declared as type int and we
> were using u32 instead (for a non negative 16bit value).
> With a quick check I noticed that other pci_enable_sriov callers
> do something similar and may need to be taken care too:
> 

The problem was calling pci_read_config_word() not
pci_enable_sriov().  I did consider passing a temporary variable to
pci_read_config_word() and then storing that in num_vfs but it
seemed more complicated.

Looking at the other drivers now, I see that's how some of them do
it.  But it makes sense for them because they have the num_vfs which
the user can configure and the number from the hardware which is the
max that are supported.

Either way would fix it, but I feel that my fix is not terribly
ugly.

regards,
dan carpenter