From: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
To: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
Cc: i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org,
Kevin Hilman <khilman-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH 4/5] I2C: DaVinci: fix signal handling bug
Date: Mon, 28 Apr 2008 11:20:40 -0700 [thread overview]
Message-ID: <48161578.3080000@boundarydevices.com> (raw)
In-Reply-To: <20080428191332.371e35e3-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
Jean Delvare wrote:
> Hi Troy,
>
> On Fri, 25 Apr 2008 09:58:13 -0700, Troy Kisky wrote:
>> If wait_for_completion_interruptible_timeout exits due
>> to a signal, the i2c bus was locking up.
>
> What kind of signal (coming from where) are you talking about?
With the user space i2c interface, a ^c was
locking the bus.
>
> If you don't want to be interrupted, why don't you simply use
> wait_for_completion_timeout() instead of
> wait_for_completion_interruptible_timeout()?
I didn't make that choice. Perhaps wait_for_completion_timeout()
would be better. I just preferred fixing the lockup if a signal
happened. It seemed like a safer change to me. Can wait_for_completion_timeout()
return for any reason other the successful completion or timeout? Will
an explicit kill of the process return? Do you want it changed to
use wait_for_completion_timeout()?
>> +static inline void terminate_read(struct davinci_i2c_dev *dev)
>> +{
>> + if (dev->buf_len)
>> + dev->buf_len--;
>> + if (dev->buf_len) {
>
> Please explain (in a comment) what you are doing here. Can't you just
> test for (dev->buf_len > 1)?
Or maybe no test, just always set the nak bit and throw away the data??
>
>> + u16 w = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
>> + w |= DAVINCI_I2C_MDR_NACK;
>> + davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, w);
>> + }
>> + /* Throw away data */
>> + davinci_i2c_read_reg(dev, DAVINCI_I2C_DRR_REG);
>> + if (!dev->terminate)
>> + dev_err(dev->dev, "RDR IRQ while no data requested\n");
>> +}
>> +static inline void terminate_write(struct davinci_i2c_dev *dev)
>> +{
>> + u16 w = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
>> + w |= DAVINCI_I2C_MDR_RM|DAVINCI_I2C_MDR_STP;
>
> Coding-style: spaces around |.
OK
>
>> + davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, w);
>> +
>> + if (!dev->terminate)
>> + dev_err(dev->dev, "TDR IRQ while no data to send\n");
>> +}
>
> I don't see the point of inlining these functions explicitly... They
> are only called in an unlikely event so this is certainly not
> performance-critical.
OK
>> @@ -419,9 +460,10 @@ static irqreturn_t i2c_davinci_isr(int this_irq, void *dev_id)
>> davinci_i2c_write_reg(dev,
>> DAVINCI_I2C_IMR_REG,
>> w);
>> - } else
>> - dev_err(dev->dev, "TDR IRQ while no data to "
>> - "send\n");
>> + } else {
>> + /* signal can terminate transfer */
>> + terminate_write(dev);
>> + }
>> break;
>>
>> case DAVINCI_I2C_IVR_SCD:
>
> Apparently you are using dev->buf_len = 0 and dev->buf = NULL to notify
> particular conditions accross the driver? This should be clearly
> documented, otherwise other developers are likely to break the driver
> while working on it.
>
Agreed.
_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
next prev parent reply other threads:[~2008-04-28 18:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-25 16:58 [PATCH 1/5] I2C: DaVinci: clock between 7-12 MHz Troy Kisky
[not found] ` <1209142694-30046-1-git-send-email-troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
2008-04-25 16:58 ` [PATCH 2/5] I2C: DaVinci: move dev_debug line for more output Troy Kisky
[not found] ` <1209142694-30046-2-git-send-email-troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
2008-04-25 16:58 ` [PATCH 3/5] I2C: DaVinci: remove useless IVR read Troy Kisky
[not found] ` <1209142694-30046-3-git-send-email-troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
2008-04-25 16:58 ` [PATCH 4/5] I2C: DaVinci: fix signal handling bug Troy Kisky
[not found] ` <1209142694-30046-4-git-send-email-troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
2008-04-25 16:58 ` [PATCH 5/5] I2C: DaVinci: initialize cmd_complete sooner Troy Kisky
[not found] ` <1209142694-30046-5-git-send-email-troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
2008-04-28 20:35 ` Jean Delvare
2008-04-28 17:13 ` [PATCH 4/5] I2C: DaVinci: fix signal handling bug Jean Delvare
[not found] ` <20080428191332.371e35e3-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-04-28 18:20 ` Troy Kisky [this message]
[not found] ` <48161578.3080000-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
2008-04-28 20:50 ` Jean Delvare
[not found] ` <20080428225011.4d97736c-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-04-28 23:40 ` Troy Kisky
[not found] ` <4816608B.2000001-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
2008-04-29 8:08 ` Jean Delvare
2008-04-28 16:08 ` [PATCH 3/5] I2C: DaVinci: remove useless IVR read Jean Delvare
2008-04-28 16:04 ` [PATCH 2/5] I2C: DaVinci: move dev_debug line for more output Jean Delvare
[not found] ` <20080428180437.272109dc-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-04-28 16:20 ` Troy Kisky
[not found] ` <4815F951.5030700-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
2008-04-28 16:37 ` Jean Delvare
2008-04-28 14:32 ` [PATCH 1/5] I2C: DaVinci: clock between 7-12 MHz Jean Delvare
-- strict thread matches above, loose matches on Subject: below --
2008-03-21 3:06 [PATCH 0/5]I2C: Davinci host controller changes Troy Kisky
2008-03-21 3:06 ` [PATCH 1/5] I2C: DaVinci: fix lost interrupt Troy Kisky
2008-03-21 3:06 ` [PATCH 2/5] I2C: DaVinci: clock between 7-12 Mhz Troy Kisky
2008-03-21 3:06 ` [PATCH 3/5] I2C: DaVinci: remove useless IVR read Troy Kisky
[not found] ` <1206068770-15458-4-git-send-email-troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
2008-03-21 3:06 ` [PATCH 4/5] I2C: DaVinci: fix signal handling bug Troy Kisky
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=48161578.3080000@boundarydevices.com \
--to=troy.kisky-q5rjgjkts06cy9shamctrueocmrvltnr@public.gmane.org \
--cc=i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org \
--cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
--cc=khilman-Igf4POYTYCDQT0dZR+AlfA@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.