From: Greg KH <greg@kroah.com>
To: "Nakajima, Jun" <jun.nakajima@intel.com>
Cc: "Zhao, Yu" <yu.zhao@intel.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"matthew@wil.cx" <matthew@wil.cx>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>
Subject: Re: [SR-IOV driver example 2/3] PF driver: integrate with SR-IOV core
Date: Wed, 26 Nov 2008 11:55:11 -0800 [thread overview]
Message-ID: <20081126195511.GA2386@kroah.com> (raw)
In-Reply-To: <0B53E02A2965CE4F9ADB38B34501A3A167E8BD7F@orsmsx505.amr.corp.intel.com>
On Wed, Nov 26, 2008 at 11:27:10AM -0800, Nakajima, Jun wrote:
> On 11/26/2008 8:58:59 AM, Greg KH wrote:
> > On Wed, Nov 26, 2008 at 10:21:56PM +0800, Yu Zhao wrote:
> > > This patch integrates the IGB driver with the SR-IOV core. It shows
> > > how the SR-IOV API is used to support the capability. Obviously
> > > people does not need to put much effort to integrate the PF driver
> > > with SR-IOV core. All SR-IOV standard stuff are handled by SR-IOV
> > > core and PF driver once it gets the necessary information (i.e.
> > > number of Virtual
> > > Functions) from the callback function.
> > >
> > > ---
> > > drivers/net/igb/igb_main.c | 30 ++++++++++++++++++++++++++++++
> > > 1 files changed, 30 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
> > > index bc063d4..b8c7dc6 100644
> > > --- a/drivers/net/igb/igb_main.c
> > > +++ b/drivers/net/igb/igb_main.c
> > > @@ -139,6 +139,7 @@ void igb_set_mc_list_pools(struct igb_adapter *,
> > > struct e1000_hw *, int, u16); static int igb_vmm_control(struct
> > > igb_adapter *, bool); static int igb_set_vf_mac(struct net_device
> > > *, int, u8*); static void igb_mbox_handler(struct igb_adapter *);
> > > +static int igb_virtual(struct pci_dev *, int);
> > > #endif
> > >
> > > static int igb_suspend(struct pci_dev *, pm_message_t); @@ -184,6
> > > +185,9 @@ static struct pci_driver igb_driver = { #endif
> > > .shutdown = igb_shutdown,
> > > .err_handler = &igb_err_handler,
> > > +#ifdef CONFIG_PCI_IOV
> > > + .virtual = igb_virtual
> > > +#endif
> >
> > #ifdef should not be needed, right?
> >
>
> Good point. I think this is because the driver is expected to build on
> older kernels also,
That should not be an issue for patches that are being submitted, right?
And if this is the case, shouldn't it be called out in the changelog
entry?
> but the problem is that the driver (and probably others) is broken
> unless the kernel is built with CONFIG_PCI_IOV because of the
> following hunk, for example.
>
> However, we don't want to use #ifdef for the (*virtual) field in the
> header. One option would be to define a constant like the following
> along with those changes.
> #define PCI_DEV_IOV
>
> Any better idea?
Just always declare it in your driver, which will be added _after_ this
field gets added to the kernel tree as well. It's not a big deal, just
an ordering of patches issue.
Because remember, don't add #ifdefs to drivers, they should not be
needed at all.
thanks,
greg k-h
next prev parent reply other threads:[~2008-11-26 19:57 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-21 18:36 [PATCH 0/13 v7] PCI: Linux kernel SR-IOV support Yu Zhao
2008-11-21 18:38 ` [PATCH 1/13 v7] PCI: enhance pci_ari_enabled() Yu Zhao
2008-11-21 18:38 ` [PATCH 2/13 v7] PCI: remove unnecessary arg of pci_update_resource() Yu Zhao
2008-11-21 18:39 ` [PATCH 3/13 v7] PCI: define PCI resource names in an 'enum' Yu Zhao
2008-11-21 18:40 ` [PATCH 4/13 v7] PCI: remove unnecessary condition check in pci_restore_bars() Yu Zhao
2008-11-21 18:40 ` [PATCH 5/13 v7] PCI: export __pci_read_base() Yu Zhao
2008-11-21 18:41 ` [PATCH 6/13 v7] PCI: make pci_alloc_child_bus() be able to handle NULL bridge Yu Zhao
2008-11-21 18:41 ` [PATCH 7/13 v7] PCI: add a new function to map BAR offset Yu Zhao
2008-11-21 18:41 ` [PATCH 8/13 v7] PCI: cleanup pci_bus_add_devices() Yu Zhao
2008-11-21 18:42 ` [PATCH 9/13 v7] PCI: split a new function from pci_bus_add_devices() Yu Zhao
2008-11-21 18:42 ` [PATCH 10/13 v7] PCI: support the SR-IOV capability Yu Zhao
2008-11-21 18:43 ` [PATCH 11/13 v7] PCI: reserve bus range for SR-IOV device Yu Zhao
2008-11-21 18:43 ` [PATCH 12/13 v7] PCI: document the SR-IOV sysfs entries Yu Zhao
2008-11-21 18:44 ` [PATCH 13/13 v7] PCI: document for SR-IOV user and developer Yu Zhao
2008-11-21 20:57 ` [PATCH 0/13 v7] PCI: Linux kernel SR-IOV support Greg KH
2008-11-22 7:03 ` Zhao, Yu
2008-11-26 14:03 ` [SR-IOV driver example 0/3] introduction Yu Zhao
2008-11-26 14:11 ` [SR-IOV driver example 1/3] PF driver: allocate hardware specific resource Yu Zhao
2008-11-26 14:21 ` [SR-IOV driver example 2/3] PF driver: integrate with SR-IOV core Yu Zhao
2008-11-26 16:58 ` Greg KH
2008-11-26 17:54 ` Chris Wright
2008-12-01 16:46 ` Yu Zhao
2008-11-26 19:27 ` Nakajima, Jun
2008-11-26 19:55 ` Greg KH [this message]
2008-12-01 16:44 ` Yu Zhao
2008-11-26 14:40 ` [SR-IOV driver example 3/3] VF driver tar ball Yu Zhao
2008-11-26 17:00 ` Greg KH
2008-11-26 16:59 ` [SR-IOV driver example 0/3] introduction Greg KH
2008-12-01 16:54 ` Yu Zhao
2008-11-26 20:14 ` Jeff Garzik
2008-12-01 16:39 ` Yu Zhao
2008-12-02 9:27 ` [SR-IOV driver example 0/3 resend] introduction Yu Zhao
2008-12-02 9:40 ` [SR-IOV driver example 1/3 resend] PF driver: hardware specific operations Yu Zhao
2008-12-02 9:42 ` [SR-IOV driver example 2/3 resend] PF driver: integrate with SR-IOV core Yu Zhao
2008-12-03 3:12 ` [SR-IOV driver example 0/3 resend] introduction Jeff Kirsher
2008-12-16 23:23 ` [PATCH 0/13 v7] PCI: Linux kernel SR-IOV support Jesse Barnes
2008-12-17 2:37 ` Jike Song
2008-12-17 6:06 ` Greg KH
2008-12-17 7:07 ` Zhao, Yu
2008-12-17 7:21 ` Greg KH
2008-12-17 16:44 ` Rose, Gregory V
2008-12-17 17:51 ` Greg KH
2008-12-17 18:51 ` Jesse Barnes
2008-12-17 19:05 ` Rose, Gregory V
2008-12-17 19:34 ` Jeremy Fitzhardinge
2008-12-17 19:42 ` Rose, Gregory V
2008-12-17 19:42 ` Jesse Barnes
2008-12-17 19:51 ` Greg KH
2008-12-17 20:07 ` Jesse Barnes
2008-12-18 2:39 ` Zhao, Yu
2008-12-18 22:42 ` Rose, Gregory V
2008-12-17 11:42 ` Fischer, Anna
2008-12-17 18:59 ` Jesse Barnes
2008-12-18 2:13 ` Zhao, Yu
2008-12-18 6:37 ` Fischer, Anna
2008-12-17 14:15 ` Matthew Wilcox
2008-12-17 17:27 ` Jesse Barnes
2008-12-18 2:26 ` Zhao, Yu
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=20081126195511.GA2386@kroah.com \
--to=greg@kroah.com \
--cc=jun.nakajima@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=virtualization@lists.linux-foundation.org \
--cc=xen-devel@lists.xensource.com \
--cc=yu.zhao@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox