[PATCH] staging: wilc1000: fix error handling in wilc_debugfs_init()

[PATCH] staging: wilc1000: fix error handling in wilc_debugfs_init()

[Luis de Bethencourt]

The common format to check if a function returned an error pointer is to
use PTR_ERR(). Instead of ERR_PTR() which is used to return said errors.

Also, if there was an error returning -EINVAL instead of -1 is more
appropriate.

Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
---
 drivers/staging/wilc1000/wilc_debugfs.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_debugfs.c b/drivers/staging/wilc1000/wilc_debugfs.c
index fcbc95d..6252931 100644
--- a/drivers/staging/wilc1000/wilc_debugfs.c
+++ b/drivers/staging/wilc1000/wilc_debugfs.c
@@ -107,7 +107,7 @@ static int __init wilc_debugfs_init(void)
 	struct wilc_debugfs_info_t *info;
 
 	wilc_dir = debugfs_create_dir("wilc_wifi", NULL);
-	if (wilc_dir ==  ERR_PTR(-ENODEV)) {
+	if (PTR_ERR(wilc_dir) == -ENODEV) {
 		/* it's not error. the debugfs is just not being enabled. */
 		printk("ERR, kernel has built without debugfs support\n");
 		return 0;
@@ -115,7 +115,7 @@ static int __init wilc_debugfs_init(void)
 
 	if (!wilc_dir) {
 		printk("ERR, debugfs create dir\n");
-		return -1;
+		return -EINVAL;
 	}
 
 	for (i = 0; i < ARRAY_SIZE(debugfs_info); i++) {
@@ -129,7 +129,7 @@ static int __init wilc_debugfs_init(void)
 		if (!debugfs_files) {
 			printk("ERR fail to create the debugfs file, %s\n", info->name);
 			debugfs_remove_recursive(wilc_dir);
-			return -1;
+			return -EINVAL;
 		}
 	}
 	return 0;
-- 
2.5.1

Re: [PATCH] staging: wilc1000: fix error handling in wilc_debugfs_init()

[Julian Calaby]

Hi All,

On Wed, Jun 22, 2016 at 10:39 PM, Luis de Bethencourt
<luisbg@osg.samsung.com> wrote:
> The common format to check if a function returned an error pointer is to
> use PTR_ERR(). Instead of ERR_PTR() which is used to return said errors.
>
> Also, if there was an error returning -EINVAL instead of -1 is more
> appropriate.

These two changes could be argued to be separate changes deserving of
their own patches.

> Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>

However if everyone else is ok with that, this is:

Reviewed-by: Julian Calaby <julian.calaby@gmail.com>

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH] staging: wilc1000: fix error handling in wilc_debugfs_init()

[Luis de Bethencourt]

On 23/06/16 02:29, Julian Calaby wrote:
> Hi All,
> 
> On Wed, Jun 22, 2016 at 10:39 PM, Luis de Bethencourt
> <luisbg@osg.samsung.com> wrote:
>> The common format to check if a function returned an error pointer is to
>> use PTR_ERR(). Instead of ERR_PTR() which is used to return said errors.
>>
>> Also, if there was an error returning -EINVAL instead of -1 is more
>> appropriate.
> 
> These two changes could be argued to be separate changes deserving of
> their own patches.
> 
>> Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
> 
> However if everyone else is ok with that, this is:
> 
> Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
> 
> Thanks,
> 

Hi Julian,

If you don't mind I will resend as two separate patches and include your
Reviewed-by in both.

Thanks for the review,
Luis

Re: [PATCH] staging: wilc1000: fix error handling in wilc_debugfs_init()

[Julian Calaby]

Hi Luis,

On Thu, Jun 23, 2016 at 9:25 PM, Luis de Bethencourt
<luisbg@osg.samsung.com> wrote:
> On 23/06/16 02:29, Julian Calaby wrote:
>> Hi All,
>>
>> On Wed, Jun 22, 2016 at 10:39 PM, Luis de Bethencourt
>> <luisbg@osg.samsung.com> wrote:
>>> The common format to check if a function returned an error pointer is to
>>> use PTR_ERR(). Instead of ERR_PTR() which is used to return said errors.
>>>
>>> Also, if there was an error returning -EINVAL instead of -1 is more
>>> appropriate.
>>
>> These two changes could be argued to be separate changes deserving of
>> their own patches.
>>
>>> Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
>>
>> However if everyone else is ok with that, this is:
>>
>> Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
>>
>> Thanks,
>>
>
> Hi Julian,
>
> If you don't mind I will resend as two separate patches and include your
> Reviewed-by in both.

Providing there are no changes other than rebasing and splitting, I'm
fine with that.,

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/