[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6E21E5352C11B742B20C142EB499E048018F4D@TK5EX14MBXC128.redmond.corp.microsoft.com>
Date: Sat, 12 Mar 2011 23:23:05 +0000
From: KY Srinivasan <kys@...rosoft.com>
To: Greg KH <gregkh@...e.de>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
"virtualization@...ts.osdl.org" <virtualization@...ts.osdl.org>,
"Haiyang Zhang" <haiyangz@...rosoft.com>,
Mike Sterling <Mike.Sterling@...rosoft.com>,
"Abhishek Kane (Mindtree Consulting PVT LTD)"
<v-abkane@...rosoft.com>, "Hank Janssen" <hjanssen@...rosoft.com>
Subject: RE: [PATCH 11/21] Staging: hv: Make vmbus driver a platform pci
driver
> -----Original Message-----
> From: Greg KH [mailto:gregkh@...e.de]
> Sent: Thursday, March 10, 2011 5:33 PM
> To: KY Srinivasan
> Cc: linux-kernel@...r.kernel.org; devel@...uxdriverproject.org;
> virtualization@...ts.osdl.org; Haiyang Zhang; Mike Sterling; Abhishek Kane
> (Mindtree Consulting PVT LTD); Hank Janssen
> Subject: Re: [PATCH 11/21] Staging: hv: Make vmbus driver a platform pci driver
>
> On Thu, Mar 10, 2011 at 10:28:27PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@...e.de]
> > > Sent: Thursday, March 10, 2011 5:21 PM
> > > To: KY Srinivasan
> > > Cc: linux-kernel@...r.kernel.org; devel@...uxdriverproject.org;
> > > virtualization@...ts.osdl.org; Haiyang Zhang; Mike Sterling; Abhishek Kane
> > > (Mindtree Consulting PVT LTD); Hank Janssen
> > > Subject: Re: [PATCH 11/21] Staging: hv: Make vmbus driver a platform pci
> driver
> > >
> > > On Thu, Mar 10, 2011 at 02:08:32PM -0800, K. Y. Srinivasan wrote:
> > > > Make vmbus driver a platform pci driver. This is
> > > > in preparation to cleaning up irq allocation for this
> > > > driver.
> > >
> > > The idea is nice, but the nameing is a bit confusing.
> > >
> > > We have "platform drivers" which are much different from what you are
> > > doing here, you are just creating a "normal" pci driver.
> > >
> > > Very minor comments below.
> > >
> > > >
> > > > Signed-off-by: K. Y. Srinivasan <kys@...rosoft.com>
> > > > Signed-off-by: Haiyang Zhang <haiyangz@...rosoft.com>
> > > > Signed-off-by: Mike Sterling <mike.sterling@...rosoft.com>
> > > > Signed-off-by: Abhishek Kane <v-abkane@...rosoft.com>
> > > > Signed-off-by: Hank Janssen <hjanssen@...rosoft.com>
> > > > ---
> > > > drivers/staging/hv/vmbus_drv.c | 63 +++++++++++++++++++++++--------
> -----
> > > ----
> > > > 1 files changed, 36 insertions(+), 27 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/hv/vmbus_drv.c
> b/drivers/staging/hv/vmbus_drv.c
> > > > index 8b9394a..e4855ac 100644
> > > > --- a/drivers/staging/hv/vmbus_drv.c
> > > > +++ b/drivers/staging/hv/vmbus_drv.c
> > > > @@ -43,6 +43,8 @@
> > > >
> > > > static struct device *root_dev; /* Root device */
> > > >
> > > > +struct pci_dev *hv_pci_dev;
> > > > +
> > > > /* Main vmbus driver data structure */
> > > > struct vmbus_driver_context {
> > > >
> > > > @@ -887,36 +889,24 @@ static irqreturn_t vmbus_isr(int irq, void *dev_id)
> > > > }
> > > > }
> > > >
> > > > -static struct dmi_system_id __initdata microsoft_hv_dmi_table[] = {
> > > > - {
> > > > - .ident = "Hyper-V",
> > > > - .matches = {
> > > > - DMI_MATCH(DMI_SYS_VENDOR, "Microsoft
> > > Corporation"),
> > > > - DMI_MATCH(DMI_PRODUCT_NAME, "Virtual Machine"),
> > > > - DMI_MATCH(DMI_BOARD_NAME, "Virtual Machine"),
> > > > - },
> > > > - },
> > > > - { },
> > > > -};
> > > > -MODULE_DEVICE_TABLE(dmi, microsoft_hv_dmi_table);
> > >
> > > You're sure it's safe to delete this now and just rely on the PCI ids,
> > > right? For some wierd reason I thought we needed both to catch all
> > > types of systems, but I can't remember why.
> > I have tested this; I don't think we need the dmi table.
>
> Ok, if you are sure, that's fine with me.
>
> > > How about "hv_bus" as a name, as that's what this really is. It's a
> > > "bus adapter", like USB, Firewire, and all sorts of other bus
> > > controllers.
> >
> > Sure; I will make these changes. Would you mind if I submit these name
> changes as a separate patch.
>
> How about just redo this patch? I haven't reviewed the others yet, so
> you might want to wait a day to see if I don't like any of them either
> :)
Greg, I have redone this patch as well as [PATCH 12/21]. Do you want me send you just these two
patches or the entire series including these two. Also, does this patch-set address all of architectural
issues you had noted earlier in the vmbus core. Please let us know what else needs to be done to
exit staging as far as the vmbus driver is concerned. I want get a head start before the new week
begins! Also, we have patches ready for all DPRINT cleanup. Hank is holding them off until
we finish addressing the architectural issues first.
Regards,
K. Y
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists