Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1336600 > unrolled thread

[PATCH] goldfish: Return proper error code

Back to article view | Back to linux.kernel

Contents

  [PATCH] goldfish: Return proper error code Amitoj Kaur Chawla <amitoj1606@gmail.com> - 2016-02-17 18:30 +0100
    Re: [PATCH] goldfish: Return proper error code One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-02-17 19:50 +0100
      Re: [PATCH] goldfish: Return proper error code Julia Lawall <julia.lawall@lip6.fr> - 2016-02-17 20:30 +0100
        Re: [PATCH] goldfish: Return proper error code Julia Lawall <julia.lawall@lip6.fr> - 2016-02-17 20:30 +0100

#1336600 — [PATCH] goldfish: Return proper error code

This change has been made with the goal that kernel functions should
return something more descriptive than -1 on failure.

Change the return value on valid_batchbuffer_addr() failure from -1 
to -EINVAL.

Signed-off-by: Amitoj Kaur Chawla <amitoj1606@gmail.com>
---
 drivers/platform/goldfish/goldfish_pipe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/goldfish/goldfish_pipe.c b/drivers/platform/goldfish/goldfish_pipe.c
index 9f6734c..6de6fd2 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -233,7 +233,7 @@ static int setup_access_params_addr(struct platform_device *pdev,
 		dev->aps = aps;
 		return 0;
 	} else
-		return -1;
+		return -EINVAL;
 }
 
 /* A value that will not be set by qemu emulator */
-- 
1.9.1

[toc] | [next] | [standalone]

#1336652

On Wed, 17 Feb 2016 22:53:29 +0530
Amitoj Kaur Chawla <amitoj1606@gmail.com> wrote:

> This change has been made with the goal that kernel functions should
> return something more descriptive than -1 on failure.
> 
> Change the return value on valid_batchbuffer_addr() failure from -1 
> to -EINVAL.
> 
> Signed-off-by: Amitoj Kaur Chawla <amitoj1606@gmail.com>

NAK. It's not user visible, it's a piece of code that has a pile of other
more important fixes needed first, and it's also as far as possible kept
aligned with the Android upstream.

If it were some random otherwise unchanging bit of code then it might
just about make sense but in this case no - especially when you only
change one of the two returns of -1 !

Alan

[toc] | [prev] | [next] | [standalone]

#1336693

On Wed, 17 Feb 2016, One Thousand Gnomes wrote:

> On Wed, 17 Feb 2016 22:53:29 +0530
> Amitoj Kaur Chawla <amitoj1606@gmail.com> wrote:
>
> > This change has been made with the goal that kernel functions should
> > return something more descriptive than -1 on failure.
> >
> > Change the return value on valid_batchbuffer_addr() failure from -1
> > to -EINVAL.
> >
> > Signed-off-by: Amitoj Kaur Chawla <amitoj1606@gmail.com>
>
> NAK. It's not user visible, it's a piece of code that has a pile of other
> more important fixes needed first, and it's also as far as possible kept
> aligned with the Android upstream.
>
> If it were some random otherwise unchanging bit of code then it might
> just about make sense but in this case no - especially when you only
> change one of the two returns of -1 !

The other has been chahged already in a patch in the staging tree.  Maybe
it's not in linux-next yet?

julia

[toc] | [prev] | [next] | [standalone]

#1336694

On Wed, 17 Feb 2016, Julia Lawall wrote:

>
>
> On Wed, 17 Feb 2016, One Thousand Gnomes wrote:
>
> > On Wed, 17 Feb 2016 22:53:29 +0530
> > Amitoj Kaur Chawla <amitoj1606@gmail.com> wrote:
> >
> > > This change has been made with the goal that kernel functions should
> > > return something more descriptive than -1 on failure.
> > >
> > > Change the return value on valid_batchbuffer_addr() failure from -1
> > > to -EINVAL.
> > >
> > > Signed-off-by: Amitoj Kaur Chawla <amitoj1606@gmail.com>
> >
> > NAK. It's not user visible, it's a piece of code that has a pile of other
> > more important fixes needed first, and it's also as far as possible kept
> > aligned with the Android upstream.
> >
> > If it were some random otherwise unchanging bit of code then it might
> > just about make sense but in this case no - especially when you only
> > change one of the two returns of -1 !
>
> The other has been chahged already in a patch in the staging tree.  Maybe
> it's not in linux-next yet?

It's there too: 1d427da1d7f9f81c4f5439c9610683d3cb9c1921

julia

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web