Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

2011-04-29 Thread Greg KH 
On Fri, Apr 29, 2011 at 02:26:13PM +, KY Srinivasan wrote:
 Perhaps I did not properly formulate my question here. The review
 process itself may be open-ended, and that is fine - we will fix all 
 legitimate
 issues/concerns  in our drivers whether they are in the staging area or not. 
 My question was specifically with regards to the review process that may gate 
 exiting
 staging. I am hoping to re-spin the remaining patches of the last patch-set 
 and send it to
 you by early next week and ask for a review. I fully intend to address 
 whatever review 
 comments I may get in a very timely manner. Assuming at some point in time 
 after I ask
 for this review there are no outstanding issues, would that be sufficient to 
 exit staging?  

If it looks acceptable to me, and there are no other objections from
other developers, then yes, that would be sufficient to move it out of
staging.

thanks,

greg k-h
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

Re: [PATCH 08/25] Staging: hv: vmbus_driver cannot be unloaded; cleanup accordingly

2011-04-29 Thread Greg KH 
On Fri, Apr 29, 2011 at 01:49:21PM +, KY Srinivasan wrote:
   2) Windows host would not permit reloading the driver without
   rebooting the guest.
  
  That's a different issue, and one that I am very surprised to hear.
  That kind of invalidates ever being able to update the driver in a guest
  for a long-running system that you want to migrate and not reboot.  That
  sounds like a major bug in hyper-v, don't you agree?
 
 In practical terms, I am not sure this is a major problem. If the root device
 Is managed by a Hyper-V driver, then you cannot unload that driver and 
 drivers it depends on anyway.

I don't run my hyper-v guests using the hyper-v driver for my root
devices, so in my setup, it is possible to unload the whole vmbus
subsystem and drivers and reload it without any system interruption.

Now I have never tried that... :)

 Greg, I am open to either approach here: 1) I could drop this patch and 
 restore the 
 exit function. 2) I could keep the patch as is, but add additional comments to
 capture this discussion. Let me know what you prefer and I will send the 
 remaining 
 patch-set with the agreed upon changes.

As you all are happy with not having this be unloaded, I'll go with 2)
as it is your code to maintain and support, not mine.

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!)

thanks,

greg k-h
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

RE: [PATCH 12/25] Staging: hv: Cleanup error handling in vmbus_child_device_register()

2011-04-29 Thread KY Srinivasan 


 -Original Message-
 From: Greg KH [mailto:g...@kroah.com]
 Sent: Wednesday, April 27, 2011 8:26 PM
 To: KY Srinivasan
 Cc: gre...@suse.de; linux-ker...@vger.kernel.org;
 de...@linuxdriverproject.org; virtualizat...@lists.osdl.org; Haiyang Zhang;
 Abhishek Kane (Mindtree Consulting PVT LTD)
 Subject: Re: [PATCH 12/25] Staging: hv: Cleanup error handling in
 vmbus_child_device_register()
 
 On Wed, Apr 27, 2011 at 02:11:48AM +, KY Srinivasan wrote:
 
 
   -Original Message-
   From: Greg KH [mailto:g...@kroah.com]
   Sent: Tuesday, April 26, 2011 6:51 PM
   To: KY Srinivasan
   Cc: gre...@suse.de; linux-ker...@vger.kernel.org;
   de...@linuxdriverproject.org; virtualizat...@lists.osdl.org; Haiyang 
   Zhang;
   Abhishek Kane (Mindtree Consulting PVT LTD)
   Subject: Re: [PATCH 12/25] Staging: hv: Cleanup error handling in
   vmbus_child_device_register()
  
   On Tue, Apr 26, 2011 at 09:20:29AM -0700, K. Y. Srinivasan wrote:
Cleanup error handling in vmbus_child_device_register().
   
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Abhishek Kane v-abk...@microsoft.com
Signed-off-by: Hank Janssen hjans...@microsoft.com
---
 drivers/staging/hv/vmbus_drv.c |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)
   
diff --git a/drivers/staging/hv/vmbus_drv.c
 b/drivers/staging/hv/vmbus_drv.c
index d597dd4..4d569ad 100644
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -720,11 +720,16 @@ int vmbus_child_device_register(struct hv_device
   *child_device_obj)
 */
ret = device_register(child_device_obj-device);
   
