From: Timur Tabi <timur-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
To: linuxppc-dev
<linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Mark Brown
<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Subject: Calling wait_event_interruptible_timeout() in I2C wait functions
Date: Tue, 03 Feb 2009 13:37:30 -0600 [thread overview]
Message-ID: <49889CFA.7070308@freescale.com> (raw)
In i2c-mpc.c, the i2c_wait() function has this:
} else {
/* Interrupt mode */
result = wait_event_interruptible_timeout(i2c->queue,
(i2c->interrupt & CSR_MIF), timeout * HZ);
if (unlikely(result < 0)) {
pr_debug("I2C: wait interrupted\n");
writeccr(i2c, 0);
} else if (unlikely(!(i2c->interrupt & CSR_MIF))) {
That is, the driver calls wait_event_interruptible_timeout() to wait for
a response from the I2C controller after a read or write operation.
However, it appears that this is not common behavior for I2C driver. In
fact, only these six drivers ever call wait_event_interruptible_timeout():
i2c-cpm.c
i2c-ibm_iic.c
i2c-mpc.c
i2c-taos-evm.c
i2c-iop3xx.c
i2c-mv64xxx.c
Although one would think that calling wait_event_interruptible_timeout()
is a good idea, it fails in one situation: when the abrupt termination
of a process causes an I2C operation to occur. That is, you press ^C in
your application, and the driver issues a final I2C operation to shut
down the device. In this situation, wait_event_interruptible_timeout()
returns -ERESTARTSYS, which is then passed up through
i2c_smbus_write_byte_data().
So my question is, is i2c-mpc.c wrong in using
wait_event_interruptible_timeout()?
--
Timur Tabi
Linux kernel developer at Freescale
WARNING: multiple messages have this Message-ID (diff)
From: Timur Tabi <timur@freescale.com>
To: linuxppc-dev <linuxppc-dev@ozlabs.org>, linux-i2c@vger.kernel.org
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Subject: Calling wait_event_interruptible_timeout() in I2C wait functions
Date: Tue, 03 Feb 2009 13:37:30 -0600 [thread overview]
Message-ID: <49889CFA.7070308@freescale.com> (raw)
In i2c-mpc.c, the i2c_wait() function has this:
} else {
/* Interrupt mode */
result = wait_event_interruptible_timeout(i2c->queue,
(i2c->interrupt & CSR_MIF), timeout * HZ);
if (unlikely(result < 0)) {
pr_debug("I2C: wait interrupted\n");
writeccr(i2c, 0);
} else if (unlikely(!(i2c->interrupt & CSR_MIF))) {
That is, the driver calls wait_event_interruptible_timeout() to wait for
a response from the I2C controller after a read or write operation.
However, it appears that this is not common behavior for I2C driver. In
fact, only these six drivers ever call wait_event_interruptible_timeout():
i2c-cpm.c
i2c-ibm_iic.c
i2c-mpc.c
i2c-taos-evm.c
i2c-iop3xx.c
i2c-mv64xxx.c
Although one would think that calling wait_event_interruptible_timeout()
is a good idea, it fails in one situation: when the abrupt termination
of a process causes an I2C operation to occur. That is, you press ^C in
your application, and the driver issues a final I2C operation to shut
down the device. In this situation, wait_event_interruptible_timeout()
returns -ERESTARTSYS, which is then passed up through
i2c_smbus_write_byte_data().
So my question is, is i2c-mpc.c wrong in using
wait_event_interruptible_timeout()?
--
Timur Tabi
Linux kernel developer at Freescale
next reply other threads:[~2009-02-03 19:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-03 19:37 Timur Tabi [this message]
2009-02-03 19:37 ` Calling wait_event_interruptible_timeout() in I2C wait functions Timur Tabi
[not found] ` <49889CFA.7070308-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2009-02-04 20:00 ` Mike Ditto
2009-02-04 20:00 ` Mike Ditto
[not found] ` <4989F3F4.7070207-Vjf7OWgA3BLqlBn2x/YWAg@public.gmane.org>
2009-02-05 11:51 ` Mark Brown
2009-02-05 11:51 ` Mark Brown
[not found] ` <20090205115100.GD422-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2009-02-05 15:18 ` Timur Tabi
2009-02-05 15:18 ` Timur Tabi
2009-02-04 20:00 ` Mike Ditto
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=49889CFA.7070308@freescale.com \
--to=timur-kzfg59tc24xl57midrcfdg@public.gmane.org \
--cc=broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.