RE: [PATCH 1/6] Staging: hv: vmbus_drv.c Replaced DPRINT with native pr_XXX

2011-02-23 Thread Hank Janssen
-Original Message- From: Joe Perches [mailto:j...@perches.com] Sent: Tuesday, February 22, 2011 8:51 PM On Tue, 2011-02-22 at 15:32 -0800, Hank Janssen wrote: This group of patches removes all DPRINT from hv_vmbus.ko. It is divided in several patches due to size. [] -

RE: [PATCH 1/6] Staging: hv: vmbus_drv.c Replaced DPRINT with native pr_XXX

2011-02-23 Thread Joe Perches
On Wed, 2011-02-23 at 16:58 +, Hank Janssen wrote: #define pr_fmt(fmt) %s: fmt, VMBUS_MOD or #define pr_fmt(fmt) %s:%s fmt, VMBUS_MOD, __func__ (if you must) I wrestled with that when I did the conversion, The reason I did not Do that is when I check other drivers very few do it

Re: [PATCH 1/6] Staging: hv: vmbus_drv.c Replaced DPRINT with native pr_XXX

2011-02-23 Thread Dan Carpenter
On Wed, Feb 23, 2011 at 04:58:10PM +, Hank Janssen wrote: Also, ff all the pr_level's are using VMBUS_MOD, then perhaps it would look better to add #define pr_fmt(fmt) %s: fmt, VMBUS_MOD or #define pr_fmt(fmt) %s:%s fmt, VMBUS_MOD, __func__ (if you must) I wrestled with

RE: [PATCH 1/6] Staging: hv: vmbus_drv.c Replaced DPRINT with native pr_XXX

2011-02-23 Thread Hank Janssen
-Original Message- From: Joe Perches [mailto:j...@perches.com] Sent: Wednesday, February 23, 2011 9:10 AM To: Hank Janssen On Wed, 2011-02-23 at 16:58 +, Hank Janssen wrote: #define pr_fmt(fmt) %s: fmt, VMBUS_MOD or #define pr_fmt(fmt) %s:%s fmt, VMBUS_MOD, __func__

Re: [PATCH]: Staging: hv: Allocate the vmbus irq dynamically

2011-02-23 Thread Greg KH
On Mon, Feb 21, 2011 at 03:51:56PM +0100, Thomas Gleixner wrote: On Mon, 21 Feb 2011, KY Srinivasan wrote: There are various ways to solve that proper. - You can provide the interrupt number from ACPI/PCI or whatever your HV provides as enumeration. - Use

Re: [PATCH 1/6] Staging: hv: vmbus_drv.c Replaced DPRINT with native pr_XXX

2011-02-23 Thread Greg KH
On Tue, Feb 22, 2011 at 03:32:40PM -0800, Hank Janssen wrote: This group of patches removes all DPRINT from hv_vmbus.ko. It is divided in several patches due to size. Why say this in the 1/6 patch? It should be in the 0/6 introduction. All DPRINT calls have been removed, and where needed

Re: [PATCH 2/6] Staging: hv: hv.c Removed all DPRINT and debug - using pr_err now

2011-02-23 Thread Greg KH
On Tue, Feb 22, 2011 at 03:32:41PM -0800, Hank Janssen wrote: This group of patches removes all DPRINT from hv_vmbus.ko. It is divided in several patches due to size. All DPRINT calls have been removed, and where needed have been replaced with pr_XX native calls. Many debug DPRINT calls have

[PATCH 1/4] staging: hv: Fix the code depending on struct vmbus_driver_context data order

2011-02-23 Thread Haiyang Zhang
The patch fixed the code depending on the exact order of fields in the struct vmbus_driver_context, so the unused field drv_ctx can be removed, and drv_obj doesn't have to be the second field in this structure. Signed-off-by: Haiyang Zhang haiya...@microsoft.com Signed-off-by: K. Y. Srinivasan

[PATCH 4/4] staging: hv: Fix the code depending on struct storvsc_driver_context data order

2011-02-23 Thread Haiyang Zhang
The patch fixed the code depending on the exact order of fields in the struct storvsc_driver_context. Now, we use container_of() instead of type casting from the first field to the container struct. Signed-off-by: Haiyang Zhang haiya...@microsoft.com Signed-off-by: K. Y. Srinivasan

RE: [PATCH 1/6] Staging: hv: vmbus_drv.c Replaced DPRINT with native pr_XXX

2011-02-23 Thread Hank Janssen
-Original Message- From: Greg KH [mailto:g...@kroah.com] Sent: Wednesday, February 23, 2011 11:12 AM To: Hank Janssen Why say this in the 1/6 patch? It should be in the 0/6 introduction. All DPRINT calls have been removed, and where needed have been replaced with pr_XX

[PATCH 2/4] staging: hv: Fix the code depending on struct netvsc_driver_context data order

2011-02-23 Thread Haiyang Zhang
The patch fixed the code depending on the exact order of fields in the struct netvsc_driver_context. Now, we use container_of() instead of type casting from the first field to the container struct. Signed-off-by: Haiyang Zhang haiya...@microsoft.com Signed-off-by: K. Y. Srinivasan

Re: [PATCH 2/4] staging: hv: Fix the code depending on struct netvsc_driver_context data order

2011-02-23 Thread Thomas Gleixner
On Wed, 23 Feb 2011, Haiyang Zhang wrote: @@ -137,8 +135,8 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net) struct net_device_context *net_device_ctx = netdev_priv(net); struct driver_context *driver_ctx =