+   if (ret)
+   return ret;
+
/* vmbus_probe() error does not get propergate to 
device_register(). */
ret = child_device_obj-probe_error;
  
   Wait, why not?  Why is the probe_error have to be saved off like this?
   That seems like something is wrong here, this patch should not be
   needed.
  
   Well, you should check the return value of device_register, that is
   needed, but this seems broken somehow.
 
  The current code had comments claiming that the probe error was not
  correctly propagated. Looking at the kernel side of the code, it was not 
  clear
  if device_register() could succeed while the probe might fail.
 
 Of course it can, device_register() has nothing to do with the probe
 callback of the device itself.  To think otherwise is to not understand
 the driver model and assume things that you should never be caring
 about.
 
 Think about it, if you register a device, you don't know at that point
 in time if a driver is currently loaded for it, and that it will be
 bound to that device.  Nor do you care, as any needed notifications for
 new drivers will be sent to userspace, and they will be loaded at some
 random time in the future.  So a probe() call might never be called for
 this device until some other time, running on some other processor, in
 some other thread.
 
 Drivers are allowed to return errors from their probe functions for
 valid reasons (i.e. this driver shouldn't bind to this device for a
 variety of good reasons.)  No one cares about this, as the driver core
 handles it properly and will pass on to the next driver in the list that
 might be able to be bound to this device.
 
 So why do you care about the return value of the probe() call?  It gets
 properly handled already by the driver core, why would your bus ever
 care about it?  (Hint, no other bus does, as it makes no sense.)
 
  In any event, if you can guarantee that device_register() can return
  any probe related errors, I agree with you that saving the probe error
  is an overkill. The current code saved the probe error and with new
  check I added with regards to the return value of device_register,
  there is no correctness issue with this patch.
 
 As explained above, no, it will not return a probe error, as that makes
 no sense.  If the code is wanting to rely on this, it is broken and must
 be fixed.

I did not say that device_register would return the probe_error. On the 
contrary, the code I added explicitly ensures that proper cleanup is done
for  the failure of  device_register and if the  probe function were
called on the same context executing the device_register call,
 the failure of the probe call as well (looking at the stack trace while in
the probe function, this appeared to be the case currently).

If you look at the existing code; the current  code did not deal with the 
failure of
device_register() - it over-writes the return value of device_register with
that of the probe error. This patch fixed that problem.

The current code dealt with the probe error by spinning up a work item to
deal with the probe failure. This work item would try to unregister the device 
that was not fully registered and this caused a problem. I tried to

RE: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

2011-04-29 Thread KY Srinivasan 


 -Original Message-
 From: Christoph Hellwig [mailto:h...@infradead.org]
 Sent: Wednesday, April 27, 2011 8:19 AM
 To: KY Srinivasan
 Cc: Christoph Hellwig; Greg KH; gre...@suse.de; linux-ker...@vger.kernel.org;
 de...@linuxdriverproject.org; virtualizat...@lists.osdl.org
 Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
 
 On Wed, Apr 27, 2011 at 11:47:03AM +, KY Srinivasan wrote:
  On the host side, Windows emulates the  standard PC hardware
  to permit hosting of fully virtualized operating systems.
  To enhance disk I/O performance, we support a virtual block driver.
  This block driver currently handles disks that have been setup as IDE
  disks for the guest - as specified in the guest configuration.
 
  On the SCSI side, we emulate a SCSI HBA. Devices configured
  under the SCSI controller for the guest are handled via this
  emulated HBA (SCSI front-end). So, SCSI disks configured for
  the guest are handled through native SCSI upper-level drivers.
  If this SCSI front-end driver is not loaded, currently, the guest
  cannot see devices that have been configured as SCSI devices.
  So, while the virtual block driver described earlier could potentially
  handle all block devices, the implementation choices made on the host
  will not permit it. Also, the only SCSI device that can be currently 
  configured
  for the guest is a disk device.
 
  Both the block device driver (hv_blkvsc) and the SCSI front-end
  driver (hv_storvsc) communicate with the host via unique channels
  that are implemented as bi-directional ring buffers. Each (storage)
  channel carries with it enough state to uniquely identify the device on
  the host side. Microsoft has chosen to use SCSI verbs for this storage 
  channel
  communication.
 
 This doesn't really explain much at all.  The only important piece
 of information I can read from this statement is that both blkvsc
 and storvsc only support disks, but not any other kind of device,
 and that chosing either one is an arbitrary seletin when setting up
 a VM configuration.
 
 But this still isn't an excuse to implement a block layer driver for
 a SCSI protocol, and it doesn't not explain in what way the two
 protocols actually differ.  You really should implement blksvs as a SCSI
 LLDD, too - and from the looks of it it doesn't even have to be a
 separate one, but just adding the ids to storvsc would do the work.

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.

