GPIO: Fix probe() error return in gpio driver probes
Ben Dooks
> 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-...@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 (b...@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 majo...@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 (b...@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 majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Brownell
> 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
Jean Delvare
> 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
Ben Dooks
> 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 majo...@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 (b...@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
Ben Dooks
> 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 (b...@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
Jean Delvare
> 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
David Brownell
>
> > > > 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
Ben Dooks
> 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 (b...@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'