* RE: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
From: KY Srinivasan @ 2011-05-02 19:48 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Greg KH, gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <20110501205315.GC1017@infradead.org>
> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@infradead.org]
> Sent: Sunday, May 01, 2011 4:53 PM
> To: KY Srinivasan
> Cc: Greg KH; gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Sun, May 01, 2011 at 06:08:37PM +0000, KY Srinivasan wrote:
> > Could you elaborate on the problems/issues when the block driver registers for
> the
> > IDE majors. On the Qemu side, we have a mechanism to disable the emulation
> when
> > PV drivers load. I don't think there is an equivalent mechanism on the Windows
> side.
> > So, as far as I know, registering for the IDE majors is the only way to also
> prevent native
> > drivers in Linux from taking control of the emulated device.
>
> What qemu are you talking about for the qemu side? Upstream qemu
> doesn't have any way to provide the same image as multiple devices,
> nevermind dynamically unplugging bits in that case. Nor does it support
> the hyperv devices.
I am talking about the qemu that was (is) shipping with Xen. In Hyper-V,
the block devices configured as IDE devices for the guest will be taken over
by the native drivers if the PV drivers don't load first and take over the IDE majors.
If you want to have the root device be managed by the PV drivers, this appears to be
the only way to ensure that native IDE drivers don't take over the root device. Granted,
this depends on ensuring the PV drivers load first, but I don't know if there is another way
to achieve this.
>
> When you steal majors you rely on:
>
> a) loading earlier than the driver you steal them from
> b) the driver not simple using other numbers
> c) if it doesn't preventing it from working at all, also for
> devices you don't "replace" with your PV devices.
These are exactly the issues that had to be solved to have the PV
drivers manage the root device.
> d) that the guest actually uses the minors your claim, e.g. any
> current linux distribution uses libata anyway, so you old IDE
> major claim wouldn't do anything. Nor would claiming sd majors
> as the low-level libata driver would still drive the hardware
> even if SD doesn't bind to it.
By setting up appropriate modprobe rules, this can be addressed.
>
> You really must never present the same device as two emulated devices
> instead of doing such hacks.
Agreed; I am not sure what the right solution for Hyper-V is other than
(a) preventing the native IDE drivers from loading and (b) having
the right modprobe rules to ensure libata would not present these
same devices to the guest as scsi devices.
Regards,
K. Y
^ permalink raw reply
* Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
From: Christoph Hellwig @ 2011-05-01 20:53 UTC (permalink / raw)
To: KY Srinivasan
Cc: Greg KH, gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481DF2A0@TK5EX14MBXC124.redmond.corp.microsoft.com>
On Sun, May 01, 2011 at 06:08:37PM +0000, KY Srinivasan wrote:
> Could you elaborate on the problems/issues when the block driver registers for the
> IDE majors. On the Qemu side, we have a mechanism to disable the emulation when
> PV drivers load. I don't think there is an equivalent mechanism on the Windows side.
> So, as far as I know, registering for the IDE majors is the only way to also prevent native
> drivers in Linux from taking control of the emulated device.
What qemu are you talking about for the qemu side? Upstream qemu
doesn't have any way to provide the same image as multiple devices,
nevermind dynamically unplugging bits in that case. Nor does it support
the hyperv devices.
When you steal majors you rely on:
a) loading earlier than the driver you steal them from
b) the driver not simple using other numbers
c) if it doesn't preventing it from working at all, also for
devices you don't "replace" with your PV devices.
d) that the guest actually uses the minors your claim, e.g. any
current linux distribution uses libata anyway, so you old IDE
major claim wouldn't do anything. Nor would claiming sd majors
as the low-level libata driver would still drive the hardware
even if SD doesn't bind to it.
You really must never present the same device as two emulated devices
instead of doing such hacks.
^ permalink raw reply
* Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
From: Christoph Hellwig @ 2011-05-01 20:47 UTC (permalink / raw)
To: KY Srinivasan
Cc: Greg KH, Christoph Hellwig, gregkh@suse.de,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
virtualization@lists.osdl.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481DF2C9@TK5EX14MBXC124.redmond.corp.microsoft.com>
On Sun, May 01, 2011 at 06:56:58PM +0000, KY Srinivasan wrote:
> > Yeah, it seems to me that no matter how the user specifies the disk
> > "type" for the guest configuration, we should use the same Linux driver,
> > with the same naming scheme for both ways.
> >
> > As Christoph points out, it's just a matter of hooking the device up to
> > the scsi subsystem. We do that today for ide, usb, scsi, and loads of
> > other types of devices all with the common goal of making it easier for
> > userspace to handle the devices in a standard manner.
>
> This is not what is being done in Xen and KVM - they both have a PV front-end
> block drivers that is not managed by the scsi stack. The Hyper-V block driver is
> equivalent to what we have in Xen and KVM in this respect.
Xen also has a PV SCSI driver, although that isn't used very much.
For virtio we think it was a mistake to not speak SCSI these days,
and ponder introducing a virtio-scsi to replace virtio-blk.
But that's not the point here at all. The point is that blockvsc
speaks a SCSI protocol over the wire, so it should be implemented
as a SCSI LLDD unless you have a good reason not to do it. This
is especially important to get advanced features like block level
cache flush and FUA support, device topology, discard support, for
free. Cache flush and FUA are good example for something that blkvsc
currently gets wrong, btw.
^ permalink raw reply
* RE: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
From: KY Srinivasan @ 2011-05-01 18:56 UTC (permalink / raw)
To: Greg KH
Cc: Christoph Hellwig, devel@linuxdriverproject.org, gregkh@suse.de,
linux-kernel@vger.kernel.org, virtualization@lists.osdl.org
In-Reply-To: <20110501154751.GA14040@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Sunday, May 01, 2011 11:48 AM
> To: KY Srinivasan
> Cc: Christoph Hellwig; gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Sun, May 01, 2011 at 11:39:21AM -0400, Christoph Hellwig wrote:
> > On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
> > > On the host-side, as part of configuring a guest you can specify block devices
> > > as being under an IDE controller or under a
> > > SCSI controller. Those are the only options you have. Devices configured
> under
> > > the IDE controller cannot be seen in the guest under the emulated SCSI front-
> end which is
> > > the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi
> front-end,
> > > the devices enumerated will not include block devices configured under the
> IDE
> > > controller. So, it is not clear to me how I can do what you are proposing given
> the
> > > restrictions imposed by the host.
> >
> > Just because a device is not reported by REPORT_LUNS doesn't mean you
> > can't talk to it using a SCSI LLDD. We have SCSI transports with all
> > kinds of strange ways to discover devices. Using scsi_add_device you
> > can add LUNs found by your own discovery methods, and use all the
> > existing scsi command handling.
>
> Yeah, it seems to me that no matter how the user specifies the disk
> "type" for the guest configuration, we should use the same Linux driver,
> with the same naming scheme for both ways.
>
> As Christoph points out, it's just a matter of hooking the device up to
> the scsi subsystem. We do that today for ide, usb, scsi, and loads of
> other types of devices all with the common goal of making it easier for
> userspace to handle the devices in a standard manner.
This is not what is being done in Xen and KVM - they both have a PV front-end
block drivers that is not managed by the scsi stack. The Hyper-V block driver is
equivalent to what we have in Xen and KVM in this respect.
Regards,
K. Y
^ permalink raw reply
* RE: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
From: KY Srinivasan @ 2011-05-01 18:08 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Greg KH, gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <20110501160721.GA8195@infradead.org>
> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@infradead.org]
> Sent: Sunday, May 01, 2011 12:07 PM
> To: KY Srinivasan
> Cc: Christoph Hellwig; Greg KH; gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Sun, May 01, 2011 at 03:46:23PM +0000, KY Srinivasan wrote:
> > What is the issue here? This is no different than what is done in other
> > Virtualization platforms. For instance, the Xen blkfront driver is no
> > different - if you specify the block device to be presented to the guest
> > as an ide device, it will register for the appropriate ide major number.
>
> No, it won't - at least not in mainline just because it's so buggy.
> If distros keep that crap around I can only recommed you to not use
> them.
Christoph,
Could you elaborate on the problems/issues when the block driver registers for the
IDE majors. On the Qemu side, we have a mechanism to disable the emulation when
PV drivers load. I don't think there is an equivalent mechanism on the Windows side.
So, as far as I know, registering for the IDE majors is the only way to also prevent native
drivers in Linux from taking control of the emulated device.
Regards,
K. Y
^ permalink raw reply
* Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
From: Christoph Hellwig @ 2011-05-01 16:07 UTC (permalink / raw)
To: KY Srinivasan
Cc: Christoph Hellwig, Greg KH, gregkh@suse.de,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
virtualization@lists.osdl.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481DF253@TK5EX14MBXC124.redmond.corp.microsoft.com>
On Sun, May 01, 2011 at 03:46:23PM +0000, KY Srinivasan wrote:
> What is the issue here? This is no different than what is done in other
> Virtualization platforms. For instance, the Xen blkfront driver is no
> different - if you specify the block device to be presented to the guest
> as an ide device, it will register for the appropriate ide major number.
No, it won't - at least not in mainline just because it's so buggy.
If distros keep that crap around I can only recommed you to not use
them.
^ permalink raw reply
* Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
From: Greg KH @ 2011-05-01 15:47 UTC (permalink / raw)
To: KY Srinivasan
Cc: Christoph Hellwig, gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <20110501153920.GA15210@infradead.org>
On Sun, May 01, 2011 at 11:39:21AM -0400, Christoph Hellwig wrote:
> On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
> > On the host-side, as part of configuring a guest you can specify block devices
> > as being under an IDE controller or under a
> > SCSI controller. Those are the only options you have. Devices configured under
> > the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
> > the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
> > the devices enumerated will not include block devices configured under the IDE
> > controller. So, it is not clear to me how I can do what you are proposing given the
> > restrictions imposed by the host.
>
> Just because a device is not reported by REPORT_LUNS doesn't mean you
> can't talk to it using a SCSI LLDD. We have SCSI transports with all
> kinds of strange ways to discover devices. Using scsi_add_device you
> can add LUNs found by your own discovery methods, and use all the
> existing scsi command handling.
Yeah, it seems to me that no matter how the user specifies the disk
"type" for the guest configuration, we should use the same Linux driver,
with the same naming scheme for both ways.
As Christoph points out, it's just a matter of hooking the device up to
the scsi subsystem. We do that today for ide, usb, scsi, and loads of
other types of devices all with the common goal of making it easier for
userspace to handle the devices in a standard manner.
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
From: KY Srinivasan @ 2011-05-01 15:46 UTC (permalink / raw)
To: Christoph Hellwig, Greg KH
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <20110501154041.GB15210@infradead.org>
> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@infradead.org]
> Sent: Sunday, May 01, 2011 11:41 AM
> To: Greg KH
> Cc: KY Srinivasan; Christoph Hellwig; gregkh@suse.de; linux-
> kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Fri, Apr 29, 2011 at 09:40:25AM -0700, Greg KH wrote:
> > Are you sure the libata core can't see this ide controller and connect
> > to it? That way you would use the scsi system if you do that and you
> > would need a much smaller ide driver, perhaps being able to merge it
> > with your scsi driver.
> >
> > We really don't want to write new IDE drivers anymore that don't use
> > libata.
>
> The blkvsc driver isn't an IDE driver, although it currently claims
> the old IDE drivers major numbers, which is a no-no and can't work
> in most usual setups.
What is the issue here? This is no different than what is done in other
Virtualization platforms. For instance, the Xen blkfront driver is no
different - if you specify the block device to be presented to the guest
as an ide device, it will register for the appropriate ide major number.
Regards,
K. Y
> I'm pretty sure I already complained about
> this in a previous review round.
^ permalink raw reply
* Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
From: Christoph Hellwig @ 2011-05-01 15:40 UTC (permalink / raw)
To: Greg KH
Cc: KY Srinivasan, Christoph Hellwig, gregkh@suse.de,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
virtualization@lists.osdl.org
In-Reply-To: <20110429164025.GA7698@kroah.com>
On Fri, Apr 29, 2011 at 09:40:25AM -0700, Greg KH wrote:
> Are you sure the libata core can't see this ide controller and connect
> to it? That way you would use the scsi system if you do that and you
> would need a much smaller ide driver, perhaps being able to merge it
> with your scsi driver.
>
> We really don't want to write new IDE drivers anymore that don't use
> libata.
The blkvsc driver isn't an IDE driver, although it currently claims
the old IDE drivers major numbers, which is a no-no and can't work
in most usual setups. I'm pretty sure I already complained about
this in a previous review round.
^ permalink raw reply
* Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
From: Christoph Hellwig @ 2011-05-01 15:39 UTC (permalink / raw)
To: KY Srinivasan
Cc: Christoph Hellwig, Greg KH, gregkh@suse.de,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
virtualization@lists.osdl.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481DD676@TK5EX14MBXC124.redmond.corp.microsoft.com>
On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
> On the host-side, as part of configuring a guest you can specify block devices
> as being under an IDE controller or under a
> SCSI controller. Those are the only options you have. Devices configured under
> the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
> the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
> the devices enumerated will not include block devices configured under the IDE
> controller. So, it is not clear to me how I can do what you are proposing given the
> restrictions imposed by the host.
Just because a device is not reported by REPORT_LUNS doesn't mean you
can't talk to it using a SCSI LLDD. We have SCSI transports with all
kinds of strange ways to discover devices. Using scsi_add_device you
can add LUNs found by your own discovery methods, and use all the
existing scsi command handling.
^ permalink raw reply
* RE: [PATCH 08/25] Staging: hv: vmbus_driver cannot be unloaded; cleanup accordingly
From: KY Srinivasan @ 2011-04-29 23:22 UTC (permalink / raw)
To: Greg KH
Cc: Greg KH, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
Haiyang Zhang, Abhishek Kane (Mindtree Consulting PVT LTD)
In-Reply-To: <20110429231421.GA24396@suse.de>
> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de]
> Sent: Friday, April 29, 2011 7:14 PM
> To: KY Srinivasan
> Cc: Greg KH; linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org; Haiyang Zhang; Abhishek Kane (Mindtree Consulting
> PVT LTD)
> Subject: Re: [PATCH 08/25] Staging: hv: vmbus_driver cannot be unloaded;
> cleanup accordingly
>
> On Fri, Apr 29, 2011 at 10:02:43PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@suse.de]
> > > Sent: Friday, April 29, 2011 11:11 AM
> > > To: KY Srinivasan
> > > Cc: Greg KH; linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > > virtualization@lists.osdl.org; Haiyang Zhang; Abhishek Kane (Mindtree
> Consulting
> > > PVT LTD)
> > > Subject: Re: [PATCH 08/25] Staging: hv: vmbus_driver cannot be unloaded;
> > > cleanup accordingly
> > >
> > >
> > > Just resend it with some more comments as I explained, and the rest, and
> > > I'll queue them up when I get caught up on my patch queue (I only have
> > > 381 to get through, the end is near!)
> >
> > Done; I just resent the remaining patches with comments and corrections
> > you had recommended. With regards to asking for a review, should I wait until
> > all these patches are applied?
>
> Yes, unless you know of any other changes you want to make to the vmbus
> core.
Thanks. Currently, I am not planning to make any changes to the vmbus core.
Regards,
K. Y
^ permalink raw reply
* Re: [PATCH 08/25] Staging: hv: vmbus_driver cannot be unloaded; cleanup accordingly
From: Greg KH @ 2011-04-29 23:14 UTC (permalink / raw)
To: KY Srinivasan
Cc: Greg KH, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
Haiyang Zhang, Abhishek Kane (Mindtree Consulting PVT LTD)
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481DD842@TK5EX14MBXC124.redmond.corp.microsoft.com>
On Fri, Apr 29, 2011 at 10:02:43PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@suse.de]
> > Sent: Friday, April 29, 2011 11:11 AM
> > To: KY Srinivasan
> > Cc: Greg KH; linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > virtualization@lists.osdl.org; Haiyang Zhang; Abhishek Kane (Mindtree Consulting
> > PVT LTD)
> > Subject: Re: [PATCH 08/25] Staging: hv: vmbus_driver cannot be unloaded;
> > cleanup accordingly
> >
> >
> > Just resend it with some more comments as I explained, and the rest, and
> > I'll queue them up when I get caught up on my patch queue (I only have
> > 381 to get through, the end is near!)
>
> Done; I just resent the remaining patches with comments and corrections
> you had recommended. With regards to asking for a review, should I wait until
> all these patches are applied?
Yes, unless you know of any other changes you want to make to the vmbus
core.
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH 08/25] Staging: hv: vmbus_driver cannot be unloaded; cleanup accordingly
From: KY Srinivasan @ 2011-04-29 22:02 UTC (permalink / raw)
To: Greg KH
Cc: Greg KH, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
Haiyang Zhang, Abhishek Kane (Mindtree Consulting PVT LTD)
In-Reply-To: <20110429151052.GC12142@suse.de>
> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de]
> Sent: Friday, April 29, 2011 11:11 AM
> To: KY Srinivasan
> Cc: Greg KH; linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org; Haiyang Zhang; Abhishek Kane (Mindtree Consulting
> PVT LTD)
> Subject: Re: [PATCH 08/25] Staging: hv: vmbus_driver cannot be unloaded;
> cleanup accordingly
>
>
> Just resend it with some more comments as I explained, and the rest, and
> I'll queue them up when I get caught up on my patch queue (I only have
> 381 to get through, the end is near!)
Done; I just resent the remaining patches with comments and corrections
you had recommended. With regards to asking for a review, should I wait until
all these patches are applied?
Regards,
K. Y
^ permalink raw reply
* [PATCH 18/18] Staging: hv: Get rid of an unused variable from struct hv_driver
From: K. Y. Srinivasan @ 2011-04-29 20:45 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization; +Cc: Haiyang Zhang, Abhishek Kane
In-Reply-To: <1304109916-24874-1-git-send-email-kys@microsoft.com>
The name field is unused in struct hv_driver. Get rid of it.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Abhishek Kane <v-abkane@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
---
drivers/staging/hv/vmbus_api.h | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/hv/vmbus_api.h b/drivers/staging/hv/vmbus_api.h
index 8e6c107..50fbeb5 100644
--- a/drivers/staging/hv/vmbus_api.h
+++ b/drivers/staging/hv/vmbus_api.h
@@ -108,8 +108,6 @@ struct hv_driver {
/* Base device object */
struct hv_device {
- char name[64];
-
/* the device type id of this device */
struct hv_guid dev_type;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 17/18] Staging: hv: VMBUS is a acpi enumerated device; get irq value from bios
From: K. Y. Srinivasan @ 2011-04-29 20:45 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization; +Cc: Haiyang Zhang, Abhishek Kane
In-Reply-To: <1304109916-24874-1-git-send-email-kys@microsoft.com>
On some Windows hosts, the Linux PCI sub-system is not
allocating irq resources to the
vmbus driver. It looks like VMBUS is an ACPI enumerated device.
Retrieve the irq information from DSDT.
Currently we use this bios specified irq, if the PCI
sub-system fails to allocate the irq.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Abhishek Kane <v-abkane@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
---
drivers/staging/hv/vmbus_drv.c | 101 +++++++++++++++++++++++++++++++++++++++-
1 files changed, 100 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/hv/vmbus_drv.c b/drivers/staging/hv/vmbus_drv.c
index 6bf5365..5dcd87a 100644
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -17,8 +17,8 @@
* Authors:
* Haiyang Zhang <haiyangz@microsoft.com>
* Hank Janssen <hjanssen@microsoft.com>
+ * K. Y. Srinivasan <kys@microsoft.com>
*
- * 3/9/2011: K. Y. Srinivasan - Significant restructuring and cleanup
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -31,6 +31,8 @@
#include <linux/pci.h>
#include <linux/dmi.h>
#include <linux/slab.h>
+#include <linux/acpi.h>
+#include <acpi/acpi_bus.h>
#include <linux/completion.h>
#include "version_info.h"
#include "hv_api.h"
@@ -52,6 +54,7 @@ EXPORT_SYMBOL(vmbus_loglevel);
static int pci_probe_error;
static struct completion probe_event;
+static int irq;
static void get_channel_info(struct hv_device *device,
struct hv_device_info *info)
@@ -712,6 +715,74 @@ void vmbus_child_device_unregister(struct hv_device *device_obj)
}
+/*
+ * VMBUS is an acpi enumerated device. Get the the IRQ information
+ * from DSDT.
+ */
+
+static acpi_status vmbus_walk_resources(struct acpi_resource *res, void *irq)
+{
+
+ if (res->type == ACPI_RESOURCE_TYPE_IRQ) {
+ struct acpi_resource_irq *irqp;
+ irqp = &res->data.irq;
+
+ *((unsigned int *)irq) = irqp->interrupts[0];
+ }
+
+ return AE_OK;
+}
+
+static int vmbus_acpi_add(struct acpi_device *device)
+{
+ acpi_status result;
+
+ result =
+ acpi_walk_resources(device->handle, METHOD_NAME__CRS,
+ vmbus_walk_resources, &irq);
+
+ if (ACPI_FAILURE(result)) {
+ complete(&probe_event);
+ return -ENODEV;
+ }
+ complete(&probe_event);
+ return 0;
+}
+
+static const struct acpi_device_id vmbus_acpi_device_ids[] = {
+ {"VMBUS", 0},
+ {"", 0},
+};
+MODULE_DEVICE_TABLE(acpi, vmbus_acpi_device_ids);
+
+static struct acpi_driver vmbus_acpi_driver = {
+ .name = "vmbus",
+ .ids = vmbus_acpi_device_ids,
+ .ops = {
+ .add = vmbus_acpi_add,
+ },
+};
+
+static int vmbus_acpi_init(void)
+{
+ int result;
+
+
+ result = acpi_bus_register_driver(&vmbus_acpi_driver);
+ if (result < 0)
+ return result;
+
+ return 0;
+}
+
+static void vmbus_acpi_exit(void)
+{
+ acpi_bus_unregister_driver(&vmbus_acpi_driver);
+
+ return;
+}
+
+
static int __devinit hv_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
@@ -721,7 +792,16 @@ static int __devinit hv_pci_probe(struct pci_dev *pdev,
if (pci_probe_error)
goto probe_cleanup;
+ /*
+ * If the PCI sub-sytem did not assign us an
+ * irq, use the bios provided one.
+ */
+
+ if (pdev->irq == 0)
+ pdev->irq = irq;
+
pci_probe_error = vmbus_bus_init(pdev);
+
if (pci_probe_error)
pci_disable_device(pdev);
@@ -751,6 +831,25 @@ static struct pci_driver hv_bus_driver = {
static int __init hv_pci_init(void)
{
int ret;
+
+ init_completion(&probe_event);
+
+ /*
+ * Get irq resources first.
+ */
+
+ ret = vmbus_acpi_init();
+ if (ret)
+ return ret;
+
+ wait_for_completion(&probe_event);
+
+ if (irq <= 0) {
+ vmbus_acpi_exit();
+ return -ENODEV;
+ }
+
+ vmbus_acpi_exit();
init_completion(&probe_event);
ret = pci_register_driver(&hv_bus_driver);
if (ret)
--
1.7.4.1
^ permalink raw reply related
* [PATCH 16/18] Staging: hv: Use the shutdown() function in struct hv_driver
From: K. Y. Srinivasan @ 2011-04-29 20:45 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization
Cc: K. Y. Srinivasan, Haiyang Zhang, Abhishek Kane, Hank Janssen
In-Reply-To: <1304109916-24874-1-git-send-email-kys@microsoft.com>
Use the newly introduced shutdown() function.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Abhishek Kane <v-abkane@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
---
drivers/staging/hv/blkvsc_drv.c | 6 +++---
drivers/staging/hv/vmbus_drv.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/hv/blkvsc_drv.c b/drivers/staging/hv/blkvsc_drv.c
index 80f7c0e..db44cf6 100644
--- a/drivers/staging/hv/blkvsc_drv.c
+++ b/drivers/staging/hv/blkvsc_drv.c
@@ -585,9 +585,9 @@ static int blkvsc_remove(struct hv_device *dev)
}
-static void blkvsc_shutdown(struct device *device)
+static void blkvsc_shutdown(struct hv_device *dev)
{
- struct block_device_context *blkdev = dev_get_drvdata(device);
+ struct block_device_context *blkdev = dev_get_drvdata(&dev->device);
unsigned long flags;
if (!blkdev)
@@ -883,7 +883,7 @@ static int blkvsc_drv_init(void)
drv->probe = blkvsc_probe;
drv->remove = blkvsc_remove;
- drv->driver.shutdown = blkvsc_shutdown;
+ drv->shutdown = blkvsc_shutdown;
/* The driver belongs to vmbus */
ret = vmbus_child_driver_register(&drv->driver);
diff --git a/drivers/staging/hv/vmbus_drv.c b/drivers/staging/hv/vmbus_drv.c
index b1e6cc4..6bf5365 100644
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -367,6 +367,7 @@ static int vmbus_remove(struct device *child_device)
static void vmbus_shutdown(struct device *child_device)
{
struct hv_driver *drv;
+ struct hv_device *dev = device_to_hv_device(child_device);
/* The device may not be attached yet */
@@ -375,9 +376,8 @@ static void vmbus_shutdown(struct device *child_device)
drv = drv_to_hv_drv(child_device->driver);
- /* Let the specific open-source driver handles the removal if it can */
- if (drv->driver.shutdown)
- drv->driver.shutdown(child_device);
+ if (drv->shutdown)
+ drv->shutdown(dev);
return;
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH 15/18] Staging: hv: Add shutdown() function to struct hv_driver
From: K. Y. Srinivasan @ 2011-04-29 20:45 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization; +Cc: Haiyang Zhang, Abhishek Kane
In-Reply-To: <1304109916-24874-1-git-send-email-kys@microsoft.com>
Add shutdown() function to struct hv_driver.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Abhishek Kane <v-abkane@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
---
drivers/staging/hv/vmbus_api.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/hv/vmbus_api.h b/drivers/staging/hv/vmbus_api.h
index 3ae0c46..8e6c107 100644
--- a/drivers/staging/hv/vmbus_api.h
+++ b/drivers/staging/hv/vmbus_api.h
@@ -102,6 +102,7 @@ struct hv_driver {
int (*probe)(struct hv_device *);
int (*remove)(struct hv_device *);
+ void (*shutdown)(struct hv_device *);
};
--
1.7.4.1
^ permalink raw reply related
* [PATCH 14/18] Staging: hv: Use the remove() function in struct hv_driver
From: K. Y. Srinivasan @ 2011-04-29 20:45 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization; +Cc: Haiyang Zhang, Abhishek Kane
In-Reply-To: <1304109916-24874-1-git-send-email-kys@microsoft.com>
Use the newly introduced remove() function in struct hv_driver.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Abhishek Kane <v-abkane@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
---
drivers/staging/hv/blkvsc_drv.c | 11 +++++------
drivers/staging/hv/hv_mouse.c | 11 +++++------
drivers/staging/hv/netvsc_drv.c | 13 ++++++-------
drivers/staging/hv/storvsc_drv.c | 13 ++++++-------
drivers/staging/hv/vmbus_drv.c | 9 +++------
5 files changed, 25 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/hv/blkvsc_drv.c b/drivers/staging/hv/blkvsc_drv.c
index 20b9a53..80f7c0e 100644
--- a/drivers/staging/hv/blkvsc_drv.c
+++ b/drivers/staging/hv/blkvsc_drv.c
@@ -537,19 +537,18 @@ out:
/*
* blkvsc_remove() - Callback when our device is removed
*/
-static int blkvsc_remove(struct device *device)
+static int blkvsc_remove(struct hv_device *dev)
{
struct storvsc_driver_object *storvsc_drv_obj =
- drv_to_stordrv(device->driver);
- struct hv_device *device_obj = device_to_hv_device(device);
- struct block_device_context *blkdev = dev_get_drvdata(device);
+ drv_to_stordrv(dev->device.driver);
+ struct block_device_context *blkdev = dev_get_drvdata(&dev->device);
unsigned long flags;
/*
* Call to the vsc driver to let it know that the device is being
* removed
*/
- storvsc_drv_obj->base.dev_rm(device_obj);
+ storvsc_drv_obj->base.dev_rm(dev);
/* Get to a known state */
spin_lock_irqsave(&blkdev->lock, flags);
@@ -883,7 +882,7 @@ static int blkvsc_drv_init(void)
drv->driver.name = storvsc_drv_obj->base.name;
drv->probe = blkvsc_probe;
- drv->driver.remove = blkvsc_remove;
+ drv->remove = blkvsc_remove;
drv->driver.shutdown = blkvsc_shutdown;
/* The driver belongs to vmbus */
diff --git a/drivers/staging/hv/hv_mouse.c b/drivers/staging/hv/hv_mouse.c
index e2363b3..d49a51e 100644
--- a/drivers/staging/hv/hv_mouse.c
+++ b/drivers/staging/hv/hv_mouse.c
@@ -858,20 +858,19 @@ static int mousevsc_probe(struct hv_device *dev)
return 0;
}
-static int mousevsc_remove(struct device *device)
+static int mousevsc_remove(struct hv_device *dev)
{
int ret = 0;
struct mousevsc_drv_obj *mousevsc_drv_obj =
- drv_to_mousedrv(device->driver);
+ drv_to_mousedrv(dev->device.driver);
- struct hv_device *device_obj = device_to_hv_device(device);
struct input_device_context *input_dev_ctx;
input_dev_ctx = kmalloc(sizeof(struct input_device_context),
GFP_KERNEL);
- dev_set_drvdata(device, input_dev_ctx);
+ dev_set_drvdata(&dev->device, input_dev_ctx);
if (input_dev_ctx->connected) {
hidinput_disconnect(input_dev_ctx->hid_device);
@@ -885,7 +884,7 @@ static int mousevsc_remove(struct device *device)
* Call to the vsc driver to let it know that the device
* is being removed
*/
- ret = mousevsc_drv_obj->base.dev_rm(device_obj);
+ ret = mousevsc_drv_obj->base.dev_rm(dev);
if (ret != 0) {
DPRINT_ERR(INPUTVSC_DRV,
@@ -1023,7 +1022,7 @@ static int __init mousevsc_init(void)
drv->driver.name = input_drv_obj->base.name;
drv->probe = mousevsc_probe;
- drv->driver.remove = mousevsc_remove;
+ drv->remove = mousevsc_remove;
/* The driver belongs to vmbus */
vmbus_child_driver_register(&drv->driver);
diff --git a/drivers/staging/hv/netvsc_drv.c b/drivers/staging/hv/netvsc_drv.c
index 685a6f5..f4c6000 100644
--- a/drivers/staging/hv/netvsc_drv.c
+++ b/drivers/staging/hv/netvsc_drv.c
@@ -408,16 +408,15 @@ static int netvsc_probe(struct hv_device *dev)
return ret;
}
-static int netvsc_remove(struct device *device)
+static int netvsc_remove(struct hv_device *dev)
{
struct netvsc_driver *net_drv_obj =
- drv_to_netvscdrv(device->driver);
- struct hv_device *device_obj = device_to_hv_device(device);
- struct net_device *net = dev_get_drvdata(&device_obj->device);
+ drv_to_netvscdrv(dev->device.driver);
+ struct net_device *net = dev_get_drvdata(&dev->device);
int ret;
if (net == NULL) {
- dev_err(device, "No net device to remove\n");
+ dev_err(&dev->device, "No net device to remove\n");
return 0;
}
@@ -434,7 +433,7 @@ static int netvsc_remove(struct device *device)
* Call to the vsc driver to let it know that the device is being
* removed
*/
- ret = net_drv_obj->base.dev_rm(device_obj);
+ ret = net_drv_obj->base.dev_rm(dev);
if (ret != 0) {
/* TODO: */
netdev_err(net, "unable to remove vsc device (ret %d)\n", ret);
@@ -501,7 +500,7 @@ static int netvsc_drv_init(int (*drv_init)(struct hv_driver *drv))
drv->driver.name = net_drv_obj->base.name;
drv->probe = netvsc_probe;
- drv->driver.remove = netvsc_remove;
+ drv->remove = netvsc_remove;
/* The driver belongs to vmbus */
ret = vmbus_child_driver_register(&drv->driver);
diff --git a/drivers/staging/hv/storvsc_drv.c b/drivers/staging/hv/storvsc_drv.c
index 2060206..e449481 100644
--- a/drivers/staging/hv/storvsc_drv.c
+++ b/drivers/staging/hv/storvsc_drv.c
@@ -128,7 +128,7 @@ static int storvsc_queuecommand(struct Scsi_Host *shost, struct scsi_cmnd *scmnd
static int storvsc_device_alloc(struct scsi_device *);
static int storvsc_device_configure(struct scsi_device *);
static int storvsc_host_reset_handler(struct scsi_cmnd *scmnd);
-static int storvsc_remove(struct device *dev);
+static int storvsc_remove(struct hv_device *dev);
static struct scatterlist *create_bounce_buffer(struct scatterlist *sgl,
unsigned int sg_count,
@@ -214,7 +214,7 @@ static int storvsc_drv_init(void)
drv->driver.name = storvsc_drv_obj->base.name;
drv->probe = storvsc_probe;
- drv->driver.remove = storvsc_remove;
+ drv->remove = storvsc_remove;
/* The driver belongs to vmbus */
ret = vmbus_child_driver_register(&drv->driver);
@@ -398,12 +398,11 @@ static int storvsc_probe(struct hv_device *device)
/*
* storvsc_remove - Callback when our device is removed
*/
-static int storvsc_remove(struct device *device)
+static int storvsc_remove(struct hv_device *dev)
{
struct storvsc_driver_object *storvsc_drv_obj =
- drv_to_stordrv(device->driver);
- struct hv_device *device_obj = device_to_hv_device(device);
- struct Scsi_Host *host = dev_get_drvdata(device);
+ drv_to_stordrv(dev->device.driver);
+ struct Scsi_Host *host = dev_get_drvdata(&dev->device);
struct host_device_context *host_device_ctx =
(struct host_device_context *)host->hostdata;
@@ -411,7 +410,7 @@ static int storvsc_remove(struct device *device)
* Call to the vsc driver to let it know that the device is being
* removed
*/
- storvsc_drv_obj->base.dev_rm(device_obj);
+ storvsc_drv_obj->base.dev_rm(dev);
if (host_device_ctx->request_pool) {
kmem_cache_destroy(host_device_ctx->request_pool);
diff --git a/drivers/staging/hv/vmbus_drv.c b/drivers/staging/hv/vmbus_drv.c
index fb55af2..b1e6cc4 100644
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -343,16 +343,13 @@ static int vmbus_remove(struct device *child_device)
int ret;
struct hv_driver *drv;
+ struct hv_device *dev = device_to_hv_device(child_device);
if (child_device->driver) {
drv = drv_to_hv_drv(child_device->driver);
- /*
- * Let the specific open-source driver handles the removal if
- * it can
- */
- if (drv->driver.remove) {
- ret = drv->driver.remove(child_device);
+ if (drv->remove) {
+ ret = drv->remove(dev);
} else {
pr_err("remove not set for driver %s\n",
dev_name(child_device));
--
1.7.4.1
^ permalink raw reply related
* [PATCH 13/18] Staging: hv: Add remove() function to struct hv_driver
From: K. Y. Srinivasan @ 2011-04-29 20:45 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization
Cc: K. Y. Srinivasan, Haiyang Zhang, Abhishek Kane, Hank Janssen
In-Reply-To: <1304109916-24874-1-git-send-email-kys@microsoft.com>
Add remove() function to struct hv_driver.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Abhishek Kane <v-abkane@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
---
drivers/staging/hv/vmbus_api.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/hv/vmbus_api.h b/drivers/staging/hv/vmbus_api.h
index 4ffb739..3ae0c46 100644
--- a/drivers/staging/hv/vmbus_api.h
+++ b/drivers/staging/hv/vmbus_api.h
@@ -101,6 +101,7 @@ struct hv_driver {
void (*cleanup)(struct hv_driver *driver);
int (*probe)(struct hv_device *);
+ int (*remove)(struct hv_device *);
};
--
1.7.4.1
^ permalink raw reply related
* [PATCH 12/18] Staging: hv: Use the probe function in struct hv_driver
From: K. Y. Srinivasan @ 2011-04-29 20:45 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization
Cc: K. Y. Srinivasan, Haiyang Zhang, Abhishek Kane, Hank Janssen
In-Reply-To: <1304109916-24874-1-git-send-email-kys@microsoft.com>
Use the newly introduced probe function.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Abhishek Kane <v-abkane@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
---
drivers/staging/hv/blkvsc_drv.c | 19 +++++++++----------
drivers/staging/hv/hv_mouse.c | 11 +++++------
drivers/staging/hv/netvsc_drv.c | 19 +++++++++----------
drivers/staging/hv/storvsc_drv.c | 23 +++++++++++------------
drivers/staging/hv/vmbus_drv.c | 6 +++---
5 files changed, 37 insertions(+), 41 deletions(-)
diff --git a/drivers/staging/hv/blkvsc_drv.c b/drivers/staging/hv/blkvsc_drv.c
index ec6a761..20b9a53 100644
--- a/drivers/staging/hv/blkvsc_drv.c
+++ b/drivers/staging/hv/blkvsc_drv.c
@@ -140,7 +140,7 @@ MODULE_PARM_DESC(ring_size, "Ring buffer size (in bytes)");
* There is a circular dependency involving blkvsc_probe()
* and block_ops.
*/
-static int blkvsc_probe(struct device *dev);
+static int blkvsc_probe(struct hv_device *dev);
static int blk_vsc_on_device_add(struct hv_device *device,
void *additional_info)
@@ -882,7 +882,7 @@ static int blkvsc_drv_init(void)
drv->driver.name = storvsc_drv_obj->base.name;
- drv->driver.probe = blkvsc_probe;
+ drv->probe = blkvsc_probe;
drv->driver.remove = blkvsc_remove;
drv->driver.shutdown = blkvsc_shutdown;
@@ -937,11 +937,10 @@ static void blkvsc_drv_exit(void)
/*
* blkvsc_probe - Add a new device for this driver
*/
-static int blkvsc_probe(struct device *device)
+static int blkvsc_probe(struct hv_device *dev)
{
struct storvsc_driver_object *storvsc_drv_obj =
- drv_to_stordrv(device->driver);
- struct hv_device *device_obj = device_to_hv_device(device);
+ drv_to_stordrv(dev->device.driver);
struct block_device_context *blkdev = NULL;
struct storvsc_device_info device_info;
@@ -961,7 +960,7 @@ static int blkvsc_probe(struct device *device)
spin_lock_init(&blkdev->lock);
- blkdev->request_pool = kmem_cache_create(dev_name(&device_obj->device),
+ blkdev->request_pool = kmem_cache_create(dev_name(&dev->device),
sizeof(struct blkvsc_request), 0,
SLAB_HWCACHE_ALIGN, NULL);
if (!blkdev->request_pool) {
@@ -971,17 +970,17 @@ static int blkvsc_probe(struct device *device)
/* Call to the vsc driver to add the device */
- ret = storvsc_drv_obj->base.dev_add(device_obj, &device_info);
+ ret = storvsc_drv_obj->base.dev_add(dev, &device_info);
if (ret != 0)
goto cleanup;
- blkdev->device_ctx = device_obj;
+ blkdev->device_ctx = dev;
/* this identified the device 0 or 1 */
blkdev->target = device_info.target_id;
/* this identified the ide ctrl 0 or 1 */
blkdev->path = device_info.path_id;
- dev_set_drvdata(device, blkdev);
+ dev_set_drvdata(&dev->device, blkdev);
ret = stor_vsc_get_major_info(&device_info, &major_info);
@@ -1041,7 +1040,7 @@ static int blkvsc_probe(struct device *device)
return ret;
remove:
- storvsc_drv_obj->base.dev_rm(device_obj);
+ storvsc_drv_obj->base.dev_rm(dev);
cleanup:
if (blkdev) {
diff --git a/drivers/staging/hv/hv_mouse.c b/drivers/staging/hv/hv_mouse.c
index 4333247..e2363b3 100644
--- a/drivers/staging/hv/hv_mouse.c
+++ b/drivers/staging/hv/hv_mouse.c
@@ -832,23 +832,22 @@ static void mousevsc_hid_close(struct hid_device *hid)
{
}
-static int mousevsc_probe(struct device *device)
+static int mousevsc_probe(struct hv_device *dev)
{
int ret = 0;
struct mousevsc_drv_obj *mousevsc_drv_obj =
- drv_to_mousedrv(device->driver);
+ drv_to_mousedrv(dev->device.driver);
- struct hv_device *device_obj = device_to_hv_device(device);
struct input_device_context *input_dev_ctx;
input_dev_ctx = kmalloc(sizeof(struct input_device_context),
GFP_KERNEL);
- dev_set_drvdata(device, input_dev_ctx);
+ dev_set_drvdata(&dev->device, input_dev_ctx);
/* Call to the vsc driver to add the device */
- ret = mousevsc_drv_obj->base.dev_add(device_obj, NULL);
+ ret = mousevsc_drv_obj->base.dev_add(dev, NULL);
if (ret != 0) {
DPRINT_ERR(INPUTVSC_DRV, "unable to add input vsc device");
@@ -1023,7 +1022,7 @@ static int __init mousevsc_init(void)
drv->driver.name = input_drv_obj->base.name;
- drv->driver.probe = mousevsc_probe;
+ drv->probe = mousevsc_probe;
drv->driver.remove = mousevsc_remove;
/* The driver belongs to vmbus */
diff --git a/drivers/staging/hv/netvsc_drv.c b/drivers/staging/hv/netvsc_drv.c
index e61eb7e..685a6f5 100644
--- a/drivers/staging/hv/netvsc_drv.c
+++ b/drivers/staging/hv/netvsc_drv.c
@@ -340,11 +340,10 @@ static void netvsc_send_garp(struct work_struct *w)
}
-static int netvsc_probe(struct device *device)
+static int netvsc_probe(struct hv_device *dev)
{
struct netvsc_driver *net_drv_obj =
- drv_to_netvscdrv(device->driver);
- struct hv_device *device_obj = device_to_hv_device(device);
+ drv_to_netvscdrv(dev->device.driver);
struct net_device *net = NULL;
struct net_device_context *net_device_ctx;
struct netvsc_device_info device_info;
@@ -361,16 +360,16 @@ static int netvsc_probe(struct device *device)
netif_carrier_off(net);
net_device_ctx = netdev_priv(net);
- net_device_ctx->device_ctx = device_obj;
+ net_device_ctx->device_ctx = dev;
net_device_ctx->avail = ring_size;
- dev_set_drvdata(device, net);
+ dev_set_drvdata(&dev->device, net);
INIT_WORK(&net_device_ctx->work, netvsc_send_garp);
/* Notify the netvsc driver of the new device */
- ret = net_drv_obj->base.dev_add(device_obj, &device_info);
+ ret = net_drv_obj->base.dev_add(dev, &device_info);
if (ret != 0) {
free_netdev(net);
- dev_set_drvdata(device, NULL);
+ dev_set_drvdata(&dev->device, NULL);
netdev_err(net, "unable to add netvsc device (ret %d)\n", ret);
return ret;
@@ -397,12 +396,12 @@ static int netvsc_probe(struct device *device)
net->features = NETIF_F_SG;
SET_ETHTOOL_OPS(net, ðtool_ops);
- SET_NETDEV_DEV(net, device);
+ SET_NETDEV_DEV(net, &dev->device);
ret = register_netdev(net);
if (ret != 0) {
/* Remove the device and release the resource */
- net_drv_obj->base.dev_rm(device_obj);
+ net_drv_obj->base.dev_rm(dev);
free_netdev(net);
}
@@ -501,7 +500,7 @@ static int netvsc_drv_init(int (*drv_init)(struct hv_driver *drv))
drv->driver.name = net_drv_obj->base.name;
- drv->driver.probe = netvsc_probe;
+ drv->probe = netvsc_probe;
drv->driver.remove = netvsc_remove;
/* The driver belongs to vmbus */
diff --git a/drivers/staging/hv/storvsc_drv.c b/drivers/staging/hv/storvsc_drv.c
index 5ac2904..2060206 100644
--- a/drivers/staging/hv/storvsc_drv.c
+++ b/drivers/staging/hv/storvsc_drv.c
@@ -123,7 +123,7 @@ static int stor_vsc_initialize(struct hv_driver *driver)
}
/* Static decl */
-static int storvsc_probe(struct device *dev);
+static int storvsc_probe(struct hv_device *dev);
static int storvsc_queuecommand(struct Scsi_Host *shost, struct scsi_cmnd *scmnd);
static int storvsc_device_alloc(struct scsi_device *);
static int storvsc_device_configure(struct scsi_device *);
@@ -213,7 +213,7 @@ static int storvsc_drv_init(void)
drv->driver.name = storvsc_drv_obj->base.name;
- drv->driver.probe = storvsc_probe;
+ drv->probe = storvsc_probe;
drv->driver.remove = storvsc_remove;
/* The driver belongs to vmbus */
@@ -320,12 +320,11 @@ static void storvsc_drv_exit(void)
/*
* storvsc_probe - Add a new device for this driver
*/
-static int storvsc_probe(struct device *device)
+static int storvsc_probe(struct hv_device *device)
{
int ret;
struct storvsc_driver_object *storvsc_drv_obj =
- drv_to_stordrv(device->driver);
- struct hv_device *device_obj = device_to_hv_device(device);
+ drv_to_stordrv(device->device.driver);
struct Scsi_Host *host;
struct host_device_context *host_device_ctx;
struct storvsc_device_info device_info;
@@ -340,16 +339,16 @@ static int storvsc_probe(struct device *device)
return -ENOMEM;
}
- dev_set_drvdata(device, host);
+ dev_set_drvdata(&device->device, host);
host_device_ctx = (struct host_device_context *)host->hostdata;
memset(host_device_ctx, 0, sizeof(struct host_device_context));
host_device_ctx->port = host->host_no;
- host_device_ctx->device_ctx = device_obj;
+ host_device_ctx->device_ctx = device;
host_device_ctx->request_pool =
- kmem_cache_create(dev_name(&device_obj->device),
+ kmem_cache_create(dev_name(&device->device),
sizeof(struct storvsc_cmd_request), 0,
SLAB_HWCACHE_ALIGN, NULL);
@@ -360,8 +359,8 @@ static int storvsc_probe(struct device *device)
device_info.port_number = host->host_no;
/* Call to the vsc driver to add the device */
- ret = storvsc_drv_obj->base.dev_add(device_obj,
- (void *)&device_info);
+ ret = storvsc_drv_obj->base.dev_add(device, (void *)&device_info);
+
if (ret != 0) {
DPRINT_ERR(STORVSC_DRV, "unable to add scsi vsc device");
kmem_cache_destroy(host_device_ctx->request_pool);
@@ -381,11 +380,11 @@ static int storvsc_probe(struct device *device)
host->max_channel = STORVSC_MAX_CHANNELS - 1;
/* Register the HBA and start the scsi bus scan */
- ret = scsi_add_host(host, device);
+ ret = scsi_add_host(host, &device->device);
if (ret != 0) {
DPRINT_ERR(STORVSC_DRV, "unable to add scsi host device");
- storvsc_drv_obj->base.dev_rm(device_obj);
+ storvsc_drv_obj->base.dev_rm(device);
kmem_cache_destroy(host_device_ctx->request_pool);
scsi_host_put(host);
diff --git a/drivers/staging/hv/vmbus_drv.c b/drivers/staging/hv/vmbus_drv.c
index 872752a..fb55af2 100644
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -319,10 +319,10 @@ static int vmbus_probe(struct device *child_device)
int ret = 0;
struct hv_driver *drv =
drv_to_hv_drv(child_device->driver);
+ struct hv_device *dev = device_to_hv_device(child_device);
- /* Let the specific open-source driver handles the probe if it can */
- if (drv->driver.probe) {
- ret = drv->driver.probe(child_device);
+ if (drv->probe) {
+ ret = drv->probe(dev);
if (ret != 0)
pr_err("probe failed for device %s (%d)\n",
dev_name(child_device), ret);
--
1.7.4.1
^ permalink raw reply related
* [PATCH 11/18] Staging: hv: Add probe function to struct hv_driver
From: K. Y. Srinivasan @ 2011-04-29 20:45 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization
Cc: K. Y. Srinivasan, Haiyang Zhang, Abhishek Kane, Hank Janssen
In-Reply-To: <1304109916-24874-1-git-send-email-kys@microsoft.com>
Add probe function to struct hv_driver.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Abhishek Kane <v-abkane@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
---
drivers/staging/hv/vmbus_api.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/hv/vmbus_api.h b/drivers/staging/hv/vmbus_api.h
index 14df762..4ffb739 100644
--- a/drivers/staging/hv/vmbus_api.h
+++ b/drivers/staging/hv/vmbus_api.h
@@ -99,6 +99,9 @@ struct hv_driver {
int (*dev_add)(struct hv_device *device, void *data);
int (*dev_rm)(struct hv_device *device);
void (*cleanup)(struct hv_driver *driver);
+
+ int (*probe)(struct hv_device *);
+
};
/* Base device object */
--
1.7.4.1
^ permalink raw reply related
* [PATCH 10/18] Staging: hv: Get rid of struct hv_bus
From: K. Y. Srinivasan @ 2011-04-29 20:45 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization; +Cc: Haiyang Zhang, Abhishek Kane
In-Reply-To: <1304109916-24874-1-git-send-email-kys@microsoft.com>
Now, get rid of struct hv_bus. We will no longer be embedding
struct bus_type.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Abhishek Kane <v-abkane@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
---
drivers/staging/hv/vmbus_drv.c | 33 +++++++++++++--------------------
1 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/hv/vmbus_drv.c b/drivers/staging/hv/vmbus_drv.c
index 6cc01c2..872752a 100644
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -45,11 +45,6 @@ static struct pci_dev *hv_pci_dev;
static struct tasklet_struct msg_dpc;
static struct tasklet_struct event_dpc;
-/* Main vmbus driver data structure */
-struct hv_bus {
- struct bus_type bus;
-};
-
unsigned int vmbus_loglevel = (ALL_MODULES << 16 | INFO_LVL);
EXPORT_SYMBOL(vmbus_loglevel);
/* (ALL_MODULES << 16 | DEBUG_LVL_ENTEREXIT); */
@@ -403,14 +398,14 @@ static void vmbus_device_release(struct device *device)
}
/* The one and only one */
-static struct hv_bus hv_bus = {
- .bus.name = "vmbus",
- .bus.match = vmbus_match,
- .bus.shutdown = vmbus_shutdown,
- .bus.remove = vmbus_remove,
- .bus.probe = vmbus_probe,
- .bus.uevent = vmbus_uevent,
- .bus.dev_attrs = vmbus_device_attrs,
+static struct bus_type hv_bus = {
+ .name = "vmbus",
+ .match = vmbus_match,
+ .shutdown = vmbus_shutdown,
+ .remove = vmbus_remove,
+ .probe = vmbus_probe,
+ .uevent = vmbus_uevent,
+ .dev_attrs = vmbus_device_attrs,
};
static const char *driver_name = "hyperv";
@@ -548,14 +543,12 @@ static int vmbus_bus_init(struct pci_dev *pdev)
goto cleanup;
}
- hv_bus.bus.name = driver_name;
-
/* Initialize the bus context */
tasklet_init(&msg_dpc, vmbus_on_msg_dpc, 0);
tasklet_init(&event_dpc, vmbus_on_event, 0);
/* Now, register the bus with LDM */
- ret = bus_register(&hv_bus.bus);
+ ret = bus_register(&hv_bus);
if (ret) {
ret = -1;
goto cleanup;
@@ -570,7 +563,7 @@ static int vmbus_bus_init(struct pci_dev *pdev)
pr_err("Unable to request IRQ %d\n",
pdev->irq);
- bus_unregister(&hv_bus.bus);
+ bus_unregister(&hv_bus);
ret = -1;
goto cleanup;
@@ -586,7 +579,7 @@ static int vmbus_bus_init(struct pci_dev *pdev)
ret = vmbus_connect();
if (ret) {
free_irq(pdev->irq, pdev);
- bus_unregister(&hv_bus.bus);
+ bus_unregister(&hv_bus);
goto cleanup;
}
@@ -616,7 +609,7 @@ int vmbus_child_driver_register(struct device_driver *drv)
pr_info("child driver registering - name %s\n", drv->name);
/* The child driver on this vmbus */
- drv->bus = &hv_bus.bus;
+ drv->bus = &hv_bus;
ret = driver_register(drv);
@@ -686,7 +679,7 @@ int vmbus_child_device_register(struct hv_device *child_device_obj)
atomic_inc_return(&device_num));
/* The new device belongs to this bus */
- child_device_obj->device.bus = &hv_bus.bus; /* device->dev.bus; */
+ child_device_obj->device.bus = &hv_bus; /* device->dev.bus; */
child_device_obj->device.parent = &hv_pci_dev->dev;
child_device_obj->device.release = vmbus_device_release;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 09/18] Staging: hv: Make event_dpc a stand alone variable
From: K. Y. Srinivasan @ 2011-04-29 20:45 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization
Cc: K. Y. Srinivasan, Haiyang Zhang, Abhishek Kane, Hank Janssen
In-Reply-To: <1304109916-24874-1-git-send-email-kys@microsoft.com>
In preparation for getting rid of struct hv_bus, Make event_dpc a
stand alone variable.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Abhishek Kane <v-abkane@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
---
drivers/staging/hv/vmbus_drv.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/hv/vmbus_drv.c b/drivers/staging/hv/vmbus_drv.c
index 38bfff0..6cc01c2 100644
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -43,11 +43,11 @@
static struct pci_dev *hv_pci_dev;
static struct tasklet_struct msg_dpc;
+static struct tasklet_struct event_dpc;
/* Main vmbus driver data structure */
struct hv_bus {
struct bus_type bus;
- struct tasklet_struct event_dpc;
};
unsigned int vmbus_loglevel = (ALL_MODULES << 16 | INFO_LVL);
@@ -519,7 +519,7 @@ static irqreturn_t vmbus_isr(int irq, void *dev_id)
tasklet_schedule(&msg_dpc);
if (test_bit(1, (unsigned long *)&ret))
- tasklet_schedule(&hv_bus.event_dpc);
+ tasklet_schedule(&event_dpc);
return IRQ_HANDLED;
} else {
@@ -552,7 +552,7 @@ static int vmbus_bus_init(struct pci_dev *pdev)
/* Initialize the bus context */
tasklet_init(&msg_dpc, vmbus_on_msg_dpc, 0);
- tasklet_init(&hv_bus.event_dpc, vmbus_on_event, 0);
+ tasklet_init(&event_dpc, vmbus_on_event, 0);
/* Now, register the bus with LDM */
ret = bus_register(&hv_bus.bus);
--
1.7.4.1
^ permalink raw reply related
* [PATCH 08/18] Staging: hv: Make msg_dpc a stand alone variable
From: K. Y. Srinivasan @ 2011-04-29 20:45 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization; +Cc: Haiyang Zhang, Abhishek Kane
In-Reply-To: <1304109916-24874-1-git-send-email-kys@microsoft.com>
In preparation for cleaning up (getting rid of) of the hv_bus structure,
make msg_dpc a stand alone variable.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Abhishek Kane <v-abkane@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
---
drivers/staging/hv/vmbus_drv.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/hv/vmbus_drv.c b/drivers/staging/hv/vmbus_drv.c
index 4106dd3..38bfff0 100644
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -42,10 +42,11 @@
static struct pci_dev *hv_pci_dev;
+static struct tasklet_struct msg_dpc;
+
/* Main vmbus driver data structure */
struct hv_bus {
struct bus_type bus;
- struct tasklet_struct msg_dpc;
struct tasklet_struct event_dpc;
};
@@ -515,7 +516,7 @@ static irqreturn_t vmbus_isr(int irq, void *dev_id)
/* Schedules a dpc if necessary */
if (ret > 0) {
if (test_bit(0, (unsigned long *)&ret))
- tasklet_schedule(&hv_bus.msg_dpc);
+ tasklet_schedule(&msg_dpc);
if (test_bit(1, (unsigned long *)&ret))
tasklet_schedule(&hv_bus.event_dpc);
@@ -550,7 +551,7 @@ static int vmbus_bus_init(struct pci_dev *pdev)
hv_bus.bus.name = driver_name;
/* Initialize the bus context */
- tasklet_init(&hv_bus.msg_dpc, vmbus_on_msg_dpc, 0);
+ tasklet_init(&msg_dpc, vmbus_on_msg_dpc, 0);
tasklet_init(&hv_bus.event_dpc, vmbus_on_event, 0);
/* Now, register the bus with LDM */
--
1.7.4.1
^ permalink raw reply related
* [PATCH 07/18] Staging: hv: Make hv_pci_dev a static variable
From: K. Y. Srinivasan @ 2011-04-29 20:45 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization; +Cc: Haiyang Zhang, Abhishek Kane
In-Reply-To: <1304109916-24874-1-git-send-email-kys@microsoft.com>
Make hv_pci_dev a static variable.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Abhishek Kane <v-abkane@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
---
drivers/staging/hv/vmbus_drv.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/hv/vmbus_drv.c b/drivers/staging/hv/vmbus_drv.c
index 8663f64..4106dd3 100644
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -40,7 +40,7 @@
#include "vmbus_private.h"
-struct pci_dev *hv_pci_dev;
+static struct pci_dev *hv_pci_dev;
/* Main vmbus driver data structure */
struct hv_bus {
--
1.7.4.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox