All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: "Christian Benvenuti (benve)" <benve@cisco.com>
Cc: David Miller <davem@davemloft.net>,
	"Roopa Prabhu (roprabhu)" <roprabhu@cisco.com>,
	"Neel Patel (neepatel)" <neepatel@cisco.com>,
	"Nishank Trivedi (nistrive)" <nistrive@cisco.com>,
	netdev@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [patch] enic: fix an endian bug in enic_probe()
Date: Fri, 02 Mar 2012 06:06:53 +0000	[thread overview]
Message-ID: <20120302060653.GU1003@mwanda> (raw)
In-Reply-To: <184D23435BECB444AB6B9D4630C8EC8303853051@XMB-RCD-303.cisco.com>

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter@oracle.com>
To: "Christian Benvenuti (benve)" <benve@cisco.com>
Cc: David Miller <davem@davemloft.net>,
	"Roopa Prabhu (roprabhu)" <roprabhu@cisco.com>,
	"Neel Patel (neepatel)" <neepatel@cisco.com>,
	"Nishank Trivedi (nistrive)" <nistrive@cisco.com>,
	netdev@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [patch] enic: fix an endian bug in enic_probe()
Date: Fri, 2 Mar 2012 09:06:53 +0300	[thread overview]
Message-ID: <20120302060653.GU1003@mwanda> (raw)
In-Reply-To: <184D23435BECB444AB6B9D4630C8EC8303853051@XMB-RCD-303.cisco.com>

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-03-02  6:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-01  7:19 [patch] enic: fix an endian bug in enic_probe() Dan Carpenter
2012-03-01  7:19 ` Dan Carpenter
2012-03-01 22:24 ` David Miller
2012-03-01 22:24   ` David Miller
2012-03-02  1:23   ` Christian Benvenuti (benve)
2012-03-02  1:23     ` Christian Benvenuti (benve)
2012-03-02  6:06     ` Dan Carpenter [this message]
2012-03-02  6:06       ` Dan Carpenter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120302060653.GU1003@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=benve@cisco.com \
    --cc=davem@davemloft.net \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=neepatel@cisco.com \
    --cc=netdev@vger.kernel.org \
    --cc=nistrive@cisco.com \
    --cc=roprabhu@cisco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.