Regards,

K. Y
 

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

2011-04-29 Thread Greg KH 
On Fri, Apr 29, 2011 at 04:32:35PM +, KY Srinivasan wrote:
 
 
  -Original Message-
  From: Christoph Hellwig [mailto:h...@infradead.org]
  Sent: Wednesday, April 27, 2011 8:19 AM
  To: KY Srinivasan
  Cc: Christoph Hellwig; Greg KH; gre...@suse.de; 
  linux-ker...@vger.kernel.org;
  de...@linuxdriverproject.org; virtualizat...@lists.osdl.org
  Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
  
  On Wed, Apr 27, 2011 at 11:47:03AM +, KY Srinivasan wrote:
   On the host side, Windows emulates the  standard PC hardware
   to permit hosting of fully virtualized operating systems.
   To enhance disk I/O performance, we support a virtual block driver.
   This block driver currently handles disks that have been setup as IDE
   disks for the guest - as specified in the guest configuration.
  
   On the SCSI side, we emulate a SCSI HBA. Devices configured
   under the SCSI controller for the guest are handled via this
   emulated HBA (SCSI front-end). So, SCSI disks configured for
   the guest are handled through native SCSI upper-level drivers.
   If this SCSI front-end driver is not loaded, currently, the guest
   cannot see devices that have been configured as SCSI devices.
   So, while the virtual block driver described earlier could potentially
   handle all block devices, the implementation choices made on the host
   will not permit it. Also, the only SCSI device that can be currently 
   configured
   for the guest is a disk device.
  
   Both the block device driver (hv_blkvsc) and the SCSI front-end
   driver (hv_storvsc) communicate with the host via unique channels
   that are implemented as bi-directional ring buffers. Each (storage)
   channel carries with it enough state to uniquely identify the device on
   the host side. Microsoft has chosen to use SCSI verbs for this storage 
   channel
   communication.
  
  This doesn't really explain much at all.  The only important piece
  of information I can read from this statement is that both blkvsc
  and storvsc only support disks, but not any other kind of device,
  and that chosing either one is an arbitrary seletin when setting up
  a VM configuration.
  
  But this still isn't an excuse to implement a block layer driver for
  a SCSI protocol, and it doesn't not explain in what way the two
  protocols actually differ.  You really should implement blksvs as a SCSI
  LLDD, too - and from the looks of it it doesn't even have to be a
  separate one, but just adding the ids to storvsc would do the work.
 
 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).

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.

thanks,

greg k-h
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

RE: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

2011-04-29 Thread KY Srinivasan 


 -Original Message-
 From: Greg KH [mailto:g...@kroah.com]
 Sent: Friday, April 29, 2011 12:40 PM
 To: KY Srinivasan
 Cc: Christoph Hellwig; gre...@suse.de; linux-ker...@vger.kernel.org;
 de...@linuxdriverproject.org; virtualizat...@lists.osdl.org
 Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
 
 On Fri, Apr 29, 2011 at 04:32:35PM +, KY Srinivasan wrote:
 
 
   -Original Message-
   From: Christoph Hellwig [mailto:h...@infradead.org]
   Sent: Wednesday, April 27, 2011 8:19 AM
   To: KY Srinivasan
   Cc: Christoph Hellwig; Greg KH; gre...@suse.de; linux-
 ker...@vger.kernel.org;
   de...@linuxdriverproject.org; virtualizat...@lists.osdl.org
   Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
  
   On Wed, Apr 27, 2011 at 11:47:03AM +, KY Srinivasan wrote:
On the host side, Windows emulates the  standard PC hardware
to permit hosting of fully virtualized operating systems.
To enhance disk I/O performance, we support a virtual block driver.
This block driver currently handles disks that have been setup as IDE
disks for the guest - as specified in the guest configuration.
   
