RE: [PATCH 2/5] staging:ti dspbridge: remove unnecessary check for NULL pointer in cmm.c

2010-07-28 Thread Ramos Falcon, Ernesto
Agree! I'll send new version of this patch.

>-Original Message-
>From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
>Sent: Wednesday, July 28, 2010 12:12 PM
>To: Ramos Falcon, Ernesto
>Cc: Menon, Nishanth; gre...@suse.de; Ramirez Luna, Omar; o...@wizery.com;
>ameya.pala...@nokia.com; felipe.contre...@nokia.com; Guzman Lugo, Fernando;
>linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-
>o...@vger.kernel.org
>Subject: Re: [PATCH 2/5] staging:ti dspbridge: remove unnecessary check for
>NULL pointer in cmm.c
>
>Hi Ernesto,
>
>On Wed, Jul 28, 2010 at 7:53 PM, Ramos Falcon, Ernesto 
>wrote:
>>>here is a better approach:
>>>remove cmm_xlator_delete altogether
>
>[...]
>
>> I considered this approach before but in terms of maintainability I
>thought it was easier to locate where translator tables are destroy if we
>keep cmm_xlator_delete function.
>
>That's not maintainability, that's debugging convenience. AFAIU linux
>is all about maintenance, because that provides real, tangible, and
>proven gains. Debugging convenience gains are hypothetical; you don't
>really know how useful it will be to have a separate free function.
>
>And please avoid bottom-posting, instead use interleaved style,
>otherwise people see a comment, and then have to scroll down to see
>the answer.
>http://en.wikipedia.org/wiki/Posting_style#Interleaved_style
>
>--
>Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/5] staging:ti dspbridge: remove unnecessary check for NULL pointer in cmm.c

2010-07-28 Thread Felipe Contreras
Hi Ernesto,

On Wed, Jul 28, 2010 at 7:53 PM, Ramos Falcon, Ernesto  wrote:
>>here is a better approach:
>>remove cmm_xlator_delete altogether

[...]

> I considered this approach before but in terms of maintainability I thought 
> it was easier to locate where translator tables are destroy if we keep 
> cmm_xlator_delete function.

That's not maintainability, that's debugging convenience. AFAIU linux
is all about maintenance, because that provides real, tangible, and
proven gains. Debugging convenience gains are hypothetical; you don't
really know how useful it will be to have a separate free function.

And please avoid bottom-posting, instead use interleaved style,
otherwise people see a comment, and then have to scroll down to see
the answer.
http://en.wikipedia.org/wiki/Posting_style#Interleaved_style

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 2/5] staging:ti dspbridge: remove unnecessary check for NULL pointer in cmm.c

2010-07-28 Thread Ramos Falcon, Ernesto


