[PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[Stephen Warren]

Some devices use a single pin as both an IRQ and a GPIO. In that case,
irq_gpio is the GPIO ID for that pin. Not all drivers use this feature.
Where they do, and the use of this feature is optional, and the system
wishes to disable this feature, this field must be explicitly set to a
defined invalid GPIO ID, such as -1.

Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
v2: This patch is new. This updated series based on Arnd's comments that
this solution was a good idea.

Note that I leave on vacation for 2 weeks starting Friday afternoon. I
may have some email capabilities during this time, but will certainly be
slow to respond.

 include/linux/i2c.h |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 3fad485..b368097 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -192,6 +192,12 @@ struct i2c_driver {
  * @driver: device's driver, hence pointer to access routines
  * @dev: Driver model device node for the slave.
  * @irq: indicates the IRQ generated by this device (if any)
+ * @irq_gpio: some devices use a single pin as both an IRQ and a GPIO. In
+ *	that case, irq_gpio is the GPIO ID for that pin. Not all drivers
+ *	use this feature. Where they do, and the use of this feature is
+ *	optional, and the system wishes to disable this feature, this
+ *	field must be explicitly set to a defined invalid GPIO ID, such
+ *	as -1.
  * @detected: member of an i2c_driver.clients list or i2c-core's
  *	userspace_devices list
  *
@@ -209,6 +215,7 @@ struct i2c_client {
 	struct i2c_driver *driver;	/* and our access routines	*/
 	struct device dev;		/* the device structure		*/
 	int irq;			/* irq issued by device		*/
+	int irq_gpio;			/* gpio corresponding to irq	*/
 	struct list_head detected;
 };
 #define to_i2c_client(d) container_of(d, struct i2c_client, dev)
-- 
1.7.0.4

[PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[Stephen Warren]

Some devices use a single pin as both an IRQ and a GPIO. In that case,
irq_gpio is the GPIO ID for that pin. Not all drivers use this feature.
Where they do, and the use of this feature is optional, and the system
wishes to disable this feature, this field must be explicitly set to a
defined invalid GPIO ID, such as -1.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v2: This patch is new. This updated series based on Arnd's comments that
this solution was a good idea.

Note that I leave on vacation for 2 weeks starting Friday afternoon. I
may have some email capabilities during this time, but will certainly be
slow to respond.

 include/linux/i2c.h |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 3fad485..b368097 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -192,6 +192,12 @@ struct i2c_driver {
  * @driver: device's driver, hence pointer to access routines
  * @dev: Driver model device node for the slave.
  * @irq: indicates the IRQ generated by this device (if any)
+ * @irq_gpio: some devices use a single pin as both an IRQ and a GPIO. In
+ *	that case, irq_gpio is the GPIO ID for that pin. Not all drivers
+ *	use this feature. Where they do, and the use of this feature is
+ *	optional, and the system wishes to disable this feature, this
+ *	field must be explicitly set to a defined invalid GPIO ID, such
+ *	as -1.
  * @detected: member of an i2c_driver.clients list or i2c-core's
  *	userspace_devices list
  *
@@ -209,6 +215,7 @@ struct i2c_client {
 	struct i2c_driver *driver;	/* and our access routines	*/
 	struct device dev;		/* the device structure		*/
 	int irq;			/* irq issued by device		*/
+	int irq_gpio;			/* gpio corresponding to irq	*/
 	struct list_head detected;
 };
 #define to_i2c_client(d) container_of(d, struct i2c_client, dev)
-- 
1.7.0.4

[PATCH V2 2/4] staging:iio:magnetometer:ak8975 Don't use irq_to_gpio()

[Stephen Warren]

Tegra doesn't have irq_to_gpio() any more, and ak8975 is included in
tegra_defconfig. This causes a build failure.

Instead, obtain the GPIO ID corresponding to the chip's IRQ from the new
i2c_client field irq_gpio.

Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
v2: Obtain eoc_gpio from i2c_client, instead of hard-coding it as an
invalid value.

 drivers/staging/iio/magnetometer/ak8975.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/iio/magnetometer/ak8975.c b/drivers/staging/iio/magnetometer/ak8975.c
index a17fa9f..14076da 100644
--- a/drivers/staging/iio/magnetometer/ak8975.c
+++ b/drivers/staging/iio/magnetometer/ak8975.c
@@ -477,7 +477,7 @@ static int ak8975_probe(struct i2c_client *client,
 	int err;
 
 	/* Grab and set up the supplied GPIO. */
-	eoc_gpio = irq_to_gpio(client->irq);
+	eoc_gpio = client->irq_gpio;
 
 	/* We may not have a GPIO based IRQ to scan, that is fine, we will
 	   poll if so */
-- 
1.7.0.4

[PATCH V2 2/4] staging:iio:magnetometer:ak8975 Don't use irq_to_gpio()

[Stephen Warren]

Tegra doesn't have irq_to_gpio() any more, and ak8975 is included in
tegra_defconfig. This causes a build failure.

Instead, obtain the GPIO ID corresponding to the chip's IRQ from the new
i2c_client field irq_gpio.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v2: Obtain eoc_gpio from i2c_client, instead of hard-coding it as an
invalid value.

 drivers/staging/iio/magnetometer/ak8975.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/iio/magnetometer/ak8975.c b/drivers/staging/iio/magnetometer/ak8975.c
index a17fa9f..14076da 100644
--- a/drivers/staging/iio/magnetometer/ak8975.c
+++ b/drivers/staging/iio/magnetometer/ak8975.c
@@ -477,7 +477,7 @@ static int ak8975_probe(struct i2c_client *client,
 	int err;
 
 	/* Grab and set up the supplied GPIO. */
-	eoc_gpio = irq_to_gpio(client->irq);
+	eoc_gpio = client->irq_gpio;
 
 	/* We may not have a GPIO based IRQ to scan, that is fine, we will
 	   poll if so */
-- 
1.7.0.4

[PATCH V2 3/4] staging:iio:magnetometer:ak8975: Don't assume 0 is an invalid GPIO

[Stephen Warren]

gpio_is_valid() is the defined mechanism to determine whether a GPIO is
valid. Use this instead of assuming that 0 is an invalid GPIO.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 drivers/staging/iio/magnetometer/ak8975.c |   11 +++++------
 1 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/iio/magnetometer/ak8975.c b/drivers/staging/iio/magnetometer/ak8975.c
index 14076da..0dfdf50 100644
--- a/drivers/staging/iio/magnetometer/ak8975.c
+++ b/drivers/staging/iio/magnetometer/ak8975.c
@@ -373,7 +373,7 @@ static int ak8975_read_axis(struct iio_dev *indio_dev, int index, int *val)
 	}
 
 	/* Wait for the conversion to complete. */
-	if (data->eoc_gpio)
+	if (gpio_is_valid(data->eoc_gpio))
 		ret = wait_conversion_complete_gpio(data);
 	else
 		ret = wait_conversion_complete_polled(data);
@@ -481,7 +481,7 @@ static int ak8975_probe(struct i2c_client *client,
 
 	/* We may not have a GPIO based IRQ to scan, that is fine, we will
 	   poll if so */
-	if (eoc_gpio > 0) {
+	if (gpio_is_valid(eoc_gpio)) {
 		err = gpio_request(eoc_gpio, "ak_8975");
 		if (err < 0) {
 			dev_err(&client->dev,
@@ -497,8 +497,7 @@ static int ak8975_probe(struct i2c_client *client,
 						eoc_gpio, err);
 			goto exit_gpio;
 		}
-	} else
-		eoc_gpio = 0;	/* No GPIO available */
+	}
 
 	/* Register with IIO */
 	indio_dev = iio_allocate_device(sizeof(*data));
@@ -534,7 +533,7 @@ static int ak8975_probe(struct i2c_client *client,
 exit_free_iio:
 	iio_free_device(indio_dev);
 exit_gpio:
-	if (eoc_gpio)
+	if (gpio_is_valid(eoc_gpio))
 		gpio_free(eoc_gpio);
 exit:
 	return err;
@@ -549,7 +548,7 @@ static int ak8975_remove(struct i2c_client *client)
 	iio_device_unregister(indio_dev);
 	iio_free_device(indio_dev);
 
-	if (eoc_gpio)
+	if (gpio_is_valid(eoc_gpio))
 		gpio_free(eoc_gpio);
 
 	return 0;
-- 
1.7.0.4

[PATCH V2 3/4] staging:iio:magnetometer:ak8975: Don't assume 0 is an invalid GPIO

[Stephen Warren]

gpio_is_valid() is the defined mechanism to determine whether a GPIO is
valid. Use this instead of assuming that 0 is an invalid GPIO.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 drivers/staging/iio/magnetometer/ak8975.c |   11 +++++------
 1 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/iio/magnetometer/ak8975.c b/drivers/staging/iio/magnetometer/ak8975.c
index 14076da..0dfdf50 100644
--- a/drivers/staging/iio/magnetometer/ak8975.c
+++ b/drivers/staging/iio/magnetometer/ak8975.c
@@ -373,7 +373,7 @@ static int ak8975_read_axis(struct iio_dev *indio_dev, int index, int *val)
 	}
 
 	/* Wait for the conversion to complete. */
-	if (data->eoc_gpio)
+	if (gpio_is_valid(data->eoc_gpio))
 		ret = wait_conversion_complete_gpio(data);
 	else
 		ret = wait_conversion_complete_polled(data);
@@ -481,7 +481,7 @@ static int ak8975_probe(struct i2c_client *client,
 
 	/* We may not have a GPIO based IRQ to scan, that is fine, we will
 	   poll if so */
-	if (eoc_gpio > 0) {
+	if (gpio_is_valid(eoc_gpio)) {
 		err = gpio_request(eoc_gpio, "ak_8975");
 		if (err < 0) {
 			dev_err(&client->dev,
@@ -497,8 +497,7 @@ static int ak8975_probe(struct i2c_client *client,
 						eoc_gpio, err);
 			goto exit_gpio;
 		}
-	} else
-		eoc_gpio = 0;	/* No GPIO available */
+	}
 
 	/* Register with IIO */
 	indio_dev = iio_allocate_device(sizeof(*data));
@@ -534,7 +533,7 @@ static int ak8975_probe(struct i2c_client *client,
 exit_free_iio:
 	iio_free_device(indio_dev);
 exit_gpio:
-	if (eoc_gpio)
+	if (gpio_is_valid(eoc_gpio))
 		gpio_free(eoc_gpio);
 exit:
 	return err;
@@ -549,7 +548,7 @@ static int ak8975_remove(struct i2c_client *client)
 	iio_device_unregister(indio_dev);
 	iio_free_device(indio_dev);
 
-	if (eoc_gpio)
+	if (gpio_is_valid(eoc_gpio))
 		gpio_free(eoc_gpio);
 
 	return 0;
-- 
1.7.0.4

[PATCH V2 4/4] staging:iio:magnetometer:ak8975: Fix probe() error-handling

[Stephen Warren]

Fix ak8975_probe() to jump to the appropriate exit labels when an error
occurs. With the previous code, some cleanup actions were being skipped
for some error conditions.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 drivers/staging/iio/magnetometer/ak8975.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/iio/magnetometer/ak8975.c b/drivers/staging/iio/magnetometer/ak8975.c
index 0dfdf50..cc20e8d 100644
--- a/drivers/staging/iio/magnetometer/ak8975.c
+++ b/drivers/staging/iio/magnetometer/ak8975.c
@@ -510,7 +510,7 @@ static int ak8975_probe(struct i2c_client *client,
 	err = ak8975_setup(client);
 	if (err < 0) {
 		dev_err(&client->dev, "AK8975 initialization fails\n");
-		goto exit_gpio;
+		goto exit_free_iio;
 	}
 
 	i2c_set_clientdata(client, indio_dev);
-- 
1.7.0.4

[PATCH V2 4/4] staging:iio:magnetometer:ak8975: Fix probe() error-handling

[Stephen Warren]

Fix ak8975_probe() to jump to the appropriate exit labels when an error
occurs. With the previous code, some cleanup actions were being skipped
for some error conditions.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 drivers/staging/iio/magnetometer/ak8975.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/iio/magnetometer/ak8975.c b/drivers/staging/iio/magnetometer/ak8975.c
index 0dfdf50..cc20e8d 100644
--- a/drivers/staging/iio/magnetometer/ak8975.c
+++ b/drivers/staging/iio/magnetometer/ak8975.c
@@ -510,7 +510,7 @@ static int ak8975_probe(struct i2c_client *client,
 	err = ak8975_setup(client);
 	if (err < 0) {
 		dev_err(&client->dev, "AK8975 initialization fails\n");
-		goto exit_gpio;
+		goto exit_free_iio;
 	}
 
 	i2c_set_clientdata(client, indio_dev);
-- 
1.7.0.4

[PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[Stephen Warren]

Some devices use a single pin as both an IRQ and a GPIO. In that case,
irq_gpio is the GPIO ID for that pin. Not all drivers use this feature.
Where they do, and the use of this feature is optional, and the system
wishes to disable this feature, this field must be explicitly set to a
defined invalid GPIO ID, such as -1.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v2: This patch is new. This updated series based on Arnd's comments that
this solution was a good idea.

Note that I leave on vacation for 2 weeks starting Friday afternoon. I
may have some email capabilities during this time, but will certainly be
slow to respond.

 include/linux/i2c.h |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 3fad485..b368097 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -192,6 +192,12 @@ struct i2c_driver {
  * @driver: device's driver, hence pointer to access routines
  * @dev: Driver model device node for the slave.
  * @irq: indicates the IRQ generated by this device (if any)
+ * @irq_gpio: some devices use a single pin as both an IRQ and a GPIO. In
+ *	that case, irq_gpio is the GPIO ID for that pin. Not all drivers
+ *	use this feature. Where they do, and the use of this feature is
+ *	optional, and the system wishes to disable this feature, this
+ *	field must be explicitly set to a defined invalid GPIO ID, such
+ *	as -1.
  * @detected: member of an i2c_driver.clients list or i2c-core's
  *	userspace_devices list
  *
@@ -209,6 +215,7 @@ struct i2c_client {
 	struct i2c_driver *driver;	/* and our access routines	*/
 	struct device dev;		/* the device structure		*/
 	int irq;			/* irq issued by device		*/
+	int irq_gpio;			/* gpio corresponding to irq	*/
 	struct list_head detected;
 };
 #define to_i2c_client(d) container_of(d, struct i2c_client, dev)
-- 
1.7.0.4

[PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[Stephen Warren]

Some devices use a single pin as both an IRQ and a GPIO. In that case,
irq_gpio is the GPIO ID for that pin. Not all drivers use this feature.
Where they do, and the use of this feature is optional, and the system
wishes to disable this feature, this field must be explicitly set to a
defined invalid GPIO ID, such as -1.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v2: This patch is new. This updated series based on Arnd's comments that
this solution was a good idea.

Note that I leave on vacation for 2 weeks starting Friday afternoon. I
may have some email capabilities during this time, but will certainly be
slow to respond.

 include/linux/i2c.h |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 3fad485..b368097 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -192,6 +192,12 @@ struct i2c_driver {
  * @driver: device's driver, hence pointer to access routines
  * @dev: Driver model device node for the slave.
  * @irq: indicates the IRQ generated by this device (if any)
+ * @irq_gpio: some devices use a single pin as both an IRQ and a GPIO. In
+ *	that case, irq_gpio is the GPIO ID for that pin. Not all drivers
+ *	use this feature. Where they do, and the use of this feature is
+ *	optional, and the system wishes to disable this feature, this
+ *	field must be explicitly set to a defined invalid GPIO ID, such
+ *	as -1.
  * @detected: member of an i2c_driver.clients list or i2c-core's
  *	userspace_devices list
  *
@@ -209,6 +215,7 @@ struct i2c_client {
 	struct i2c_driver *driver;	/* and our access routines	*/
 	struct device dev;		/* the device structure		*/
 	int irq;			/* irq issued by device		*/
+	int irq_gpio;			/* gpio corresponding to irq	*/
 	struct list_head detected;
 };
 #define to_i2c_client(d) container_of(d, struct i2c_client, dev)
-- 
1.7.0.4

[PATCH V2 2/4] staging:iio:magnetometer:ak8975 Don't use irq_to_gpio()

[Stephen Warren]

Tegra doesn't have irq_to_gpio() any more, and ak8975 is included in
tegra_defconfig. This causes a build failure.

Instead, obtain the GPIO ID corresponding to the chip's IRQ from the new
i2c_client field irq_gpio.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v2: Obtain eoc_gpio from i2c_client, instead of hard-coding it as an
invalid value.

 drivers/staging/iio/magnetometer/ak8975.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/iio/magnetometer/ak8975.c b/drivers/staging/iio/magnetometer/ak8975.c
index a17fa9f..14076da 100644
--- a/drivers/staging/iio/magnetometer/ak8975.c
+++ b/drivers/staging/iio/magnetometer/ak8975.c
@@ -477,7 +477,7 @@ static int ak8975_probe(struct i2c_client *client,
 	int err;
 
 	/* Grab and set up the supplied GPIO. */
-	eoc_gpio = irq_to_gpio(client->irq);
+	eoc_gpio = client->irq_gpio;
 
 	/* We may not have a GPIO based IRQ to scan, that is fine, we will
 	   poll if so */
-- 
1.7.0.4

[PATCH V2 2/4] staging:iio:magnetometer:ak8975 Don't use irq_to_gpio()

[Stephen Warren]

Tegra doesn't have irq_to_gpio() any more, and ak8975 is included in
tegra_defconfig. This causes a build failure.

Instead, obtain the GPIO ID corresponding to the chip's IRQ from the new
i2c_client field irq_gpio.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v2: Obtain eoc_gpio from i2c_client, instead of hard-coding it as an
invalid value.

 drivers/staging/iio/magnetometer/ak8975.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/iio/magnetometer/ak8975.c b/drivers/staging/iio/magnetometer/ak8975.c
index a17fa9f..14076da 100644
--- a/drivers/staging/iio/magnetometer/ak8975.c
+++ b/drivers/staging/iio/magnetometer/ak8975.c
@@ -477,7 +477,7 @@ static int ak8975_probe(struct i2c_client *client,
 	int err;
 
 	/* Grab and set up the supplied GPIO. */
-	eoc_gpio = irq_to_gpio(client->irq);
+	eoc_gpio = client->irq_gpio;
 
 	/* We may not have a GPIO based IRQ to scan, that is fine, we will
 	   poll if so */
-- 
1.7.0.4

[PATCH V2 3/4] staging:iio:magnetometer:ak8975: Don't assume 0 is an invalid GPIO

[Stephen Warren]

gpio_is_valid() is the defined mechanism to determine whether a GPIO is
valid. Use this instead of assuming that 0 is an invalid GPIO.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 drivers/staging/iio/magnetometer/ak8975.c |   11 +++++------
 1 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/iio/magnetometer/ak8975.c b/drivers/staging/iio/magnetometer/ak8975.c
index 14076da..0dfdf50 100644
--- a/drivers/staging/iio/magnetometer/ak8975.c
+++ b/drivers/staging/iio/magnetometer/ak8975.c
@@ -373,7 +373,7 @@ static int ak8975_read_axis(struct iio_dev *indio_dev, int index, int *val)
 	}
 
 	/* Wait for the conversion to complete. */
-	if (data->eoc_gpio)
+	if (gpio_is_valid(data->eoc_gpio))
 		ret = wait_conversion_complete_gpio(data);
 	else
 		ret = wait_conversion_complete_polled(data);
@@ -481,7 +481,7 @@ static int ak8975_probe(struct i2c_client *client,
 
 	/* We may not have a GPIO based IRQ to scan, that is fine, we will
 	   poll if so */
-	if (eoc_gpio > 0) {
+	if (gpio_is_valid(eoc_gpio)) {
 		err = gpio_request(eoc_gpio, "ak_8975");
 		if (err < 0) {
 			dev_err(&client->dev,
@@ -497,8 +497,7 @@ static int ak8975_probe(struct i2c_client *client,
 						eoc_gpio, err);
 			goto exit_gpio;
 		}
-	} else
-		eoc_gpio = 0;	/* No GPIO available */
+	}
 
 	/* Register with IIO */
 	indio_dev = iio_allocate_device(sizeof(*data));
@@ -534,7 +533,7 @@ static int ak8975_probe(struct i2c_client *client,
 exit_free_iio:
 	iio_free_device(indio_dev);
 exit_gpio:
-	if (eoc_gpio)
+	if (gpio_is_valid(eoc_gpio))
 		gpio_free(eoc_gpio);
 exit:
 	return err;
@@ -549,7 +548,7 @@ static int ak8975_remove(struct i2c_client *client)
 	iio_device_unregister(indio_dev);
 	iio_free_device(indio_dev);
 
-	if (eoc_gpio)
+	if (gpio_is_valid(eoc_gpio))
 		gpio_free(eoc_gpio);
 
 	return 0;
-- 
1.7.0.4

[PATCH V2 3/4] staging:iio:magnetometer:ak8975: Don't assume 0 is an invalid GPIO

[Stephen Warren]

gpio_is_valid() is the defined mechanism to determine whether a GPIO is
valid. Use this instead of assuming that 0 is an invalid GPIO.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 drivers/staging/iio/magnetometer/ak8975.c |   11 +++++------
 1 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/iio/magnetometer/ak8975.c b/drivers/staging/iio/magnetometer/ak8975.c
index 14076da..0dfdf50 100644
--- a/drivers/staging/iio/magnetometer/ak8975.c
+++ b/drivers/staging/iio/magnetometer/ak8975.c
@@ -373,7 +373,7 @@ static int ak8975_read_axis(struct iio_dev *indio_dev, int index, int *val)
 	}
 
 	/* Wait for the conversion to complete. */
-	if (data->eoc_gpio)
+	if (gpio_is_valid(data->eoc_gpio))
 		ret = wait_conversion_complete_gpio(data);
 	else
 		ret = wait_conversion_complete_polled(data);
@@ -481,7 +481,7 @@ static int ak8975_probe(struct i2c_client *client,
 
 	/* We may not have a GPIO based IRQ to scan, that is fine, we will
 	   poll if so */
-	if (eoc_gpio > 0) {
+	if (gpio_is_valid(eoc_gpio)) {
 		err = gpio_request(eoc_gpio, "ak_8975");
 		if (err < 0) {
 			dev_err(&client->dev,
@@ -497,8 +497,7 @@ static int ak8975_probe(struct i2c_client *client,
 						eoc_gpio, err);
 			goto exit_gpio;
 		}
-	} else
-		eoc_gpio = 0;	/* No GPIO available */
+	}
 
 	/* Register with IIO */
 	indio_dev = iio_allocate_device(sizeof(*data));
@@ -534,7 +533,7 @@ static int ak8975_probe(struct i2c_client *client,
 exit_free_iio:
 	iio_free_device(indio_dev);
 exit_gpio:
-	if (eoc_gpio)
+	if (gpio_is_valid(eoc_gpio))
 		gpio_free(eoc_gpio);
 exit:
 	return err;
@@ -549,7 +548,7 @@ static int ak8975_remove(struct i2c_client *client)
 	iio_device_unregister(indio_dev);
 	iio_free_device(indio_dev);
 
-	if (eoc_gpio)
+	if (gpio_is_valid(eoc_gpio))
 		gpio_free(eoc_gpio);
 
 	return 0;
-- 
1.7.0.4

[PATCH V2 4/4] staging:iio:magnetometer:ak8975: Fix probe() error-handling

[Stephen Warren]

Fix ak8975_probe() to jump to the appropriate exit labels when an error
occurs. With the previous code, some cleanup actions were being skipped
for some error conditions.

Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 drivers/staging/iio/magnetometer/ak8975.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/iio/magnetometer/ak8975.c b/drivers/staging/iio/magnetometer/ak8975.c
index 0dfdf50..cc20e8d 100644
--- a/drivers/staging/iio/magnetometer/ak8975.c
+++ b/drivers/staging/iio/magnetometer/ak8975.c
@@ -510,7 +510,7 @@ static int ak8975_probe(struct i2c_client *client,
 	err = ak8975_setup(client);
 	if (err < 0) {
 		dev_err(&client->dev, "AK8975 initialization fails\n");
-		goto exit_gpio;
+		goto exit_free_iio;
 	}
 
 	i2c_set_clientdata(client, indio_dev);
-- 
1.7.0.4

[PATCH V2 4/4] staging:iio:magnetometer:ak8975: Fix probe() error-handling

[Stephen Warren]

Fix ak8975_probe() to jump to the appropriate exit labels when an error
occurs. With the previous code, some cleanup actions were being skipped
for some error conditions.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 drivers/staging/iio/magnetometer/ak8975.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/iio/magnetometer/ak8975.c b/drivers/staging/iio/magnetometer/ak8975.c
index 0dfdf50..cc20e8d 100644
--- a/drivers/staging/iio/magnetometer/ak8975.c
+++ b/drivers/staging/iio/magnetometer/ak8975.c
@@ -510,7 +510,7 @@ static int ak8975_probe(struct i2c_client *client,
 	err = ak8975_setup(client);
 	if (err < 0) {
 		dev_err(&client->dev, "AK8975 initialization fails\n");
-		goto exit_gpio;
+		goto exit_free_iio;
 	}
 
 	i2c_set_clientdata(client, indio_dev);
-- 
1.7.0.4

Re: [PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[Mark Brown]

On Thu, Sep 01, 2011 at 10:52:41AM -0600, Stephen Warren wrote:
> Some devices use a single pin as both an IRQ and a GPIO. In that case,
> irq_gpio is the GPIO ID for that pin. Not all drivers use this feature.
> Where they do, and the use of this feature is optional, and the system
> wishes to disable this feature, this field must be explicitly set to a
> defined invalid GPIO ID, such as -1.
> 
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

SPI could also benefit from this.

Re: [PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[Mark Brown]

On Thu, Sep 01, 2011 at 10:52:41AM -0600, Stephen Warren wrote:
> Some devices use a single pin as both an IRQ and a GPIO. In that case,
> irq_gpio is the GPIO ID for that pin. Not all drivers use this feature.
> Where they do, and the use of this feature is optional, and the system
> wishes to disable this feature, this field must be explicitly set to a
> defined invalid GPIO ID, such as -1.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>

SPI could also benefit from this.

Re: [PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[Arnd Bergmann]

On Thursday 01 September 2011 10:52:37 Stephen Warren wrote:
> Some devices use a single pin as both an IRQ and a GPIO. In that case,
> irq_gpio is the GPIO ID for that pin. Not all drivers use this feature.
> Where they do, and the use of this feature is optional, and the system
> wishes to disable this feature, this field must be explicitly set to a
> defined invalid GPIO ID, such as -1.
> 
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> v2: This patch is new. This updated series based on Arnd's comments that
> this solution was a good idea.

Looks very good to me (the whole series).

	Arnd

Re: [PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[Arnd Bergmann]

On Thursday 01 September 2011 10:52:37 Stephen Warren wrote:
> Some devices use a single pin as both an IRQ and a GPIO. In that case,
> irq_gpio is the GPIO ID for that pin. Not all drivers use this feature.
> Where they do, and the use of this feature is optional, and the system
> wishes to disable this feature, this field must be explicitly set to a
> defined invalid GPIO ID, such as -1.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> v2: This patch is new. This updated series based on Arnd's comments that
> this solution was a good idea.

Looks very good to me (the whole series).

	Arnd

Re: [PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[Jonathan Cameron]

On 09/01/11 17:52, Stephen Warren wrote:
> Some devices use a single pin as both an IRQ and a GPIO. In that case,
> irq_gpio is the GPIO ID for that pin. Not all drivers use this feature.
> Where they do, and the use of this feature is optional, and the system
> wishes to disable this feature, this field must be explicitly set to a
> defined invalid GPIO ID, such as -1.
Why make it specifically an irq related gpio?  Might as well just call it
gpio then it can be used for cases where it never corresponds to an irq
such as capture trigger pins.

Otherwise I'd be happy to see this go in.
> 
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> v2: This patch is new. This updated series based on Arnd's comments that
> this solution was a good idea.
> 
> Note that I leave on vacation for 2 weeks starting Friday afternoon. I
> may have some email capabilities during this time, but will certainly be
> slow to respond.
> 
>  include/linux/i2c.h |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index 3fad485..b368097 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -192,6 +192,12 @@ struct i2c_driver {
>   * @driver: device's driver, hence pointer to access routines
>   * @dev: Driver model device node for the slave.
>   * @irq: indicates the IRQ generated by this device (if any)
> + * @irq_gpio: some devices use a single pin as both an IRQ and a GPIO. In
> + *	that case, irq_gpio is the GPIO ID for that pin. Not all drivers
> + *	use this feature. Where they do, and the use of this feature is
> + *	optional, and the system wishes to disable this feature, this
> + *	field must be explicitly set to a defined invalid GPIO ID, such
> + *	as -1.
>   * @detected: member of an i2c_driver.clients list or i2c-core's
>   *	userspace_devices list
>   *
> @@ -209,6 +215,7 @@ struct i2c_client {
>  	struct i2c_driver *driver;	/* and our access routines	*/
>  	struct device dev;		/* the device structure		*/
>  	int irq;			/* irq issued by device		*/
> +	int irq_gpio;			/* gpio corresponding to irq	*/
>  	struct list_head detected;
>  };
>  #define to_i2c_client(d) container_of(d, struct i2c_client, dev)

Re: [PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[Jonathan Cameron]

On 09/01/11 17:52, Stephen Warren wrote:
> Some devices use a single pin as both an IRQ and a GPIO. In that case,
> irq_gpio is the GPIO ID for that pin. Not all drivers use this feature.
> Where they do, and the use of this feature is optional, and the system
> wishes to disable this feature, this field must be explicitly set to a
> defined invalid GPIO ID, such as -1.
Why make it specifically an irq related gpio?  Might as well just call it
gpio then it can be used for cases where it never corresponds to an irq
such as capture trigger pins.

Otherwise I'd be happy to see this go in.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> v2: This patch is new. This updated series based on Arnd's comments that
> this solution was a good idea.
> 
> Note that I leave on vacation for 2 weeks starting Friday afternoon. I
> may have some email capabilities during this time, but will certainly be
> slow to respond.
> 
>  include/linux/i2c.h |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index 3fad485..b368097 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -192,6 +192,12 @@ struct i2c_driver {
>   * @driver: device's driver, hence pointer to access routines
>   * @dev: Driver model device node for the slave.
>   * @irq: indicates the IRQ generated by this device (if any)
> + * @irq_gpio: some devices use a single pin as both an IRQ and a GPIO. In
> + *	that case, irq_gpio is the GPIO ID for that pin. Not all drivers
> + *	use this feature. Where they do, and the use of this feature is
> + *	optional, and the system wishes to disable this feature, this
> + *	field must be explicitly set to a defined invalid GPIO ID, such
> + *	as -1.
>   * @detected: member of an i2c_driver.clients list or i2c-core's
>   *	userspace_devices list
>   *
> @@ -209,6 +215,7 @@ struct i2c_client {
>  	struct i2c_driver *driver;	/* and our access routines	*/
>  	struct device dev;		/* the device structure		*/
>  	int irq;			/* irq issued by device		*/
> +	int irq_gpio;			/* gpio corresponding to irq	*/
>  	struct list_head detected;
>  };
>  #define to_i2c_client(d) container_of(d, struct i2c_client, dev)

Re: [PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[Jonathan Cameron]

On 09/02/11 09:48, Jonathan Cameron wrote:
> On 09/01/11 17:52, Stephen Warren wrote:
>> Some devices use a single pin as both an IRQ and a GPIO. In that case,
>> irq_gpio is the GPIO ID for that pin. Not all drivers use this feature.
>> Where they do, and the use of this feature is optional, and the system
>> wishes to disable this feature, this field must be explicitly set to a
>> defined invalid GPIO ID, such as -1.
> Why make it specifically an irq related gpio?  Might as well just call it
> gpio then it can be used for cases where it never corresponds to an irq
> such as capture trigger pins.
> 
> Otherwise I'd be happy to see this go in.
oops, should have taken a closer look.  For i2c devices specified by i2c_board_info
structs there is no way of actually specifying this value.
>>
>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>> ---
>> v2: This patch is new. This updated series based on Arnd's comments that
>> this solution was a good idea.
>>
>> Note that I leave on vacation for 2 weeks starting Friday afternoon. I
>> may have some email capabilities during this time, but will certainly be
>> slow to respond.
>>
>>  include/linux/i2c.h |    7 +++++++
>>  1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
>> index 3fad485..b368097 100644
>> --- a/include/linux/i2c.h
>> +++ b/include/linux/i2c.h
>> @@ -192,6 +192,12 @@ struct i2c_driver {
>>   * @driver: device's driver, hence pointer to access routines
>>   * @dev: Driver model device node for the slave.
>>   * @irq: indicates the IRQ generated by this device (if any)
>> + * @irq_gpio: some devices use a single pin as both an IRQ and a GPIO. In
>> + *	that case, irq_gpio is the GPIO ID for that pin. Not all drivers
>> + *	use this feature. Where they do, and the use of this feature is
>> + *	optional, and the system wishes to disable this feature, this
>> + *	field must be explicitly set to a defined invalid GPIO ID, such
>> + *	as -1.
>>   * @detected: member of an i2c_driver.clients list or i2c-core's
>>   *	userspace_devices list
>>   *
>> @@ -209,6 +215,7 @@ struct i2c_client {
>>  	struct i2c_driver *driver;	/* and our access routines	*/
>>  	struct device dev;		/* the device structure		*/
>>  	int irq;			/* irq issued by device		*/
>> +	int irq_gpio;			/* gpio corresponding to irq	*/
>>  	struct list_head detected;
>>  };
>>  #define to_i2c_client(d) container_of(d, struct i2c_client, dev)
> 

Re: [PATCH V2 3/4] staging:iio:magnetometer:ak8975: Don't assume 0 is an invalid GPIO

[Jonathan Cameron]

On 09/01/11 17:52, Stephen Warren wrote:
> gpio_is_valid() is the defined mechanism to determine whether a GPIO is
> valid. Use this instead of assuming that 0 is an invalid GPIO.
> 
This one is unchanged so you should probably have carried acks from v1.
Anyhow,
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Acked-by: Jonathan Cameron <jic23-KWPb1pKIrIJaa/9Udqfwiw@public.gmane.org>
> ---
>  drivers/staging/iio/magnetometer/ak8975.c |   11 +++++------
>  1 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/iio/magnetometer/ak8975.c b/drivers/staging/iio/magnetometer/ak8975.c
> index 14076da..0dfdf50 100644
> --- a/drivers/staging/iio/magnetometer/ak8975.c
> +++ b/drivers/staging/iio/magnetometer/ak8975.c
> @@ -373,7 +373,7 @@ static int ak8975_read_axis(struct iio_dev *indio_dev, int index, int *val)
>  	}
>  
>  	/* Wait for the conversion to complete. */
> -	if (data->eoc_gpio)
> +	if (gpio_is_valid(data->eoc_gpio))
>  		ret = wait_conversion_complete_gpio(data);
>  	else
>  		ret = wait_conversion_complete_polled(data);
> @@ -481,7 +481,7 @@ static int ak8975_probe(struct i2c_client *client,
>  
>  	/* We may not have a GPIO based IRQ to scan, that is fine, we will
>  	   poll if so */
> -	if (eoc_gpio > 0) {
> +	if (gpio_is_valid(eoc_gpio)) {
>  		err = gpio_request(eoc_gpio, "ak_8975");
>  		if (err < 0) {
>  			dev_err(&client->dev,
> @@ -497,8 +497,7 @@ static int ak8975_probe(struct i2c_client *client,
>  						eoc_gpio, err);
>  			goto exit_gpio;
>  		}
> -	} else
> -		eoc_gpio = 0;	/* No GPIO available */
> +	}
>  
>  	/* Register with IIO */
>  	indio_dev = iio_allocate_device(sizeof(*data));
> @@ -534,7 +533,7 @@ static int ak8975_probe(struct i2c_client *client,
>  exit_free_iio:
>  	iio_free_device(indio_dev);
>  exit_gpio:
> -	if (eoc_gpio)
> +	if (gpio_is_valid(eoc_gpio))
>  		gpio_free(eoc_gpio);
>  exit:
>  	return err;
> @@ -549,7 +548,7 @@ static int ak8975_remove(struct i2c_client *client)
>  	iio_device_unregister(indio_dev);
>  	iio_free_device(indio_dev);
>  
> -	if (eoc_gpio)
> +	if (gpio_is_valid(eoc_gpio))
>  		gpio_free(eoc_gpio);
>  
>  	return 0;

Re: [PATCH V2 3/4] staging:iio:magnetometer:ak8975: Don't assume 0 is an invalid GPIO

[Jonathan Cameron]

On 09/01/11 17:52, Stephen Warren wrote:
> gpio_is_valid() is the defined mechanism to determine whether a GPIO is
> valid. Use this instead of assuming that 0 is an invalid GPIO.
> 
This one is unchanged so you should probably have carried acks from v1.
Anyhow,
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
> ---
>  drivers/staging/iio/magnetometer/ak8975.c |   11 +++++------
>  1 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/iio/magnetometer/ak8975.c b/drivers/staging/iio/magnetometer/ak8975.c
> index 14076da..0dfdf50 100644
> --- a/drivers/staging/iio/magnetometer/ak8975.c
> +++ b/drivers/staging/iio/magnetometer/ak8975.c
> @@ -373,7 +373,7 @@ static int ak8975_read_axis(struct iio_dev *indio_dev, int index, int *val)
>  	}
>  
>  	/* Wait for the conversion to complete. */
> -	if (data->eoc_gpio)
> +	if (gpio_is_valid(data->eoc_gpio))
>  		ret = wait_conversion_complete_gpio(data);
>  	else
>  		ret = wait_conversion_complete_polled(data);
> @@ -481,7 +481,7 @@ static int ak8975_probe(struct i2c_client *client,
>  
>  	/* We may not have a GPIO based IRQ to scan, that is fine, we will
>  	   poll if so */
> -	if (eoc_gpio > 0) {
> +	if (gpio_is_valid(eoc_gpio)) {
>  		err = gpio_request(eoc_gpio, "ak_8975");
>  		if (err < 0) {
>  			dev_err(&client->dev,
> @@ -497,8 +497,7 @@ static int ak8975_probe(struct i2c_client *client,
>  						eoc_gpio, err);
>  			goto exit_gpio;
>  		}
> -	} else
> -		eoc_gpio = 0;	/* No GPIO available */
> +	}
>  
>  	/* Register with IIO */
>  	indio_dev = iio_allocate_device(sizeof(*data));
> @@ -534,7 +533,7 @@ static int ak8975_probe(struct i2c_client *client,
>  exit_free_iio:
>  	iio_free_device(indio_dev);
>  exit_gpio:
> -	if (eoc_gpio)
> +	if (gpio_is_valid(eoc_gpio))
>  		gpio_free(eoc_gpio);
>  exit:
>  	return err;
> @@ -549,7 +548,7 @@ static int ak8975_remove(struct i2c_client *client)
>  	iio_device_unregister(indio_dev);
>  	iio_free_device(indio_dev);
>  
> -	if (eoc_gpio)
> +	if (gpio_is_valid(eoc_gpio))
>  		gpio_free(eoc_gpio);
>  
>  	return 0;

Re: [PATCH V2 4/4] staging:iio:magnetometer:ak8975: Fix probe() error-handling

[Jonathan Cameron]

On 09/01/11 17:52, Stephen Warren wrote:
> Fix ak8975_probe() to jump to the appropriate exit labels when an error
> occurs. With the previous code, some cleanup actions were being skipped
> for some error conditions.
> 
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Acked-by: Jonathan Cameron <jic23-KWPb1pKIrIJaa/9Udqfwiw@public.gmane.org>
> ---
>  drivers/staging/iio/magnetometer/ak8975.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/staging/iio/magnetometer/ak8975.c b/drivers/staging/iio/magnetometer/ak8975.c
> index 0dfdf50..cc20e8d 100644
> --- a/drivers/staging/iio/magnetometer/ak8975.c
> +++ b/drivers/staging/iio/magnetometer/ak8975.c
> @@ -510,7 +510,7 @@ static int ak8975_probe(struct i2c_client *client,
>  	err = ak8975_setup(client);
>  	if (err < 0) {
>  		dev_err(&client->dev, "AK8975 initialization fails\n");
> -		goto exit_gpio;
> +		goto exit_free_iio;
>  	}
>  
>  	i2c_set_clientdata(client, indio_dev);

Re: [PATCH V2 4/4] staging:iio:magnetometer:ak8975: Fix probe() error-handling

[Jonathan Cameron]

On 09/01/11 17:52, Stephen Warren wrote:
> Fix ak8975_probe() to jump to the appropriate exit labels when an error
> occurs. With the previous code, some cleanup actions were being skipped
> for some error conditions.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
> ---
>  drivers/staging/iio/magnetometer/ak8975.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/staging/iio/magnetometer/ak8975.c b/drivers/staging/iio/magnetometer/ak8975.c
> index 0dfdf50..cc20e8d 100644
> --- a/drivers/staging/iio/magnetometer/ak8975.c
> +++ b/drivers/staging/iio/magnetometer/ak8975.c
> @@ -510,7 +510,7 @@ static int ak8975_probe(struct i2c_client *client,
>  	err = ak8975_setup(client);
>  	if (err < 0) {
>  		dev_err(&client->dev, "AK8975 initialization fails\n");
> -		goto exit_gpio;
> +		goto exit_free_iio;
>  	}
>  
>  	i2c_set_clientdata(client, indio_dev);

RE: [PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[Stephen Warren]

Jonathan Cameron wrote at Friday, September 02, 2011 2:48 AM:
> On 09/01/11 17:52, Stephen Warren wrote:
> > Some devices use a single pin as both an IRQ and a GPIO. In that case,
> > irq_gpio is the GPIO ID for that pin. Not all drivers use this feature.
> > Where they do, and the use of this feature is optional, and the system
> > wishes to disable this feature, this field must be explicitly set to a
> > defined invalid GPIO ID, such as -1.
>
> Why make it specifically an irq related gpio?  Might as well just call it
> gpio then it can be used for cases where it never corresponds to an irq
> such as capture trigger pins.
> 
> Otherwise I'd be happy to see this go in.

The idea was specifically to replace the need to call irq_to_gpio(i2c->irq).
If we did just rename it plain "gpio" and allow it to be used for anything,
then that does indeed start looking more like device-specific platform data.

I guess it sounds like consensus is to go that way. It does seem like that
will end up creating a bunch more device-specific platform-data files though.
I wonder if adding IORESOURCE_GPIO would make sense so this could be handled
in a generic way without custom platform data types?

-- 
nvpublic

RE: [PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[Stephen Warren]

Jonathan Cameron wrote at Friday, September 02, 2011 2:48 AM:
> On 09/01/11 17:52, Stephen Warren wrote:
> > Some devices use a single pin as both an IRQ and a GPIO. In that case,
> > irq_gpio is the GPIO ID for that pin. Not all drivers use this feature.
> > Where they do, and the use of this feature is optional, and the system
> > wishes to disable this feature, this field must be explicitly set to a
> > defined invalid GPIO ID, such as -1.
>
> Why make it specifically an irq related gpio?  Might as well just call it
> gpio then it can be used for cases where it never corresponds to an irq
> such as capture trigger pins.
> 
> Otherwise I'd be happy to see this go in.

The idea was specifically to replace the need to call irq_to_gpio(i2c->irq).
If we did just rename it plain "gpio" and allow it to be used for anything,
then that does indeed start looking more like device-specific platform data.

I guess it sounds like consensus is to go that way. It does seem like that
will end up creating a bunch more device-specific platform-data files though.
I wonder if adding IORESOURCE_GPIO would make sense so this could be handled
in a generic way without custom platform data types?

-- 
nvpublic

RE: [PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[Stephen Warren]

Jonathan Cameron wrote at Friday, September 02, 2011 2:48 AM:
> On 09/01/11 17:52, Stephen Warren wrote:
> > Some devices use a single pin as both an IRQ and a GPIO. In that case,
> > irq_gpio is the GPIO ID for that pin. Not all drivers use this feature.
> > Where they do, and the use of this feature is optional, and the system
> > wishes to disable this feature, this field must be explicitly set to a
> > defined invalid GPIO ID, such as -1.
>
> Why make it specifically an irq related gpio?  Might as well just call it
> gpio then it can be used for cases where it never corresponds to an irq
> such as capture trigger pins.
>=20
> Otherwise I'd be happy to see this go in.

The idea was specifically to replace the need to call irq_to_gpio(i2c->irq)=
.
If we did just rename it plain "gpio" and allow it to be used for anything,
then that does indeed start looking more like device-specific platform data=
.

I guess it sounds like consensus is to go that way. It does seem like that
will end up creating a bunch more device-specific platform-data files thoug=
h.
I wonder if adding IORESOURCE_GPIO would make sense so this could be handle=
d
in a generic way without custom platform data types?

--=20
nvpublic

Re: [PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[Arnd Bergmann]

On Friday 02 September 2011, Stephen Warren wrote:
> The idea was specifically to replace the need to call irq_to_gpio(i2c->irq).
> If we did just rename it plain "gpio" and allow it to be used for anything,
> then that does indeed start looking more like device-specific platform data.
> 
> I guess it sounds like consensus is to go that way. It does seem like that
> will end up creating a bunch more device-specific platform-data files though.
> I wonder if adding IORESOURCE_GPIO would make sense so this could be handled
> in a generic way without custom platform data types?

Interesting point. That's probably best for Grant to comment on, because
it depends on the long-term direction he wants to take with this.

I suppose that an IORESOURCE_GPIO makes a lot of sense if we expect
to keep having a flat system-wide gpio number space in the long run,
similar to irq numbers.

It would not fit well if we expect gpio numbers to be local to
a gpio controller, with no unique global identifier for them, similar
to how dma channels in the dma-engine subsystem are handled.

	Arnd

Re: [PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[Arnd Bergmann]

On Friday 02 September 2011, Stephen Warren wrote:
> The idea was specifically to replace the need to call irq_to_gpio(i2c->irq).
> If we did just rename it plain "gpio" and allow it to be used for anything,
> then that does indeed start looking more like device-specific platform data.
> 
> I guess it sounds like consensus is to go that way. It does seem like that
> will end up creating a bunch more device-specific platform-data files though.
> I wonder if adding IORESOURCE_GPIO would make sense so this could be handled
> in a generic way without custom platform data types?

Interesting point. That's probably best for Grant to comment on, because
it depends on the long-term direction he wants to take with this.

I suppose that an IORESOURCE_GPIO makes a lot of sense if we expect
to keep having a flat system-wide gpio number space in the long run,
similar to irq numbers.

It would not fit well if we expect gpio numbers to be local to
a gpio controller, with no unique global identifier for them, similar
to how dma channels in the dma-engine subsystem are handled.

	Arnd

Re: [PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[Mark Brown]

On Fri, Sep 02, 2011 at 06:05:27PM +0200, Arnd Bergmann wrote:

> It would not fit well if we expect gpio numbers to be local to
> a gpio controller, with no unique global identifier for them, similar
> to how dma channels in the dma-engine subsystem are handled.

Or perhaps moving to a clk API style lookup?

Re: [PATCH V2 1/4] i2c: Add irq_gpio field to struct i2c_client.

[Mark Brown]

On Fri, Sep 02, 2011 at 06:05:27PM +0200, Arnd Bergmann wrote:

> It would not fit well if we expect gpio numbers to be local to
> a gpio controller, with no unique global identifier for them, similar
> to how dma channels in the dma-engine subsystem are handled.

Or perhaps moving to a clk API style lookup?