Re: [PATCH 4/4] staging: hv: Fix the code depending on struct storvsc_driver_context data order

2011-02-23 Thread Greg KH
On Wed, Feb 23, 2011 at 12:19:58PM -0800, Haiyang Zhang wrote: The patch fixed the code depending on the exact order of fields in the struct storvsc_driver_context. Now, we use container_of() instead of type casting from the first field to the container struct. Signed-off-by: Haiyang Zhang

Re: [PATCH 3/4] staging: hv: Fix the code depending on struct blkvsc_driver_context data order

2011-02-23 Thread Greg KH
On Wed, Feb 23, 2011 at 12:19:57PM -0800, Haiyang Zhang wrote: The patch fixed the code depending on the exact order of fields in the struct blkvsc_driver_context. Now, we use container_of() instead of type casting from the first field to the container struct. Signed-off-by: Haiyang Zhang

Re: [PATCH 2/4] staging: hv: Fix the code depending on struct netvsc_driver_context data order

2011-02-23 Thread Greg KH
On Wed, Feb 23, 2011 at 12:19:56PM -0800, Haiyang Zhang wrote: The patch fixed the code depending on the exact order of fields in the struct netvsc_driver_context. Now, we use container_of() instead of type casting from the first field to the container struct. Signed-off-by: Haiyang Zhang

Re: [PATCH 1/4] staging: hv: Fix the code depending on struct vmbus_driver_context data order

2011-02-23 Thread Greg KH
On Wed, Feb 23, 2011 at 12:19:55PM -0800, Haiyang Zhang wrote: The patch fixed the code depending on the exact order of fields in the struct vmbus_driver_context, so the unused field drv_ctx can be removed, and drv_obj doesn't have to be the second field in this structure. Signed-off-by:

RE: [PATCH 1/4] staging: hv: Fix the code depending on struct vmbus_driver_context data order

2011-02-23 Thread KY Srinivasan
-Original Message- From: Greg KH [mailto:g...@kroah.com] Sent: Wednesday, February 23, 2011 4:27 PM To: Haiyang Zhang Cc: Hank Janssen; KY Srinivasan; Abhishek Kane (Mindtree Consulting PVT LTD); gre...@suse.de; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;

RE: [PATCH 1/4] staging: hv: Fix the code depending on struct vmbus_driver_context data order

2011-02-23 Thread Haiyang Zhang
From: Greg KH [mailto:g...@kroah.com] Sent: Wednesday, February 23, 2011 4:27 PM struct driver_context { struct hv_guid class_id; - struct device_driver driver; + struct hv_driver *hv_drv; If you have a pointer to hv_driver, why do you need a full 'struct device_driver'

Re: [PATCH 1/4] staging: hv: Fix the code depending on struct vmbus_driver_context data order

2011-02-23 Thread Greg KH
On Wed, Feb 23, 2011 at 10:44:37PM +, KY Srinivasan wrote: -Original Message- From: Greg KH [mailto:g...@kroah.com] Sent: Wednesday, February 23, 2011 4:27 PM To: Haiyang Zhang Cc: Hank Janssen; KY Srinivasan; Abhishek Kane (Mindtree Consulting PVT LTD);

RE: [PATCH 2/6] Staging: hv: hv.c Removed all DPRINT and debug - using pr_err now

2011-02-23 Thread Hank Janssen
-Original Message- From: Greg KH [mailto:g...@kroah.com] Sent: Wednesday, February 23, 2011 1:57 PM They where compile and run tested. And syslog was not a mess. What did I mess up here? The amount of printouts now are a fraction of what they where before. You forgot to put

Re: [PATCH 1/4] staging: hv: Fix the code depending on struct vmbus_driver_context data order

2011-02-23 Thread Greg KH
On Wed, Feb 23, 2011 at 10:55:12PM +, Haiyang Zhang wrote: From: Greg KH [mailto:g...@kroah.com] The layering is almost ok, there is still one more layer here than is needed, and it should be removed (I already removed lots of layers that were not needed, just didn't get to this one.)

Re: [PATCH 2/6] Staging: hv: hv.c Removed all DPRINT and debug - using pr_err now

2011-02-23 Thread Greg KH
On Wed, Feb 23, 2011 at 11:17:54PM +, Hank Janssen wrote: -Original Message- From: Greg KH [mailto:g...@kroah.com] Sent: Wednesday, February 23, 2011 1:57 PM They where compile and run tested. And syslog was not a mess. What did I mess up here? The amount of printouts

RE: [PATCH 2/6] Staging: hv: hv.c Removed all DPRINT and debug - using pr_err now

2011-02-23 Thread Joe Perches
On Wed, 2011-02-23 at 23:17 +, Hank Janssen wrote: -Original Message- From: Greg KH [mailto:g...@kroah.com] Sent: Wednesday, February 23, 2011 1:57 PM They where compile and run tested. And syslog was not a mess. What did I mess up here? The amount of printouts now are a

Re: [PATCH 2/6] Staging: hv: hv.c Removed all DPRINT and debug - using pr_err now

2011-02-23 Thread Greg KH
On Wed, Feb 23, 2011 at 04:57:29PM -0800, Joe Perches wrote: On Wed, 2011-02-23 at 23:17 +, Hank Janssen wrote: -Original Message- From: Greg KH [mailto:g...@kroah.com] Sent: Wednesday, February 23, 2011 1:57 PM They where compile and run tested. And syslog was not a mess.