>-Original Message-
>From: Menon, Nishanth
>Sent: Wednesday, July 28, 2010 10:32 AM
>To: Ramos Falcon, Ernesto
>Cc: gre...@suse.de; Ramirez Luna, Omar; o...@wizery.com;
>ameya.pala...@nokia.com; felipe.contre...@nokia.com; Guzman Lugo, Fernando;
>linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-
>o...@vger.kernel.org
>Subject: Re: [PATCH 2/5] staging:ti dspbridge: remove unnecessary check for
>NULL pointer in cmm.c
>
>Nishanth Menon had written, on 07/28/2010 10:04 AM, the following:
>> Ramos Falcon, Ernesto had written, on 07/28/2010 09:40 AM, the following:
>>> Remove unnecessary check for NULL pointer in cmm.c.
>>>
>>> Signed-off-by: Ernesto Ramos 
>>> ---
>>>  drivers/staging/tidspbridge/pmgr/cmm.c |8 ++--
>>>  1 files changed, 2 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/staging/tidspbridge/pmgr/cmm.c
>b/drivers/staging/tidspbridge/pmgr/cmm.c
>>> index 8e808d9..874ed64 100644
>>> --- a/drivers/staging/tidspbridge/pmgr/cmm.c
>>> +++ b/drivers/staging/tidspbridge/pmgr/cmm.c
>>> @@ -992,16 +992,12 @@ int cmm_xlator_create(struct cmm_xlatorobject
>**xlator,
>>>  int cmm_xlator_delete(struct cmm_xlatorobject *xlator, bool force)
>>>  {
>>> struct cmm_xlator *xlator_obj = (struct cmm_xlator *)xlator;
>>> -   int status = 0;
>>>
>>> DBC_REQUIRE(refs > 0);
>>>
>>> -   if (xlator_obj)
>>> -   kfree(xlator_obj);
>>> -   else
>>> -   status = -EFAULT;
>>> +   kfree(xlator_obj);
>>>
>>> -   return status;
>>> +   return 0;
>>>  }
>>>
>>>  /*
>> which kind of begs the question - does this function need to any longer
>> return int?
>>
>here is a better approach:
>remove cmm_xlator_delete altogether
>diff --git a/drivers/staging/tidspbridge/pmgr/cmm.c
>b/drivers/staging/tidspbridge/pmgr/cmm.c
>index 8e808d9..1a4ebca 100644
>--- a/drivers/staging/tidspbridge/pmgr/cmm.c
>+++ b/drivers/staging/tidspbridge/pmgr/cmm.c
>@@ -984,27 +984,6 @@ int cmm_xlator_create(struct cmm_xlatorobject
>**xlator,
>  }
>
>  /*
>- *   cmm_xlator_delete 
>- *  Purpose:
>- *  Free the Xlator resources.
>- *  VM gets freed later.
>- */
>-int cmm_xlator_delete(struct cmm_xlatorobject *xlator, bool force)
>-{
>-  struct cmm_xlator *xlator_obj = (struct cmm_xlator *)xlator;
>-  int status = 0;
>-
>-  DBC_REQUIRE(refs > 0);
>-
>-  if (xlator_obj)
>-  kfree(xlator_obj);
>-  else
>-  status = -EFAULT;
>-
>-  return status;
>-}
>-
>-/*
>   *   cmm_xlator_alloc_buf 
>   */
>  void *cmm_xlator_alloc_buf(struct cmm_xlatorobject *xlator, void *va_buf,
>diff --git a/drivers/staging/tidspbridge/rmgr/node.c
>b/drivers/staging/tidspbridge/rmgr/node.c
>index 9f07c81..0c39288 100644
>--- a/drivers/staging/tidspbridge/rmgr/node.c
>+++ b/drivers/staging/tidspbridge/rmgr/node.c
>@@ -2503,7 +2503,6 @@ static void delete_node(struct node_object *hnode,
>   struct process_context *pr_ctxt)
>  {
>   struct node_mgr *hnode_mgr;
>-  struct cmm_xlatorobject *xlator;
>   struct bridge_drv_interface *intf_fxns;
>   u32 i;
>   enum node_type node_type;
>@@ -2521,7 +2520,6 @@ static void delete_node(struct node_object *hnode,
>   hnode_mgr = hnode->hnode_mgr;
>   if (!hnode_mgr)
>   goto func_end;
>-  xlator = hnode->xlator;
>   node_type = node_get_type(hnode);
>   if (node_type != NODE_DEVICE) {
>   node_msg_args = hnode->create_args.asa.node_msg_args;
>@@ -2617,10 +2615,7 @@ static void delete_node(struct node_object *hnode,
>   hnode->dcd_props.obj_data.node_obj.pstr_i_alg_name = NULL;
>
>   /* Free all SM address translator resources */
>-  if (xlator) {
>-  (void)cmm_xlator_delete(xlator, true);  /* force free */
>-  xlator = NULL;
>-  }
>+  kfree(hnode->xlator);
>
>   kfree(hnode->nldr_node_obj);
>   hnode->nldr_node_obj = NULL;
>diff --git a/drivers/staging/tidspbridge/rmgr/strm.c
>b/drivers/staging/tidspbridge/rmgr/strm.c
>index 73888e3..05a8d13 100644
>--- a/drivers/staging/tidspbridge/rmgr/strm.c
>+++ b/drivers/staging/tidspbridge/rmgr/strm.c
>@@ -844,14 +844,8 @@ static int delete_strm(struct strm_object *stream_obj)
>   status = (*intf_fxns->pfn_chnl_close)
>   (stream_obj->chnl_obj);
>  

Re: [PATCH 2/5] staging:ti dspbridge: remove unnecessary check for NULL pointer in cmm.c

2010-07-28 Thread Nishanth Menon

Nishanth Menon had written, on 07/28/2010 10:04 AM, the following:

Ramos Falcon, Ernesto had written, on 07/28/2010 09:40 AM, the following:

Remove unnecessary check for NULL pointer in cmm.c.

Signed-off-by: Ernesto Ramos 
---
 drivers/staging/tidspbridge/pmgr/cmm.c |8 ++--
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/tidspbridge/pmgr/cmm.c 
b/drivers/staging/tidspbridge/pmgr/cmm.c
index 8e808d9..874ed64 100644
--- a/drivers/staging/tidspbridge/pmgr/cmm.c
+++ b/drivers/staging/tidspbridge/pmgr/cmm.c
@@ -992,16 +992,12 @@ int cmm_xlator_create(struct cmm_xlatorobject **xlator,
 int cmm_xlator_delete(struct cmm_xlatorobject *xlator, bool force)
 {
struct cmm_xlator *xlator_obj = (struct cmm_xlator *)xlator;
-   int status = 0;
 
 	DBC_REQUIRE(refs > 0);
 
-	if (xlator_obj)

-   kfree(xlator_obj);
-   else
-   status = -EFAULT;
+   kfree(xlator_obj);
 
-	return status;

+   return 0;
 }
 
 /*
which kind of begs the question - does this function need to any longer 
return int?



here is a better approach:
remove cmm_xlator_delete altogether
diff --git a/drivers/staging/tidspbridge/pmgr/cmm.c 
b/drivers/staging/tidspbridge/pmgr/cmm.c

index 8e808d9..1a4ebca 100644
--- a/drivers/staging/tidspbridge/pmgr/cmm.c
+++ b/drivers/staging/tidspbridge/pmgr/cmm.c
@@ -984,27 +984,6 @@ int cmm_xlator_create(struct cmm_xlatorobject **xlator,
 }

 /*
- *   cmm_xlator_delete 
- *  Purpose:
- *  Free the Xlator resources.
- *  VM gets freed later.
- */
-int cmm_xlator_delete(struct cmm_xlatorobject *xlator, bool force)
-{
-   struct cmm_xlator *xlator_obj = (struct cmm_xlator *)xlator;
-   int status = 0;
-
-   DBC_REQUIRE(refs > 0);
-
-   if (xlator_obj)
-   kfree(xlator_obj);
-   else
-   status = -EFAULT;
-
-   return status;
-}
-
-/*
  *   cmm_xlator_alloc_buf 
  */
 void *cmm_xlator_alloc_buf(struct cmm_xlatorobject *xlator, void *va_buf,
diff --git a/drivers/staging/tidspbridge/rmgr/node.c 
b/drivers/staging/tidspbridge/rmgr/node.c

index 9f07c81..0c39288 100644
--- a/drivers/staging/tidspbridge/rmgr/node.c
+++ b/drivers/staging/tidspbridge/rmgr/node.c
@@ -2503,7 +2503,6 @@ static void delete_node(struct node_object *hnode,
struct process_context *pr_ctxt)
 {
struct node_mgr *hnode_mgr;
-   struct cmm_xlatorobject *xlator;
struct bridge_drv_interface *intf_fxns;
u32 i;
enum node_type node_type;
@@ -2521,7 +2520,6 @@ static void delete_node(struct node_object *hnode,
hnode_mgr = hnode->hnode_mgr;
if (!hnode_mgr)
goto func_end;
-   xlator = hnode->xlator;
node_type = node_get_type(hnode);
if (node_type != NODE_DEVICE) {
node_msg_args = hnode->create_args.asa.node_msg_args;
@@ -2617,10 +2615,7 @@ static void delete_node(struct node_object *hnode,
hnode->dcd_props.obj_data.node_obj.pstr_i_alg_name = NULL;

/* Free all SM address translator resources */
-   if (xlator) {
-   (void)cmm_xlator_delete(xlator, true);  /* force free */
-   xlator = NULL;
-   }
+   kfree(hnode->xlator);

kfree(hnode->nldr_node_obj);
hnode->nldr_node_obj = NULL;
diff --git a/drivers/staging/tidspbridge/rmgr/strm.c 
b/drivers/staging/tidspbridge/rmgr/strm.c

index 73888e3..05a8d13 100644
--- a/drivers/staging/tidspbridge/rmgr/strm.c
+++ b/drivers/staging/tidspbridge/rmgr/strm.c
@@ -844,14 +844,8 @@ static int delete_strm(struct strm_object *stream_obj)
status = (*intf_fxns->pfn_chnl_close)
(stream_obj->chnl_obj);
/* Free all SM address translator resources */
-   if (DSP_SUCCEEDED(status)) {
-   if (stream_obj->xlator) {
-   /* force free */
-   (void)cmm_xlator_delete(stream_obj->
-   xlator,
-   true);
-   }
-   }
+   if (DSP_SUCCEEDED(status))
+   kfree(stream_obj->xlator);
}
kfree(stream_obj);
} else {
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/5] staging:ti dspbridge: remove unnecessary check for NULL pointer in cmm.c

2010-07-28 Thread Nishanth Menon

Ramos Falcon, Ernesto had written, on 07/28/2010 09:40 AM, the following:

Remove unnecessary check for NULL pointer in cmm.c.

Signed-off-by: Ernesto Ramos 
---
 drivers/staging/tidspbridge/pmgr/cmm.c |8 ++--
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/tidspbridge/pmgr/cmm.c 
b/drivers/staging/tidspbridge/pmgr/cmm.c
index 8e808d9..874ed64 100644
--- a/drivers/staging/tidspbridge/pmgr/cmm.c
+++ b/drivers/staging/tidspbridge/pmgr/cmm.c
@@ -992,16 +992,12 @@ int cmm_xlator_create(struct cmm_xlatorobject **xlator,
 int cmm_xlator_delete(struct cmm_xlatorobject *xlator, bool force)
 {
struct cmm_xlator *xlator_obj = (struct cmm_xlator *)xlator;
-   int status = 0;
 
 	DBC_REQUIRE(refs > 0);
 
-	if (xlator_obj)

-   kfree(xlator_obj);
-   else
-   status = -EFAULT;
+   kfree(xlator_obj);
 
-	return status;

+   return 0;
 }
 
 /*
which kind of begs the question - does this function need to any longer 
return int?


--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html