On the SCSI side, we emulate a SCSI HBA. Devices configured
under the SCSI controller for the guest are handled via this
emulated HBA (SCSI front-end). So, SCSI disks configured for
the guest are handled through native SCSI upper-level drivers.
If this SCSI front-end driver is not loaded, currently, the guest
cannot see devices that have been configured as SCSI devices.
So, while the virtual block driver described earlier could potentially
handle all block devices, the implementation choices made on the host
will not permit it. Also, the only SCSI device that can be currently 
configured
for the guest is a disk device.
   
Both the block device driver (hv_blkvsc) and the SCSI front-end
driver (hv_storvsc) communicate with the host via unique channels
that are implemented as bi-directional ring buffers. Each (storage)
channel carries with it enough state to uniquely identify the device on
the host side. Microsoft has chosen to use SCSI verbs for this storage
 channel
communication.
  
   This doesn't really explain much at all.  The only important piece
   of information I can read from this statement is that both blkvsc
   and storvsc only support disks, but not any other kind of device,
   and that chosing either one is an arbitrary seletin when setting up
   a VM configuration.
  
   But this still isn't an excuse to implement a block layer driver for
   a SCSI protocol, and it doesn't not explain in what way the two
   protocols actually differ.  You really should implement blksvs as a SCSI
   LLDD, too - and from the looks of it it doesn't even have to be a
   separate one, but just adding the ids to storvsc would do the work.
 
  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).
 
 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.

If we don't load the blkvsc driver, the emulated IDE controller exposed to
the guest can and will be seen by the libata core. In this case though, your
disk I/O will be taking the emulated path with the usual performance hit.

When you load the blkvsc driver, the device access does not go through the 
emulated
IDE controller. Blkvsc is truly a generic block driver that registers as a 
block driver in
the guest and talks to an appropriate device driver on the host, communicating 
over
the vmbus. In this respect, it is identical to block drivers we have for guests 
in other
virtualization platforms (Xen etc.). The only difference is that on the host 
side,
the only way you can assign a scsi disk to the guest is to configure this scsi 
disk
under the scsi controller. So, while blkvsc is a generic block driver, because 
of the
restrictions on the host side, it only ends up managing block devices that have 
IDE majors.   

 
 We really don't want to write new IDE drivers anymore that don't use
 libata.

As I noted earlier, it is incorrect to view Hyper-V blkvsc driver as an IDE 
driver. There
is nothing IDE specific about it. It is very much like other block front-end 
drivers
(like in Xen) that get their device information from the host and register the 
block
device accordingly with the guest. It just happens that in the current version 
of the
Windows host, only devices that are configured as IDE devices in the host end 
up being
managed by this driver. To make this clear, in my recent

RE: [PATCH 08/25] Staging: hv: vmbus_driver cannot be unloaded; cleanup accordingly

2011-04-29 Thread KY Srinivasan 


 -Original Message-
 From: Greg KH [mailto:gre...@suse.de]
 Sent: Friday, April 29, 2011 11:11 AM
 To: KY Srinivasan
 Cc: Greg KH; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
 virtualizat...@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 01:49:21PM +, KY Srinivasan wrote:
 
 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!)

Thanks Greg; soon after I sent you this patch-set, I had also sent a single 
patch to
address a redundant assignment:

0001-Staging-hv-Do-not-re-set-the-bus-name.patch

Please drop this patch. I will deal with this issue as part of the remaining 
patch-set
I will be sending now.

Regards,

K. Y


 
 
 thanks,
 
 greg k-h

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[RESEND] [PATCH 00/18] Staging: hv: Cleanup vmbus driver code

2011-04-29 Thread K. Y. Srinivasan 
This is a resend of the patches yet to be applied.
This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days.  In this patch-set we
deal with the following issues:


1) Cleanup error handling in the vmbus_probe() and 
   vmbus_child_device_register() functions. Fixed a 
   bug in the probe failure path as part of this cleanup.

2) The Windows host cannot handle the vmbus_driver being 
   unloaded and subsequently loaded. Cleanup the driver with
   this in mind.

3) Get rid of struct hv_bus that embedded struct bus_type to 
   conform with the LDM.

4) Add probe/remove/shutdown functions to struct hv_driver to
   conform to LDM.

5) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
   to allocate irq resources to the vmbus driver. I recently learnt
   that the vmbus driver is an acpi enumerated device on the Hyper-V
   platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[PATCH 02/18] Staging: hv: Get rid of vmbus_release_unattached_channels() as it is not used

2011-04-29 Thread K. Y. Srinivasan 
Since vmbus_release_unattached_channels() is only used in module
unload path and since the vmbus driver cannot be unloaded,
get rid of this dead code.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Abhishek Kane v-abk...@microsoft.com
Signed-off-by: Hank Janssen hjans...@microsoft.com
---
 drivers/staging/hv/channel_mgmt.c |   33 -
 drivers/staging/hv/channel_mgmt.h |2 --
 2 files changed, 0 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/hv/channel_mgmt.c 
b/drivers/staging/hv/channel_mgmt.c
index fe32f7e..1929ab3 100644
--- a/drivers/staging/hv/channel_mgmt.c
+++ b/drivers/staging/hv/channel_mgmt.c
@@ -791,37 +791,4 @@ cleanup:
return ret;
 }
 
-/*
- * vmbus_release_unattached_channels - Release channels that are
- * unattached/unconnected ie (no drivers associated)
- */
-void vmbus_release_unattached_channels(void)
-{
-   struct vmbus_channel *channel, *pos;
-   struct vmbus_channel *start = NULL;
-   unsigned long flags;
-
-   spin_lock_irqsave(vmbus_connection.channel_lock, flags);
-
-   list_for_each_entry_safe(channel, pos, vmbus_connection.chn_list,
-listentry) {
-   if (channel == start)
-   break;
-
-   if (!channel-device_obj-drv) {
-   list_del(channel-listentry);
-
-   pr_err(Releasing unattached device object\n);
-
-   vmbus_child_device_unregister(channel-device_obj);
-   free_channel(channel);
-   } else {
-   if (!start)
-   start = channel;
-   }
-   }
-
-   spin_unlock_irqrestore(vmbus_connection.channel_lock, flags);
-}
-
 /* eof */
diff --git a/drivers/staging/hv/channel_mgmt.h 
b/drivers/staging/hv/channel_mgmt.h
index 96f74e2..3b2c393 100644
--- a/drivers/staging/hv/channel_mgmt.h
+++ b/drivers/staging/hv/channel_mgmt.h
@@ -315,6 +315,4 @@ void vmbus_onmessage(void *context);
 
 int vmbus_request_offers(void);
 
-void vmbus_release_unattached_channels(void);
-
 #endif /* _CHANNEL_MGMT_H_ */
-- 
1.7.4.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[PATCH 01/18] Staging: hv: vmbus_driver cannot be unloaded; cleanup accordingly

2011-04-29 Thread K. Y. Srinivasan 
The vmbus driver cannot be unloaded; the windows host does not
permit this: A) All guest resources given to the host cannot
be recovered and B) Windows host does not permit reloading the
vmbus_driver without re-booting the guest. Both these issues
are host related. Acknowledge this reality and cleanup the 
vmbus driver accordingly. Note that, ideally we will want to handle 
the root device through the Hyper-V block driver. In this case 
unloading the vmbus driver will not be possible because of the
dependency issues.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Abhishek Kane v-abk...@microsoft.com
Signed-off-by: Hank Janssen hjans...@microsoft.com
---
 drivers/staging/hv/vmbus_drv.c |   32 
 1 files changed, 0 insertions(+), 32 deletions(-)

diff --git a/drivers/staging/hv/vmbus_drv.c b/drivers/staging/hv/vmbus_drv.c
index bf124a7..d597dd4 100644
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -622,30 +622,6 @@ cleanup:
return ret;
 }
 
