GPIO: Fix probe() error return in gpio driver probes

GPIO: Fix probe() error return in gpio driver probes

[Ben Dooks]

[-- Attachment #1: simtec/check-gpio-driver-return-codes.patch --]
[-- Type: text/plain, Size: 3301 bytes --]

A number of drivers in drivers/gpio return -ENODEV when confronted
with missing setup parameters such as the platform data. However,
returning -ENODEV causes the driver layer to silently ignore the
driver as it assumes the probe did not find anything and was only
speculative.

To make life easier to discern why a driver is not being attached,
change to returning -EINVAL, which is a better description of the
fact that the driver data was not valid.

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Index: linux.git7/drivers/gpio/max7301.c
===================================================================
--- linux.git7.orig/drivers/gpio/max7301.c	2008-12-12 13:35:42.000000000 +0000
+++ linux.git7/drivers/gpio/max7301.c	2008-12-12 13:36:12.000000000 +0000
@@ -218,7 +218,7 @@ static int __devinit max7301_probe(struc
 
 	pdata = spi->dev.platform_data;
 	if (!pdata || !pdata->base)
-		return -ENODEV;
+		return -EINVAL;
 
 	/*
 	 * bits_per_word cannot be configured in platform data
Index: linux.git7/drivers/gpio/max732x.c
===================================================================
--- linux.git7.orig/drivers/gpio/max732x.c	2008-12-12 13:36:22.000000000 +0000
+++ linux.git7/drivers/gpio/max732x.c	2008-12-12 13:36:28.000000000 +0000
@@ -268,7 +268,7 @@ static int __devinit max732x_probe(struc
 
 	pdata = client->dev.platform_data;
 	if (pdata == NULL)
-		return -ENODEV;
+		return -EINVAL;
 
 	chip = kzalloc(sizeof(struct max732x_chip), GFP_KERNEL);
 	if (chip == NULL)
Index: linux.git7/drivers/gpio/mcp23s08.c
===================================================================
--- linux.git7.orig/drivers/gpio/mcp23s08.c	2008-12-12 14:10:01.000000000 +0000
+++ linux.git7/drivers/gpio/mcp23s08.c	2008-12-12 14:11:19.000000000 +0000
@@ -311,7 +311,7 @@ static int mcp23s08_probe(struct spi_dev
 
 	pdata = spi->dev.platform_data;
 	if (!pdata || !gpio_is_valid(pdata->base))
-		return -ENODEV;
+		return -EINVAL;
 
 	for (addr = 0; addr < 4; addr++) {
 		if (!pdata->chip[addr].is_present)
Index: linux.git7/drivers/gpio/pca953x.c
===================================================================
--- linux.git7.orig/drivers/gpio/pca953x.c	2008-12-12 13:33:47.000000000 +0000
+++ linux.git7/drivers/gpio/pca953x.c	2008-12-12 13:33:55.000000000 +0000
@@ -201,7 +201,7 @@ static int __devinit pca953x_probe(struc
 
 	pdata = client->dev.platform_data;
 	if (pdata == NULL)
-		return -ENODEV;
+		return -EINVAL;
 
 	chip = kzalloc(sizeof(struct pca953x_chip), GFP_KERNEL);
 	if (chip == NULL)
Index: linux.git7/drivers/gpio/pcf857x.c
===================================================================
--- linux.git7.orig/drivers/gpio/pcf857x.c	2008-12-12 13:34:33.000000000 +0000
+++ linux.git7/drivers/gpio/pcf857x.c	2008-12-12 13:34:54.000000000 +0000
@@ -189,7 +189,7 @@ static int pcf857x_probe(struct i2c_clie
 
 	pdata = client->dev.platform_data;
 	if (!pdata)
-		return -ENODEV;
+		return -EINVAL;
 
 	/* Allocate, initialize, and register this gpio_chip. */
 	gpio = kzalloc(sizeof *gpio, GFP_KERNEL);
@@ -249,7 +249,7 @@ static int pcf857x_probe(struct i2c_clie
 			status = i2c_read_le16(client);
 
 	} else
-		status = -ENODEV;
+		status = -EINVAL;
 
 	if (status < 0)
 		goto fail;

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

GPIO: Fix probe() error return in gpio driver probes

[Ben Dooks]

[-- Attachment #1: simtec/check-gpio-driver-return-codes.patch --]
[-- Type: text/plain, Size: 3361 bytes --]

A number of drivers in drivers/gpio return -ENODEV when confronted
with missing setup parameters such as the platform data. However,
returning -ENODEV causes the driver layer to silently ignore the
driver as it assumes the probe did not find anything and was only
speculative.

To make life easier to discern why a driver is not being attached,
change to returning -EINVAL, which is a better description of the
fact that the driver data was not valid.

Signed-off-by: Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>
Index: linux.git7/drivers/gpio/max7301.c
===================================================================
--- linux.git7.orig/drivers/gpio/max7301.c	2008-12-12 13:35:42.000000000 +0000
+++ linux.git7/drivers/gpio/max7301.c	2008-12-12 13:36:12.000000000 +0000
@@ -218,7 +218,7 @@ static int __devinit max7301_probe(struc
 
 	pdata = spi->dev.platform_data;
 	if (!pdata || !pdata->base)
-		return -ENODEV;
+		return -EINVAL;
 
 	/*
 	 * bits_per_word cannot be configured in platform data
Index: linux.git7/drivers/gpio/max732x.c
===================================================================
--- linux.git7.orig/drivers/gpio/max732x.c	2008-12-12 13:36:22.000000000 +0000
+++ linux.git7/drivers/gpio/max732x.c	2008-12-12 13:36:28.000000000 +0000
@@ -268,7 +268,7 @@ static int __devinit max732x_probe(struc
 
 	pdata = client->dev.platform_data;
 	if (pdata == NULL)
-		return -ENODEV;
+		return -EINVAL;
 
 	chip = kzalloc(sizeof(struct max732x_chip), GFP_KERNEL);
 	if (chip == NULL)
Index: linux.git7/drivers/gpio/mcp23s08.c
===================================================================
--- linux.git7.orig/drivers/gpio/mcp23s08.c	2008-12-12 14:10:01.000000000 +0000
+++ linux.git7/drivers/gpio/mcp23s08.c	2008-12-12 14:11:19.000000000 +0000
@@ -311,7 +311,7 @@ static int mcp23s08_probe(struct spi_dev
 
 	pdata = spi->dev.platform_data;
 	if (!pdata || !gpio_is_valid(pdata->base))
-		return -ENODEV;
+		return -EINVAL;
 
 	for (addr = 0; addr < 4; addr++) {
 		if (!pdata->chip[addr].is_present)
Index: linux.git7/drivers/gpio/pca953x.c
===================================================================
--- linux.git7.orig/drivers/gpio/pca953x.c	2008-12-12 13:33:47.000000000 +0000
+++ linux.git7/drivers/gpio/pca953x.c	2008-12-12 13:33:55.000000000 +0000
@@ -201,7 +201,7 @@ static int __devinit pca953x_probe(struc
 
 	pdata = client->dev.platform_data;
 	if (pdata == NULL)
-		return -ENODEV;
+		return -EINVAL;
 
 	chip = kzalloc(sizeof(struct pca953x_chip), GFP_KERNEL);
 	if (chip == NULL)
Index: linux.git7/drivers/gpio/pcf857x.c
===================================================================
--- linux.git7.orig/drivers/gpio/pcf857x.c	2008-12-12 13:34:33.000000000 +0000
+++ linux.git7/drivers/gpio/pcf857x.c	2008-12-12 13:34:54.000000000 +0000
@@ -189,7 +189,7 @@ static int pcf857x_probe(struct i2c_clie
 
 	pdata = client->dev.platform_data;
 	if (!pdata)
-		return -ENODEV;
+		return -EINVAL;
 
 	/* Allocate, initialize, and register this gpio_chip. */
 	gpio = kzalloc(sizeof *gpio, GFP_KERNEL);
@@ -249,7 +249,7 @@ static int pcf857x_probe(struct i2c_clie
 			status = i2c_read_le16(client);
 
 	} else
-		status = -ENODEV;
+		status = -EINVAL;
 
 	if (status < 0)
 		goto fail;

-- 
Ben (ben-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: GPIO: Fix probe() error return in gpio driver probes

[Ben Dooks]

On Fri, Dec 12, 2008 at 03:24:27PM +0000, Ben Dooks wrote:
> A number of drivers in drivers/gpio return -ENODEV when confronted
> with missing setup parameters such as the platform data. However,
> returning -ENODEV causes the driver layer to silently ignore the
> driver as it assumes the probe did not find anything and was only
> speculative.
> 
> To make life easier to discern why a driver is not being attached,
> change to returning -EINVAL, which is a better description of the
> fact that the driver data was not valid.
> 
> Signed-off-by: Ben Dooks <ben-linux@fluff.org>

Has anyone reveiwed this patch? Are there any comments, or can this
be commited at somepoint (even if it is during the next merge window)?

> Index: linux.git7/drivers/gpio/max7301.c
> ===================================================================
> --- linux.git7.orig/drivers/gpio/max7301.c	2008-12-12 13:35:42.000000000 +0000
> +++ linux.git7/drivers/gpio/max7301.c	2008-12-12 13:36:12.000000000 +0000
> @@ -218,7 +218,7 @@ static int __devinit max7301_probe(struc
>  
>  	pdata = spi->dev.platform_data;
>  	if (!pdata || !pdata->base)
> -		return -ENODEV;
> +		return -EINVAL;
>  
>  	/*
>  	 * bits_per_word cannot be configured in platform data
> Index: linux.git7/drivers/gpio/max732x.c
> ===================================================================
> --- linux.git7.orig/drivers/gpio/max732x.c	2008-12-12 13:36:22.000000000 +0000
> +++ linux.git7/drivers/gpio/max732x.c	2008-12-12 13:36:28.000000000 +0000
> @@ -268,7 +268,7 @@ static int __devinit max732x_probe(struc
>  
>  	pdata = client->dev.platform_data;
>  	if (pdata == NULL)
> -		return -ENODEV;
> +		return -EINVAL;
>  
>  	chip = kzalloc(sizeof(struct max732x_chip), GFP_KERNEL);
>  	if (chip == NULL)
> Index: linux.git7/drivers/gpio/mcp23s08.c
> ===================================================================
> --- linux.git7.orig/drivers/gpio/mcp23s08.c	2008-12-12 14:10:01.000000000 +0000
> +++ linux.git7/drivers/gpio/mcp23s08.c	2008-12-12 14:11:19.000000000 +0000
> @@ -311,7 +311,7 @@ static int mcp23s08_probe(struct spi_dev
>  
>  	pdata = spi->dev.platform_data;
>  	if (!pdata || !gpio_is_valid(pdata->base))
> -		return -ENODEV;
> +		return -EINVAL;
>  
>  	for (addr = 0; addr < 4; addr++) {
>  		if (!pdata->chip[addr].is_present)
> Index: linux.git7/drivers/gpio/pca953x.c
> ===================================================================
> --- linux.git7.orig/drivers/gpio/pca953x.c	2008-12-12 13:33:47.000000000 +0000
> +++ linux.git7/drivers/gpio/pca953x.c	2008-12-12 13:33:55.000000000 +0000
> @@ -201,7 +201,7 @@ static int __devinit pca953x_probe(struc
>  
>  	pdata = client->dev.platform_data;
>  	if (pdata == NULL)
> -		return -ENODEV;
> +		return -EINVAL;
>  
>  	chip = kzalloc(sizeof(struct pca953x_chip), GFP_KERNEL);
>  	if (chip == NULL)
> Index: linux.git7/drivers/gpio/pcf857x.c
> ===================================================================
> --- linux.git7.orig/drivers/gpio/pcf857x.c	2008-12-12 13:34:33.000000000 +0000
> +++ linux.git7/drivers/gpio/pcf857x.c	2008-12-12 13:34:54.000000000 +0000
> @@ -189,7 +189,7 @@ static int pcf857x_probe(struct i2c_clie
>  
>  	pdata = client->dev.platform_data;
>  	if (!pdata)
> -		return -ENODEV;
> +		return -EINVAL;
>  
>  	/* Allocate, initialize, and register this gpio_chip. */
>  	gpio = kzalloc(sizeof *gpio, GFP_KERNEL);
> @@ -249,7 +249,7 @@ static int pcf857x_probe(struct i2c_clie
>  			status = i2c_read_le16(client);
>  
>  	} else
> -		status = -ENODEV;
> +		status = -EINVAL;
>  
>  	if (status < 0)
>  		goto fail;
> 
> -- 
> Ben (ben@fluff.org, http://www.fluff.org/)
> 
>   'a smiley only costs 4 bytes'
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: GPIO: Fix probe() error return in gpio driver probes

[Ben Dooks]

On Fri, Dec 12, 2008 at 03:24:27PM +0000, Ben Dooks wrote:
> A number of drivers in drivers/gpio return -ENODEV when confronted
> with missing setup parameters such as the platform data. However,
> returning -ENODEV causes the driver layer to silently ignore the
> driver as it assumes the probe did not find anything and was only
> speculative.
> 
> To make life easier to discern why a driver is not being attached,
> change to returning -EINVAL, which is a better description of the
> fact that the driver data was not valid.
> 
> Signed-off-by: Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>

Has anyone reveiwed this patch? Are there any comments, or can this
be commited at somepoint (even if it is during the next merge window)?

> Index: linux.git7/drivers/gpio/max7301.c
> ===================================================================
> --- linux.git7.orig/drivers/gpio/max7301.c	2008-12-12 13:35:42.000000000 +0000
> +++ linux.git7/drivers/gpio/max7301.c	2008-12-12 13:36:12.000000000 +0000
> @@ -218,7 +218,7 @@ static int __devinit max7301_probe(struc
>  
>  	pdata = spi->dev.platform_data;
>  	if (!pdata || !pdata->base)
> -		return -ENODEV;
> +		return -EINVAL;
>  
>  	/*
>  	 * bits_per_word cannot be configured in platform data
> Index: linux.git7/drivers/gpio/max732x.c
> ===================================================================
> --- linux.git7.orig/drivers/gpio/max732x.c	2008-12-12 13:36:22.000000000 +0000
> +++ linux.git7/drivers/gpio/max732x.c	2008-12-12 13:36:28.000000000 +0000
> @@ -268,7 +268,7 @@ static int __devinit max732x_probe(struc
>  
>  	pdata = client->dev.platform_data;
>  	if (pdata == NULL)
> -		return -ENODEV;
> +		return -EINVAL;
>  
>  	chip = kzalloc(sizeof(struct max732x_chip), GFP_KERNEL);
>  	if (chip == NULL)
> Index: linux.git7/drivers/gpio/mcp23s08.c
> ===================================================================
> --- linux.git7.orig/drivers/gpio/mcp23s08.c	2008-12-12 14:10:01.000000000 +0000
> +++ linux.git7/drivers/gpio/mcp23s08.c	2008-12-12 14:11:19.000000000 +0000
> @@ -311,7 +311,7 @@ static int mcp23s08_probe(struct spi_dev
>  
>  	pdata = spi->dev.platform_data;
>  	if (!pdata || !gpio_is_valid(pdata->base))
> -		return -ENODEV;
> +		return -EINVAL;
>  
>  	for (addr = 0; addr < 4; addr++) {
>  		if (!pdata->chip[addr].is_present)
> Index: linux.git7/drivers/gpio/pca953x.c
> ===================================================================
> --- linux.git7.orig/drivers/gpio/pca953x.c	2008-12-12 13:33:47.000000000 +0000
> +++ linux.git7/drivers/gpio/pca953x.c	2008-12-12 13:33:55.000000000 +0000
> @@ -201,7 +201,7 @@ static int __devinit pca953x_probe(struc
>  
>  	pdata = client->dev.platform_data;
>  	if (pdata == NULL)
> -		return -ENODEV;
> +		return -EINVAL;
>  
>  	chip = kzalloc(sizeof(struct pca953x_chip), GFP_KERNEL);
>  	if (chip == NULL)
> Index: linux.git7/drivers/gpio/pcf857x.c
> ===================================================================
> --- linux.git7.orig/drivers/gpio/pcf857x.c	2008-12-12 13:34:33.000000000 +0000
> +++ linux.git7/drivers/gpio/pcf857x.c	2008-12-12 13:34:54.000000000 +0000
> @@ -189,7 +189,7 @@ static int pcf857x_probe(struct i2c_clie
>  
>  	pdata = client->dev.platform_data;
>  	if (!pdata)
> -		return -ENODEV;
> +		return -EINVAL;
>  
>  	/* Allocate, initialize, and register this gpio_chip. */
>  	gpio = kzalloc(sizeof *gpio, GFP_KERNEL);
> @@ -249,7 +249,7 @@ static int pcf857x_probe(struct i2c_clie
>  			status = i2c_read_le16(client);
>  
>  	} else
> -		status = -ENODEV;
> +		status = -EINVAL;
>  
>  	if (status < 0)
>  		goto fail;
> 
> -- 
> Ben (ben-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/)
> 
>   'a smiley only costs 4 bytes'
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Ben (ben-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: GPIO: Fix probe() error return in gpio driver probes

[David Brownell]

On Sunday 14 December 2008, Ben Dooks wrote:
> Has anyone reveiwed this patch? Are there any comments, or can this
> be commited at somepoint (even if it is during the next merge window)?

I was thinking that -EINVAL is almost the least informative
diagnostic code possible, since so many places return it
that it's usually hard to find out *which* invalid parameter
triggered ...

Is there a less-overloaded code you could return?

I have no issue with the patch other than that.

- Dave

Re: GPIO: Fix probe() error return in gpio driver probes

[David Brownell]

On Sunday 14 December 2008, Ben Dooks wrote:
> Has anyone reveiwed this patch? Are there any comments, or can this
> be commited at somepoint (even if it is during the next merge window)?

I was thinking that -EINVAL is almost the least informative
diagnostic code possible, since so many places return it
that it's usually hard to find out *which* invalid parameter
triggered ...

Is there a less-overloaded code you could return?

I have no issue with the patch other than that.

- Dave

Re: GPIO: Fix probe() error return in gpio driver probes

[Jean Delvare]

On Sun, 14 Dec 2008 16:11:17 -0800, David Brownell wrote:
> On Sunday 14 December 2008, Ben Dooks wrote:
> > Has anyone reveiwed this patch? Are there any comments, or can this
> > be commited at somepoint (even if it is during the next merge window)?
> 
> I was thinking that -EINVAL is almost the least informative
> diagnostic code possible, since so many places return it
> that it's usually hard to find out *which* invalid parameter
> triggered ...
> 
> Is there a less-overloaded code you could return?

-EINVAL sounds right to me, all that's really missing is dev_dbg()
messages in the drivers to log what the exact problem was. 

> I have no issue with the patch other than that.

-- 
Jean Delvare

Re: GPIO: Fix probe() error return in gpio driver probes

[Jean Delvare]

On Sun, 14 Dec 2008 16:11:17 -0800, David Brownell wrote:
> On Sunday 14 December 2008, Ben Dooks wrote:
> > Has anyone reveiwed this patch? Are there any comments, or can this
> > be commited at somepoint (even if it is during the next merge window)?
> 
> I was thinking that -EINVAL is almost the least informative
> diagnostic code possible, since so many places return it
> that it's usually hard to find out *which* invalid parameter
> triggered ...
> 
> Is there a less-overloaded code you could return?

-EINVAL sounds right to me, all that's really missing is dev_dbg()
messages in the drivers to log what the exact problem was. 

> I have no issue with the patch other than that.

-- 
Jean Delvare

Re: GPIO: Fix probe() error return in gpio driver probes

[Ben Dooks]

On Sun, Dec 14, 2008 at 04:11:17PM -0800, David Brownell wrote:
> On Sunday 14 December 2008, Ben Dooks wrote:
> > Has anyone reveiwed this patch? Are there any comments, or can this
> > be commited at somepoint (even if it is during the next merge window)?
> 
> I was thinking that -EINVAL is almost the least informative
> diagnostic code possible, since so many places return it
> that it's usually hard to find out *which* invalid parameter
> triggered ...
> 
> Is there a less-overloaded code you could return?

The only other ones that I think would be close are:

       ENOTSUP         Operation not supported (POSIX.1)
       EPROTO          Protocol error (POSIX.1)
       ENOENT	       No such file or directory
       EFAULT	       Bad address

Feedback welcone.
 
> I have no issue with the patch other than that.
> 
> - Dave
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: GPIO: Fix probe() error return in gpio driver probes

[Ben Dooks]

On Sun, Dec 14, 2008 at 04:11:17PM -0800, David Brownell wrote:
> On Sunday 14 December 2008, Ben Dooks wrote:
> > Has anyone reveiwed this patch? Are there any comments, or can this
> > be commited at somepoint (even if it is during the next merge window)?
> 
> I was thinking that -EINVAL is almost the least informative
> diagnostic code possible, since so many places return it
> that it's usually hard to find out *which* invalid parameter
> triggered ...
> 
> Is there a less-overloaded code you could return?

The only other ones that I think would be close are:

       ENOTSUP         Operation not supported (POSIX.1)
       EPROTO          Protocol error (POSIX.1)
       ENOENT	       No such file or directory
       EFAULT	       Bad address

Feedback welcone.
 
> I have no issue with the patch other than that.
> 
> - Dave
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Ben (ben-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: GPIO: Fix probe() error return in gpio driver probes

[Ben Dooks]

On Mon, Dec 15, 2008 at 08:46:00AM +0100, Jean Delvare wrote:
> On Sun, 14 Dec 2008 16:11:17 -0800, David Brownell wrote:
> > On Sunday 14 December 2008, Ben Dooks wrote:
> > > Has anyone reveiwed this patch? Are there any comments, or can this
> > > be commited at somepoint (even if it is during the next merge window)?
> > 
> > I was thinking that -EINVAL is almost the least informative
> > diagnostic code possible, since so many places return it
> > that it's usually hard to find out *which* invalid parameter
> > triggered ...
> > 
> > Is there a less-overloaded code you could return?
> 
> -EINVAL sounds right to me, all that's really missing is dev_dbg()
> messages in the drivers to log what the exact problem was. 

It might be more acceptable to be dev_err(), that way it will get
printed no matter what debug options have been selected. If so, a
seperate patch is probably in order to make the change.

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: GPIO: Fix probe() error return in gpio driver probes

[Ben Dooks]

On Mon, Dec 15, 2008 at 08:46:00AM +0100, Jean Delvare wrote:
> On Sun, 14 Dec 2008 16:11:17 -0800, David Brownell wrote:
> > On Sunday 14 December 2008, Ben Dooks wrote:
> > > Has anyone reveiwed this patch? Are there any comments, or can this
> > > be commited at somepoint (even if it is during the next merge window)?
> > 
> > I was thinking that -EINVAL is almost the least informative
> > diagnostic code possible, since so many places return it
> > that it's usually hard to find out *which* invalid parameter
> > triggered ...
> > 
> > Is there a less-overloaded code you could return?
> 
> -EINVAL sounds right to me, all that's really missing is dev_dbg()
> messages in the drivers to log what the exact problem was. 

It might be more acceptable to be dev_err(), that way it will get
printed no matter what debug options have been selected. If so, a
seperate patch is probably in order to make the change.

-- 
Ben (ben-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: GPIO: Fix probe() error return in gpio driver probes

[Jean Delvare]

On Mon, 15 Dec 2008 10:16:16 +0000, Ben Dooks wrote:
> On Mon, Dec 15, 2008 at 08:46:00AM +0100, Jean Delvare wrote:
> > On Sun, 14 Dec 2008 16:11:17 -0800, David Brownell wrote:
> > > On Sunday 14 December 2008, Ben Dooks wrote:
> > > > Has anyone reveiwed this patch? Are there any comments, or can this
> > > > be commited at somepoint (even if it is during the next merge window)?
> > > 
> > > I was thinking that -EINVAL is almost the least informative
> > > diagnostic code possible, since so many places return it
> > > that it's usually hard to find out *which* invalid parameter
> > > triggered ...
> > > 
> > > Is there a less-overloaded code you could return?
> > 
> > -EINVAL sounds right to me, all that's really missing is dev_dbg()
> > messages in the drivers to log what the exact problem was. 
> 
> It might be more acceptable to be dev_err(), that way it will get
> printed no matter what debug options have been selected. If so, a
> seperate patch is probably in order to make the change.

As far as I can see, such errors would be caused by development-time
mistakes, so dev_dbg() seems appropriate. dev_err() would make the
binaries larger for all end-users.

-- 
Jean Delvare

Re: GPIO: Fix probe() error return in gpio driver probes

[Jean Delvare]

On Mon, 15 Dec 2008 10:16:16 +0000, Ben Dooks wrote:
> On Mon, Dec 15, 2008 at 08:46:00AM +0100, Jean Delvare wrote:
> > On Sun, 14 Dec 2008 16:11:17 -0800, David Brownell wrote:
> > > On Sunday 14 December 2008, Ben Dooks wrote:
> > > > Has anyone reveiwed this patch? Are there any comments, or can this
> > > > be commited at somepoint (even if it is during the next merge window)?
> > > 
> > > I was thinking that -EINVAL is almost the least informative
> > > diagnostic code possible, since so many places return it
> > > that it's usually hard to find out *which* invalid parameter
> > > triggered ...
> > > 
> > > Is there a less-overloaded code you could return?
> > 
> > -EINVAL sounds right to me, all that's really missing is dev_dbg()
> > messages in the drivers to log what the exact problem was. 
> 
> It might be more acceptable to be dev_err(), that way it will get
> printed no matter what debug options have been selected. If so, a
> seperate patch is probably in order to make the change.

As far as I can see, such errors would be caused by development-time
mistakes, so dev_dbg() seems appropriate. dev_err() would make the
binaries larger for all end-users.

-- 
Jean Delvare

Re: GPIO: Fix probe() error return in gpio driver probes

[David Brownell]

On Monday 15 December 2008, Jean Delvare wrote:
> 
> > > > I was thinking that -EINVAL is almost the least informative
> > > > diagnostic code possible, since so many places return it
> > > > that it's usually hard to find out *which* invalid parameter
> > > > triggered ...
> > > > 
> > > > Is there a less-overloaded code you could return?
> > > 
> > > -EINVAL sounds right to me, all that's really missing is dev_dbg()
> > > messages in the drivers to log what the exact problem was. 

Fair enough, though it just papers over how ambiguous -EINVAL is.


> > It might be more acceptable to be dev_err(), that way it will get
> > printed no matter what debug options have been selected. If so, a
> > seperate patch is probably in order to make the change.
> 
> As far as I can see, such errors would be caused by development-time
> mistakes, so dev_dbg() seems appropriate. dev_err() would make the
> binaries larger for all end-users.

Right, dev_dbg() is the way to go.  I'd ack a version of this patch
which pairs these -EINVAL changes with dev_dbg() messages to make
these problems less painful to track down.  dev_err() is much abused.

- Dave

Re: GPIO: Fix probe() error return in gpio driver probes

[David Brownell]

On Monday 15 December 2008, Jean Delvare wrote:
> 
> > > > I was thinking that -EINVAL is almost the least informative
> > > > diagnostic code possible, since so many places return it
> > > > that it's usually hard to find out *which* invalid parameter
> > > > triggered ...
> > > > 
> > > > Is there a less-overloaded code you could return?
> > > 
> > > -EINVAL sounds right to me, all that's really missing is dev_dbg()
> > > messages in the drivers to log what the exact problem was. 

Fair enough, though it just papers over how ambiguous -EINVAL is.


> > It might be more acceptable to be dev_err(), that way it will get
> > printed no matter what debug options have been selected. If so, a
> > seperate patch is probably in order to make the change.
> 
> As far as I can see, such errors would be caused by development-time
> mistakes, so dev_dbg() seems appropriate. dev_err() would make the
> binaries larger for all end-users.

Right, dev_dbg() is the way to go.  I'd ack a version of this patch
which pairs these -EINVAL changes with dev_dbg() messages to make
these problems less painful to track down.  dev_err() is much abused.

- Dave

Re: GPIO: Fix probe() error return in gpio driver probes

[Ben Dooks]

On Thu, Dec 18, 2008 at 10:16:27AM -0800, David Brownell wrote:
> On Monday 15 December 2008, Jean Delvare wrote:
> > 
> > > > > I was thinking that -EINVAL is almost the least informative
> > > > > diagnostic code possible, since so many places return it
> > > > > that it's usually hard to find out *which* invalid parameter
> > > > > triggered ...
> > > > > 
> > > > > Is there a less-overloaded code you could return?
> > > > 
> > > > -EINVAL sounds right to me, all that's really missing is dev_dbg()
> > > > messages in the drivers to log what the exact problem was. 
> 
> Fair enough, though it just papers over how ambiguous -EINVAL is.

Unforunately there's not a lot of choice in errno.h for other options.
 
> > > It might be more acceptable to be dev_err(), that way it will get
> > > printed no matter what debug options have been selected. If so, a
> > > seperate patch is probably in order to make the change.
> > 
> > As far as I can see, such errors would be caused by development-time
> > mistakes, so dev_dbg() seems appropriate. dev_err() would make the
> > binaries larger for all end-users.
> 
> Right, dev_dbg() is the way to go.  I'd ack a version of this patch
> which pairs these -EINVAL changes with dev_dbg() messages to make
> these problems less painful to track down.  dev_err() is much abused.

Ok, I'll try and sort that out for you as soon as possible.

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: GPIO: Fix probe() error return in gpio driver probes

[Ben Dooks]

On Thu, Dec 18, 2008 at 10:16:27AM -0800, David Brownell wrote:
> On Monday 15 December 2008, Jean Delvare wrote:
> > 
> > > > > I was thinking that -EINVAL is almost the least informative
> > > > > diagnostic code possible, since so many places return it
> > > > > that it's usually hard to find out *which* invalid parameter
> > > > > triggered ...
> > > > > 
> > > > > Is there a less-overloaded code you could return?
> > > > 
> > > > -EINVAL sounds right to me, all that's really missing is dev_dbg()
> > > > messages in the drivers to log what the exact problem was. 
> 
> Fair enough, though it just papers over how ambiguous -EINVAL is.

Unforunately there's not a lot of choice in errno.h for other options.
 
> > > It might be more acceptable to be dev_err(), that way it will get
> > > printed no matter what debug options have been selected. If so, a
> > > seperate patch is probably in order to make the change.
> > 
> > As far as I can see, such errors would be caused by development-time
> > mistakes, so dev_dbg() seems appropriate. dev_err() would make the
> > binaries larger for all end-users.
> 
> Right, dev_dbg() is the way to go.  I'd ack a version of this patch
> which pairs these -EINVAL changes with dev_dbg() messages to make
> these problems less painful to track down.  dev_err() is much abused.

Ok, I'll try and sort that out for you as soon as possible.

-- 
Ben (ben-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: GPIO: Fix probe() error return in gpio driver probes

[Ben Dooks]

On Wed, Jan 07, 2009 at 12:56:19PM +0000, ben@fluff.org.uk wrote:
> A number of drivers in drivers/gpio return -ENODEV when confronted
> with missing setup parameters such as the platform data. However,
> returning -ENODEV causes the driver layer to silently ignore the
> driver as it assumes the probe did not find anything and was only
> speculative.
> 
> To make life easier to discern why a driver is not being attached,
> change to returning -EINVAL, which is a better description of the
> fact that the driver data was not valid.
> 
> Also add a set of dev_dbg() statements to the error paths to provide
> an better explanation of the error as there may be more that one point
> in the driver.

sorry, sent from the wrong email address please ignore.
-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: GPIO: Fix probe() error return in gpio driver probes

[Ben Dooks]

On Wed, Jan 07, 2009 at 12:56:19PM +0000, ben-elnMNo+KYs3pIgCt6eIbzw@public.gmane.org wrote:
> A number of drivers in drivers/gpio return -ENODEV when confronted
> with missing setup parameters such as the platform data. However,
> returning -ENODEV causes the driver layer to silently ignore the
> driver as it assumes the probe did not find anything and was only
> speculative.
> 
> To make life easier to discern why a driver is not being attached,
> change to returning -EINVAL, which is a better description of the
> fact that the driver data was not valid.
> 
> Also add a set of dev_dbg() statements to the error paths to provide
> an better explanation of the error as there may be more that one point
> in the driver.

sorry, sent from the wrong email address please ignore.
-- 
Ben (ben-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

GPIO: Fix probe() error return in gpio driver probes

[Ben Dooks]

[-- Attachment #1: simtec/check-gpio-driver-return-codes.patch --]
[-- Type: text/plain, Size: 4055 bytes --]

A number of drivers in drivers/gpio return -ENODEV when confronted
with missing setup parameters such as the platform data. However,
returning -ENODEV causes the driver layer to silently ignore the
driver as it assumes the probe did not find anything and was only
speculative.

To make life easier to discern why a driver is not being attached,
change to returning -EINVAL, which is a better description of the
fact that the driver data was not valid.

Also add a set of dev_dbg() statements to the error paths to provide
an better explanation of the error as there may be more that one point
in the driver.

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Index: linux.git3/drivers/gpio/max7301.c
===================================================================
--- linux.git3.orig/drivers/gpio/max7301.c	2008-10-22 09:50:45.000000000 +0100
+++ linux.git3/drivers/gpio/max7301.c	2009-01-07 12:37:46.000000000 +0000
@@ -217,8 +217,10 @@ static int __devinit max7301_probe(struc
 	int i, ret;
 
 	pdata = spi->dev.platform_data;
-	if (!pdata || !pdata->base)
-		return -ENODEV;
+	if (!pdata || !pdata->base) {
+		dev_dbg(&spi->dev, "incorrect or missing platform data\n");
+		return -EINVAL;
+	}
 
 	/*
 	 * bits_per_word cannot be configured in platform data
Index: linux.git3/drivers/gpio/max732x.c
===================================================================
--- linux.git3.orig/drivers/gpio/max732x.c	2008-10-22 09:50:45.000000000 +0100
+++ linux.git3/drivers/gpio/max732x.c	2009-01-07 12:22:10.000000000 +0000
@@ -267,8 +267,10 @@ static int __devinit max732x_probe(struc
 	int ret, nr_port;
 
 	pdata = client->dev.platform_data;
-	if (pdata == NULL)
-		return -ENODEV;
+	if (pdata == NULL) {
+		dev_dbg(&client->dev, "no platform data\n");
+		return -EINVAL;
+	}
 
 	chip = kzalloc(sizeof(struct max732x_chip), GFP_KERNEL);
 	if (chip == NULL)
Index: linux.git3/drivers/gpio/mcp23s08.c
===================================================================
--- linux.git3.orig/drivers/gpio/mcp23s08.c	2008-10-22 09:50:45.000000000 +0100
+++ linux.git3/drivers/gpio/mcp23s08.c	2009-01-07 12:23:24.000000000 +0000
@@ -310,8 +310,10 @@ static int mcp23s08_probe(struct spi_dev
 	unsigned			base;
 
 	pdata = spi->dev.platform_data;
-	if (!pdata || !gpio_is_valid(pdata->base))
-		return -ENODEV;
+	if (!pdata || !gpio_is_valid(pdata->base)) {
+		dev_dbg(&spi->dev, "invalid or missing platform data\n");
+		return -EINVAL;
+	}
 
 	for (addr = 0; addr < 4; addr++) {
 		if (!pdata->chip[addr].is_present)
Index: linux.git3/drivers/gpio/pca953x.c
===================================================================
--- linux.git3.orig/drivers/gpio/pca953x.c	2008-10-22 09:50:45.000000000 +0100
+++ linux.git3/drivers/gpio/pca953x.c	2009-01-07 12:36:00.000000000 +0000
@@ -200,8 +200,10 @@ static int __devinit pca953x_probe(struc
 	int ret;
 
 	pdata = client->dev.platform_data;
-	if (pdata == NULL)
-		return -ENODEV;
+	if (pdata == NULL) {
+		dev_dbg(&client->dev, "no platform data\n");
+		return -EINVAL;
+	}
 
 	chip = kzalloc(sizeof(struct pca953x_chip), GFP_KERNEL);
 	if (chip == NULL)
Index: linux.git3/drivers/gpio/pcf857x.c
===================================================================
--- linux.git3.orig/drivers/gpio/pcf857x.c	2008-10-22 09:50:45.000000000 +0100
+++ linux.git3/drivers/gpio/pcf857x.c	2009-01-07 12:27:00.000000000 +0000
@@ -188,8 +188,10 @@ static int pcf857x_probe(struct i2c_clie
 	int				status;
 
 	pdata = client->dev.platform_data;
-	if (!pdata)
-		return -ENODEV;
+	if (!pdata) {
+		dev_dbg(&client->dev, "no platform data\n");
+		return -EINVAL;
+	}
 
 	/* Allocate, initialize, and register this gpio_chip. */
 	gpio = kzalloc(sizeof *gpio, GFP_KERNEL);
@@ -248,8 +250,10 @@ static int pcf857x_probe(struct i2c_clie
 		else
 			status = i2c_read_le16(client);
 
-	} else
-		status = -ENODEV;
+	} else {
+		dev_dbg(&client->dev, "unsupported number of gpios\n");
+		status = -EINVAL;
+	}
 
 	if (status < 0)
 		goto fail;

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

GPIO: Fix probe() error return in gpio driver probes

[ben]

[-- Attachment #1: simtec/check-gpio-driver-return-codes.patch --]
[-- Type: text/plain, Size: 4055 bytes --]

A number of drivers in drivers/gpio return -ENODEV when confronted
with missing setup parameters such as the platform data. However,
returning -ENODEV causes the driver layer to silently ignore the
driver as it assumes the probe did not find anything and was only
speculative.

To make life easier to discern why a driver is not being attached,
change to returning -EINVAL, which is a better description of the
fact that the driver data was not valid.

Also add a set of dev_dbg() statements to the error paths to provide
an better explanation of the error as there may be more that one point
in the driver.

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Index: linux.git3/drivers/gpio/max7301.c
===================================================================
--- linux.git3.orig/drivers/gpio/max7301.c	2008-10-22 09:50:45.000000000 +0100
+++ linux.git3/drivers/gpio/max7301.c	2009-01-07 12:37:46.000000000 +0000
@@ -217,8 +217,10 @@ static int __devinit max7301_probe(struc
 	int i, ret;
 
 	pdata = spi->dev.platform_data;
-	if (!pdata || !pdata->base)
-		return -ENODEV;
+	if (!pdata || !pdata->base) {
+		dev_dbg(&spi->dev, "incorrect or missing platform data\n");
+		return -EINVAL;
+	}
 
 	/*
 	 * bits_per_word cannot be configured in platform data
Index: linux.git3/drivers/gpio/max732x.c
===================================================================
--- linux.git3.orig/drivers/gpio/max732x.c	2008-10-22 09:50:45.000000000 +0100
+++ linux.git3/drivers/gpio/max732x.c	2009-01-07 12:22:10.000000000 +0000
@@ -267,8 +267,10 @@ static int __devinit max732x_probe(struc
 	int ret, nr_port;
 
 	pdata = client->dev.platform_data;
-	if (pdata == NULL)
-		return -ENODEV;
+	if (pdata == NULL) {
+		dev_dbg(&client->dev, "no platform data\n");
+		return -EINVAL;
+	}
 
 	chip = kzalloc(sizeof(struct max732x_chip), GFP_KERNEL);
 	if (chip == NULL)
Index: linux.git3/drivers/gpio/mcp23s08.c
===================================================================
--- linux.git3.orig/drivers/gpio/mcp23s08.c	2008-10-22 09:50:45.000000000 +0100
+++ linux.git3/drivers/gpio/mcp23s08.c	2009-01-07 12:23:24.000000000 +0000
@@ -310,8 +310,10 @@ static int mcp23s08_probe(struct spi_dev
 	unsigned			base;
 
 	pdata = spi->dev.platform_data;
-	if (!pdata || !gpio_is_valid(pdata->base))
-		return -ENODEV;
+	if (!pdata || !gpio_is_valid(pdata->base)) {
+		dev_dbg(&spi->dev, "invalid or missing platform data\n");
+		return -EINVAL;
+	}
 
 	for (addr = 0; addr < 4; addr++) {
 		if (!pdata->chip[addr].is_present)
Index: linux.git3/drivers/gpio/pca953x.c
===================================================================
--- linux.git3.orig/drivers/gpio/pca953x.c	2008-10-22 09:50:45.000000000 +0100
+++ linux.git3/drivers/gpio/pca953x.c	2009-01-07 12:36:00.000000000 +0000
@@ -200,8 +200,10 @@ static int __devinit pca953x_probe(struc
 	int ret;
 
 	pdata = client->dev.platform_data;
-	if (pdata == NULL)
-		return -ENODEV;
+	if (pdata == NULL) {
+		dev_dbg(&client->dev, "no platform data\n");
+		return -EINVAL;
+	}
 
 	chip = kzalloc(sizeof(struct pca953x_chip), GFP_KERNEL);
 	if (chip == NULL)
Index: linux.git3/drivers/gpio/pcf857x.c
===================================================================
--- linux.git3.orig/drivers/gpio/pcf857x.c	2008-10-22 09:50:45.000000000 +0100
+++ linux.git3/drivers/gpio/pcf857x.c	2009-01-07 12:27:00.000000000 +0000
@@ -188,8 +188,10 @@ static int pcf857x_probe(struct i2c_clie
 	int				status;
 
 	pdata = client->dev.platform_data;
-	if (!pdata)
-		return -ENODEV;
+	if (!pdata) {
+		dev_dbg(&client->dev, "no platform data\n");
+		return -EINVAL;
+	}
 
 	/* Allocate, initialize, and register this gpio_chip. */
 	gpio = kzalloc(sizeof *gpio, GFP_KERNEL);
@@ -248,8 +250,10 @@ static int pcf857x_probe(struct i2c_clie
 		else
 			status = i2c_read_le16(client);
 
-	} else
-		status = -ENODEV;
+	} else {
+		dev_dbg(&client->dev, "unsupported number of gpios\n");
+		status = -EINVAL;
+	}
 
 	if (status < 0)
 		goto fail;

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

GPIO: Fix probe() error return in gpio driver probes

[ben-elnMNo+KYs3pIgCt6eIbzw]

[-- Attachment #1: simtec/check-gpio-driver-return-codes.patch --]
[-- Type: text/plain, Size: 4115 bytes --]

A number of drivers in drivers/gpio return -ENODEV when confronted
with missing setup parameters such as the platform data. However,
returning -ENODEV causes the driver layer to silently ignore the
driver as it assumes the probe did not find anything and was only
speculative.

To make life easier to discern why a driver is not being attached,
change to returning -EINVAL, which is a better description of the
fact that the driver data was not valid.

Also add a set of dev_dbg() statements to the error paths to provide
an better explanation of the error as there may be more that one point
in the driver.

Signed-off-by: Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>
Index: linux.git3/drivers/gpio/max7301.c
===================================================================
--- linux.git3.orig/drivers/gpio/max7301.c	2008-10-22 09:50:45.000000000 +0100
+++ linux.git3/drivers/gpio/max7301.c	2009-01-07 12:37:46.000000000 +0000
@@ -217,8 +217,10 @@ static int __devinit max7301_probe(struc
 	int i, ret;
 
 	pdata = spi->dev.platform_data;
-	if (!pdata || !pdata->base)
-		return -ENODEV;
+	if (!pdata || !pdata->base) {
+		dev_dbg(&spi->dev, "incorrect or missing platform data\n");
+		return -EINVAL;
+	}
 
 	/*
 	 * bits_per_word cannot be configured in platform data
Index: linux.git3/drivers/gpio/max732x.c
===================================================================
--- linux.git3.orig/drivers/gpio/max732x.c	2008-10-22 09:50:45.000000000 +0100
+++ linux.git3/drivers/gpio/max732x.c	2009-01-07 12:22:10.000000000 +0000
@@ -267,8 +267,10 @@ static int __devinit max732x_probe(struc
 	int ret, nr_port;
 
 	pdata = client->dev.platform_data;
-	if (pdata == NULL)
-		return -ENODEV;
+	if (pdata == NULL) {
+		dev_dbg(&client->dev, "no platform data\n");
+		return -EINVAL;
+	}
 
 	chip = kzalloc(sizeof(struct max732x_chip), GFP_KERNEL);
 	if (chip == NULL)
Index: linux.git3/drivers/gpio/mcp23s08.c
===================================================================
--- linux.git3.orig/drivers/gpio/mcp23s08.c	2008-10-22 09:50:45.000000000 +0100
+++ linux.git3/drivers/gpio/mcp23s08.c	2009-01-07 12:23:24.000000000 +0000
@@ -310,8 +310,10 @@ static int mcp23s08_probe(struct spi_dev
 	unsigned			base;
 
 	pdata = spi->dev.platform_data;
-	if (!pdata || !gpio_is_valid(pdata->base))
-		return -ENODEV;
+	if (!pdata || !gpio_is_valid(pdata->base)) {
+		dev_dbg(&spi->dev, "invalid or missing platform data\n");
+		return -EINVAL;
+	}
 
 	for (addr = 0; addr < 4; addr++) {
 		if (!pdata->chip[addr].is_present)
Index: linux.git3/drivers/gpio/pca953x.c
===================================================================
--- linux.git3.orig/drivers/gpio/pca953x.c	2008-10-22 09:50:45.000000000 +0100
+++ linux.git3/drivers/gpio/pca953x.c	2009-01-07 12:36:00.000000000 +0000
@@ -200,8 +200,10 @@ static int __devinit pca953x_probe(struc
 	int ret;
 
 	pdata = client->dev.platform_data;
-	if (pdata == NULL)
-		return -ENODEV;
+	if (pdata == NULL) {
+		dev_dbg(&client->dev, "no platform data\n");
+		return -EINVAL;
+	}
 
 	chip = kzalloc(sizeof(struct pca953x_chip), GFP_KERNEL);
 	if (chip == NULL)
Index: linux.git3/drivers/gpio/pcf857x.c
===================================================================
--- linux.git3.orig/drivers/gpio/pcf857x.c	2008-10-22 09:50:45.000000000 +0100
+++ linux.git3/drivers/gpio/pcf857x.c	2009-01-07 12:27:00.000000000 +0000
@@ -188,8 +188,10 @@ static int pcf857x_probe(struct i2c_clie
 	int				status;
 
 	pdata = client->dev.platform_data;
-	if (!pdata)
-		return -ENODEV;
+	if (!pdata) {
+		dev_dbg(&client->dev, "no platform data\n");
+		return -EINVAL;
+	}
 
 	/* Allocate, initialize, and register this gpio_chip. */
 	gpio = kzalloc(sizeof *gpio, GFP_KERNEL);
@@ -248,8 +250,10 @@ static int pcf857x_probe(struct i2c_clie
 		else
 			status = i2c_read_le16(client);
 
-	} else
-		status = -ENODEV;
+	} else {
+		dev_dbg(&client->dev, "unsupported number of gpios\n");
+		status = -EINVAL;
+	}
 
 	if (status < 0)
 		goto fail;

-- 
Ben (ben-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'