From: Jonathan Cameron <jic23@kernel.org>
To: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: linux-iio@vger.kernel.org
Subject: Re: [PATCH 3/3] iio: ak8975: Don't bail out for irq setup error
Date: Sat, 15 Mar 2014 15:14:02 +0000 [thread overview]
Message-ID: <53246E3A.7020702@kernel.org> (raw)
In-Reply-To: <1394572557-8102-3-git-send-email-srinivas.pandruvada@linux.intel.com>
On 11/03/14 21:15, Srinivas Pandruvada wrote:
> This driver can very well work via polling, if request_irq failed.
> The problem is that many times i2c interrupts are shared. This
> driver is not ready for shared interrupt as it will return IRQ_HANDLED,
> in every case. Here we will get EBUSY when some other driver registered
> handler and this driver is grabbing in exclusive mode.
> So in this case just print error and continue in polling mode.
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
I'm not sure this is a good solution as it means that we will get very different
results depending on the probe order of various drivers. How do other i2c drivers
cope with the fact that there is no way of knowing within the interrupt routine
that the device was the one causing the interrupt?
A quick grep suggests that the normal trick is to had over to an irq thread
then return IRQ_NONE from that once we know it isn't our irq. Could we have
move the queue wakeup into a a thread (converting to a threaded interrupt) but
before it query the hardware to establish it is actually our interrupt?
> ---
> drivers/iio/magnetometer/ak8975.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c
> index fe5e9c8..0f9c407 100644
> --- a/drivers/iio/magnetometer/ak8975.c
> +++ b/drivers/iio/magnetometer/ak8975.c
> @@ -236,9 +236,15 @@ static int ak8975_setup(struct i2c_client *client)
> if (data->eoc_gpio > 0 || client->irq) {
> ret = ak8975_setup_irq(data);
> if (ret < 0) {
> - dev_err(&client->dev,
> - "Error setting data ready interrupt\n");
> - return ret;
> + if (ret == -EBUSY) {
> + dev_err(&client->dev,
> + "device Intr busy:polling required\n");
> + ret = 0;
> + } else {
> + dev_err(&client->dev,
> + "Error setting data ready interrupt\n");
> + return ret;
> + }
> }
> }
>
>
next prev parent reply other threads:[~2014-03-15 15:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-11 21:15 [PATCH 1/3] iio: ak8975 : Add AK8963 compatibility mode support Srinivas Pandruvada
2014-03-11 21:15 ` [PATCH 2/3] iio: ak8975: Added ACPI enumeration Srinivas Pandruvada
2014-03-15 15:06 ` Jonathan Cameron
2014-03-11 21:15 ` [PATCH 3/3] iio: ak8975: Don't bail out for irq setup error Srinivas Pandruvada
2014-03-15 15:14 ` Jonathan Cameron [this message]
2014-03-17 15:44 ` Srinivas Pandruvada
2014-03-17 17:18 ` Jonathan Cameron
2014-03-12 10:07 ` [PATCH 1/3] iio: ak8975 : Add AK8963 compatibility mode support Lars-Peter Clausen
2014-03-12 18:30 ` Srinivas Pandruvada
2014-03-15 15:03 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53246E3A.7020702@kernel.org \
--to=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=srinivas.pandruvada@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).