-/*
- * vmbus_bus_exit - Terminate the vmbus driver.
- *
- * This routine is opposite of vmbus_bus_init()
- */
-static void vmbus_bus_exit(void)
-{
-
-
-   vmbus_release_unattached_channels();
-   vmbus_disconnect();
-   on_each_cpu(hv_synic_cleanup, NULL, 1);
-
-   hv_cleanup();
-
-   bus_unregister(hv_bus.bus);
-
-   free_irq(hv_pci_dev-irq, hv_pci_dev);
-
-   tasklet_kill(hv_bus.msg_dpc);
-   tasklet_kill(hv_bus.event_dpc);
-}
-
-
 /**
  * vmbus_child_driver_register() - Register a vmbus's child driver
  * @drv:Pointer to driver structure you want to register
@@ -814,17 +790,9 @@ static int __init hv_pci_init(void)
return pci_register_driver(hv_bus_driver);
 }
 
-static void __exit hv_pci_exit(void)
-{
-   vmbus_bus_exit();
-   pci_unregister_driver(hv_bus_driver);
-}
-
-
 
 MODULE_LICENSE(GPL);
 MODULE_VERSION(HV_DRV_VERSION);
 module_param(vmbus_loglevel, int, S_IRUGO|S_IWUSR);
 
 module_init(hv_pci_init);
-module_exit(hv_pci_exit);
-- 
1.7.4.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[PATCH 16/18] Staging: hv: Use the shutdown() function in struct hv_driver

2011-04-29 Thread K. Y. Srinivasan 
Use the newly introduced  shutdown() function.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Abhishek Kane v-abk...@microsoft.com
Signed-off-by: Hank Janssen hjans...@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

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[PATCH 03/18] Staging: hv: Get rid of the drv field in struct hv_device

2011-04-29 Thread K. Y. Srinivasan 
Now, we can rid of the drv field in struct hv_device.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Abhishek Kane v-abk...@microsoft.com
Signed-off-by: Hank Janssen hjans...@microsoft.com
---
 drivers/staging/hv/vmbus_api.h |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/hv/vmbus_api.h b/drivers/staging/hv/vmbus_api.h
index 51fa952..02e3587 100644
--- a/drivers/staging/hv/vmbus_api.h
+++ b/drivers/staging/hv/vmbus_api.h
@@ -103,9 +103,6 @@ struct hv_driver {
 
 /* Base device object */
 struct hv_device {
-   /* the driver for this device */
-   struct hv_driver *drv;
-
char name[64];
 
struct work_struct probe_failed_work_item;
-- 
1.7.4.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[PATCH 05/18] Staging: hv: Cleanup vmbus_probe() function

2011-04-29 Thread K. Y. Srinivasan 
The logic for handling probe failure was broken. Now that we have
cleaned up error handling, get rid of the vmbus_probe_failed_cb()
function.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Abhishek Kane v-abk...@microsoft.com
Signed-off-by: Hank Janssen hjans...@microsoft.com
---
 drivers/staging/hv/vmbus_api.h |4 
 drivers/staging/hv/vmbus_drv.c |   31 ++-
 2 files changed, 2 insertions(+), 33 deletions(-)

diff --git a/drivers/staging/hv/vmbus_api.h b/drivers/staging/hv/vmbus_api.h
index 02e3587..14df762 100644
--- a/drivers/staging/hv/vmbus_api.h
+++ b/drivers/staging/hv/vmbus_api.h
@@ -105,10 +105,6 @@ struct hv_driver {
 struct hv_device {
char name[64];
 
-   struct work_struct probe_failed_work_item;
-
-   int probe_error;
-
/* the device type id of this device */
struct hv_guid dev_type;
 
diff --git a/drivers/staging/hv/vmbus_drv.c b/drivers/staging/hv/vmbus_drv.c
index 1183459..5f88249 100644
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -313,27 +313,6 @@ static int vmbus_match(struct device *device, struct 
device_driver *driver)
return match;
 }
 
-
-/*
- * vmbus_probe_failed_cb - Callback when a driver probe failed in vmbus_probe()
- *
- * We need a callback because we cannot invoked device_unregister() inside
- * vmbus_probe() since vmbus_probe() may be invoked inside device_register()
- * i.e. we cannot call device_unregister() inside device_register()
- */
-static void vmbus_probe_failed_cb(struct work_struct *context)
-{
-   struct hv_device *device_ctx = (struct hv_device *)context;
-
-   /*
-* Kick off the process of unregistering the device.
-* This will call vmbus_remove() and eventually vmbus_device_release()
-*/
-   device_unregister(device_ctx-device);
-
-   /* put_device(device_ctx-device); */
-}
-
 /*
  * vmbus_probe - Add the new vmbus's child device
  */
@@ -342,20 +321,14 @@ 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 = dev-probe_error =
-   drv-driver.probe(child_device);
-   if (ret != 0) {
+   ret = drv-driver.probe(child_device);
+   if (ret != 0)
pr_err(probe failed for device %s (%d)\n,
   dev_name(child_device), ret);
 
-   INIT_WORK(dev-probe_failed_work_item,
- vmbus_probe_failed_cb);
-   schedule_work(dev-probe_failed_work_item);
-   }
} else {
pr_err(probe not set for driver %s\n,
   dev_name(child_device));
-- 
1.7.4.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[PATCH 17/18] Staging: hv: VMBUS is a acpi enumerated device; get irq value from bios

2011-04-29 Thread K. Y. Srinivasan 
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 k...@microsoft.com
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Abhishek Kane v-abk...@microsoft.com
Signed-off-by: Hank Janssen hjans...@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 haiya...@microsoft.com
  *   Hank Janssen  hjans...@microsoft.com
+ *   K. Y. Srinivasan k...@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

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[PATCH 18/18] Staging: hv: Get rid of an unused variable from struct hv_driver

2011-04-29 Thread K. Y. Srinivasan 
The name field is unused in struct hv_driver. Get rid of it.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Abhishek Kane v-abk...@microsoft.com
Signed-off-by: Hank Janssen hjans...@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

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[PATCH 06/18] Staging: hv: Properly handle errors in hv_pci_probe()

2011-04-29 Thread K. Y. Srinivasan 
Much of the vmbus driver initialization is done within the hv_pci_probe()
function. Properly handle errors in hv_pci_probe so that we can
appropriately deal with loading of the vmbus driver.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Abhishek Kane v-abk...@microsoft.com
Signed-off-by: Hank Janssen hjans...@microsoft.com
---
 drivers/staging/hv/vmbus_drv.c |   34 +-
 1 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/hv/vmbus_drv.c b/drivers/staging/hv/vmbus_drv.c
index 5f88249..8663f64 100644
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -54,6 +54,8 @@ EXPORT_SYMBOL(vmbus_loglevel);
/* (ALL_MODULES  16 | DEBUG_LVL_ENTEREXIT); */
/* (((VMBUS | VMBUS_DRV)16) | DEBUG_LVL_ENTEREXIT); */
 
+static int pci_probe_error;
+static struct completion probe_event;
 
 static void get_channel_info(struct hv_device *device,
 struct hv_device_info *info)
@@ -722,19 +724,19 @@ void vmbus_child_device_unregister(struct hv_device 
*device_obj)
 static int __devinit hv_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
 {
-   int err;
-
hv_pci_dev = pdev;
 
-   err = pci_enable_device(pdev);
-   if (err)
-   return err;
+   pci_probe_error = pci_enable_device(pdev);
+   if (pci_probe_error)
+   goto probe_cleanup;
 
-   err = vmbus_bus_init(pdev);
-   if (err)
+   pci_probe_error = vmbus_bus_init(pdev);
+   if (pci_probe_error)
pci_disable_device(pdev);
 
-   return err;
+probe_cleanup:
+   complete(probe_event);
+   return pci_probe_error;
 }
 
 /*
@@ -757,7 +759,21 @@ static struct pci_driver hv_bus_driver = {
 
 static int __init hv_pci_init(void)
 {
-   return pci_register_driver(hv_bus_driver);
+   int ret;
+   init_completion(probe_event);
+   ret = pci_register_driver(hv_bus_driver);
+   if (ret)
+   return ret;
+   /*
+* All the vmbus initialization occurs within the
+* hv_pci_probe() function. Wait for hv_pci_probe()
+* to complete.
+*/
+   wait_for_completion(probe_event);
+
+   if (pci_probe_error)
+   pci_unregister_driver(hv_bus_driver);
+   return pci_probe_error;
 }
 
 
-- 
1.7.4.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[PATCH 07/18] Staging: hv: Make hv_pci_dev a static variable

2011-04-29 Thread K. Y. Srinivasan 
Make hv_pci_dev a static variable.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Abhishek Kane v-abk...@microsoft.com
Signed-off-by: Hank Janssen hjans...@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

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[PATCH 10/18] Staging: hv: Get rid of struct hv_bus

2011-04-29 Thread K. Y. Srinivasan 
Now, get rid of struct hv_bus. We will no longer be embedding
struct bus_type.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Abhishek Kane v-abk...@microsoft.com
Signed-off-by: Hank Janssen hjans...@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

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[PATCH 04/18] Staging: hv: Cleanup error handling in vmbus_child_device_register()

2011-04-29 Thread K. Y. Srinivasan 
Cleanup error handling in vmbus_child_device_register().

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Abhishek Kane v-abk...@microsoft.com
Signed-off-by: Hank Janssen hjans...@microsoft.com
---
 drivers/staging/hv/vmbus_drv.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/hv/vmbus_drv.c b/drivers/staging/hv/vmbus_drv.c
index d597dd4..1183459 100644
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -720,9 +720,6 @@ int vmbus_child_device_register(struct hv_device 
*child_device_obj)
 */
ret = device_register(child_device_obj-device);
 
-   /* vmbus_probe() error does not get propergate to device_register(). */
-   ret = child_device_obj-probe_error;
-
if (ret)
pr_err(Unable to register child device\n);
else
-- 
1.7.4.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[PATCH 15/18] Staging: hv: Add shutdown() function to struct hv_driver

2011-04-29 Thread K. Y. Srinivasan 
Add shutdown() function to struct hv_driver.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Abhishek Kane v-abk...@microsoft.com
Signed-off-by: Hank Janssen hjans...@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

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[PATCH 14/18] Staging: hv: Use the remove() function in struct hv_driver

2011-04-29 Thread K. Y. Srinivasan 
Use the newly introduced remove() function in struct hv_driver.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Abhishek Kane v-abk...@microsoft.com
Signed-off-by: Hank Janssen hjans...@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

[PATCH 13/18] Staging: hv: Add remove() function to struct hv_driver

2011-04-29 Thread K. Y. Srinivasan 
Add remove() function to struct hv_driver.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Abhishek Kane v-abk...@microsoft.com
Signed-off-by: Hank Janssen hjans...@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

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[PATCH 11/18] Staging: hv: Add probe function to struct hv_driver

2011-04-29 Thread K. Y. Srinivasan 
Add probe function to struct hv_driver.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Abhishek Kane v-abk...@microsoft.com
Signed-off-by: Hank Janssen hjans...@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

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[PATCH 09/18] Staging: hv: Make event_dpc a stand alone variable

2011-04-29 Thread K. Y. Srinivasan 
In preparation for getting rid of struct hv_bus, Make event_dpc a
stand alone variable.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Abhishek Kane v-abk...@microsoft.com
Signed-off-by: Hank Janssen hjans...@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

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[PATCH 12/18] Staging: hv: Use the probe function in struct hv_driver

2011-04-29 Thread K. Y. Srinivasan 
Use the newly introduced probe function.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Signed-off-by: Abhishek Kane v-abk...@microsoft.com
Signed-off-by: Hank Janssen hjans...@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
+++

RE: [PATCH 08/25] Staging: hv: vmbus_driver cannot be unloaded; cleanup accordingly

2011-04-29 Thread KY Srinivasan 


 -Original Message-
 From: Greg KH [mailto:gre...@suse.de]
 Sent: Friday, April 29, 2011 11:11 AM
 To: KY Srinivasan
 Cc: Greg KH; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
 virtualizat...@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

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

Re: [PATCH 08/25] Staging: hv: vmbus_driver cannot be unloaded; cleanup accordingly

2011-04-29 Thread Greg KH 
On Fri, Apr 29, 2011 at 10:02:43PM +, KY Srinivasan wrote:
 
 
  -Original Message-
  From: Greg KH [mailto:gre...@suse.de]
  Sent: Friday, April 29, 2011 11:11 AM
  To: KY Srinivasan
  Cc: Greg KH; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
  virtualizat...@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
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

RE: [PATCH 08/25] Staging: hv: vmbus_driver cannot be unloaded; cleanup accordingly

2011-04-29 Thread KY Srinivasan 


 -Original Message-
 From: Greg KH [mailto:gre...@suse.de]
 Sent: Friday, April 29, 2011 7:14 PM
 To: KY Srinivasan
 Cc: Greg KH; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
 virtualizat...@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 +, KY Srinivasan wrote:
 
 
   -Original Message-
   From: Greg KH [mailto:gre...@suse.de]
   Sent: Friday, April 29, 2011 11:11 AM
   To: KY Srinivasan
   Cc: Greg KH; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
   virtualizat...@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



___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization