@@ -453,12 +452,13 @@ static int ak8975_probe(struct i2c_client *client,mutex_init(&data->lock);/* Grab and set up the supplied GPIO. */-data->eoc_irq=client->irq;pdata=client->dev.platform_data;if(pdata)data->eoc_gpio=pdata->gpio;-else-data->eoc_gpio=irq_to_gpio(client->irq);+else{+else{+dev_err(&client->dev,"failed, no platform GPIO specified\n");+gotoexit;+}if(!data->eoc_gpio){dev_err(&client->dev,"failed, no valid GPIO\n");--
Hi Kyungmin Park,
On 4 March 2011 14:51, Kyungmin Park [off-list ref] wrote:
Hi,
On Fri, Mar 4, 2011 at 2:34 PM, Naveen Krishna Ch
[off-list ref] wrote:
quoted
Issue:
For some architectures CONFIG_GENERIC_GPIO is defined,
leaving irq_to_gpio undefined. ?Causing build break.
It's better to implement the irq_to_gpio. Since gpio_to_irq is already
implemented. it's just vice versa.
Implementing such macros in machine header files leads to inclusion of
mach/gpio.h or irqs.h
Russel King, seems against to the same...
Any suggestions, please
Thank you,
Kyungmin Park
quoted
Solution:
1. Some architechtures define irq_to_gpio in machine specific code.
2. Make GPIO in platdata mandatory.
Signed-off-by: Naveen Krishna Ch <redacted>
---
?drivers/staging/iio/magnetometer/ak8975.c | ? ?8 ++++----
?1 files changed, 4 insertions(+), 4 deletions(-)
From: Russell King - ARM Linux <hidden> Date: 2011-03-06 00:58:41
On Sun, Mar 06, 2011 at 09:31:41AM +0900, Naveen Krishna Ch wrote:
Hi Kyungmin Park,
On 4 March 2011 14:51, Kyungmin Park [off-list ref] wrote:
quoted
Hi,
On Fri, Mar 4, 2011 at 2:34 PM, Naveen Krishna Ch
[off-list ref] wrote:
quoted
Issue:
For some architectures CONFIG_GENERIC_GPIO is defined,
leaving irq_to_gpio undefined. ?Causing build break.
It's better to implement the irq_to_gpio. Since gpio_to_irq is already
implemented. it's just vice versa.
Implementing such macros in machine header files leads to inclusion of
mach/gpio.h or irqs.h
Russel King, seems against to the same...
Four reasons:
1. including mach/gpio.h means that the code is non-portable to other
architectures.
2. linux/gpio.h defines helpers for the !GENERIC_GPIO case.
3. it's good practice to always use linux/ includes rather than asm/ or
mach/ where-ever possible.
4. over time, standard helpers tend to get split out into the common
architecture-independent header files. Who would like to volunteer
to fix up all the mach/gpio.h->linux/gpio.h when that happens.
However:
quoted
quoted
For some architectures CONFIG_GENERIC_GPIO is defined,
leaving irq_to_gpio undefined. ?Causing build break.
I read this as saying: "There are architectures which set
CONFIG_GENERIC_GPIO but do not provide a definition for irq_to_gpio()".
If that's true, then that's a problem for those architectures to solve.
However, first I'd like you to clear up some confusion: what do you mean
by architecture? ARM/Sparc/x86? Or S3C2410 vs OMAP4430 vs Orion vs
Tegra? The former are architectures. The latter are SoCs or families
of SoCs/machines/platforms.
Last point: do _not_ cc: mailing list managers for normal discussion
email - I'm talking about the majordomo at vger.kernel.org which was in the
CC in this thread. Mailing list managers take specially formatted email
messages in order to take automated action. They do not recognise plain
language, and you'll probably get a verbose error reply.
Hi Russell King,
On 6 March 2011 09:58, Russell King - ARM Linux [off-list ref] wrote:
On Sun, Mar 06, 2011 at 09:31:41AM +0900, Naveen Krishna Ch wrote:
quoted
Hi Kyungmin Park,
On 4 March 2011 14:51, Kyungmin Park [off-list ref] wrote:
quoted
Hi,
On Fri, Mar 4, 2011 at 2:34 PM, Naveen Krishna Ch
[off-list ref] wrote:
quoted
Issue:
For some architectures CONFIG_GENERIC_GPIO is defined,
leaving irq_to_gpio undefined. ?Causing build break.
It's better to implement the irq_to_gpio. Since gpio_to_irq is already
implemented. it's just vice versa.
Implementing such macros in machine header files leads to inclusion of
mach/gpio.h or irqs.h
Russel King, seems against to the same...
Four reasons:
1. including mach/gpio.h means that the code is non-portable to other
? architectures.
2. linux/gpio.h defines helpers for the !GENERIC_GPIO case.
3. it's good practice to always use linux/ includes rather than asm/ or
? mach/ where-ever possible.
4. over time, standard helpers tend to get split out into the common
? architecture-independent header files. ?Who would like to volunteer
? to fix up all the mach/gpio.h->linux/gpio.h when that happens.
I understand, the complication created by using machine specific code.
However:
quoted
quoted
quoted
For some architectures CONFIG_GENERIC_GPIO is defined,
leaving irq_to_gpio undefined. ?Causing build break.
I read this as saying: "There are architectures which set
CONFIG_GENERIC_GPIO but do not provide a definition for irq_to_gpio()".
If that's true, then that's a problem for those architectures to solve.
I will start looking into fixing the problem, instead of this issue.
However, first I'd like you to clear up some confusion: what do you mean
by architecture? ?ARM/Sparc/x86? ?Or S3C2410 vs OMAP4430 vs Orion vs
Tegra? ?The former are architectures. ?The latter are SoCs or families
of SoCs/machines/platforms.
I mean, SoCs or families.
Last point: do _not_ cc: mailing list managers for normal discussion
email - I'm talking about the majordomo at vger.kernel.org which was in the
CC in this thread.
Sorry my bad, Will correct it here on.
Mailing list managers take specially formatted email
messages in order to take automated action. ?They do not recognise plain
language, and you'll probably get a verbose error reply.
Yes, I Did..
Thanks, for your prompt reply and the explanation.
--
Shine bright,
(: Nav :)