On Friday 21 November 2008, Jean Delvare wrote:
> --- linux-2.6.28-rc6.orig/drivers/i2c/i2c-core.c 2008-11-21
> 11:01:53.000000000 +0100
> +++ linux-2.6.28-rc6/drivers/i2c/i2c-core.c 2008-11-21 14:55:29.000000000
> +0100
> @@ -446,6 +446,7 @@ static int i2c_do_alert(struct device *d
> static void smbus_alert(struct work_struct *work)
> {
> struct i2c_adapter *bus;
> + unsigned short prev_addr = 0;
>
> bus = container_of(work, struct i2c_adapter, alert);
> for (;;) {
> @@ -465,11 +466,18 @@ static void smbus_alert(struct work_stru
>
> data.flag = (status & 1) != 0;
> data.addr = status >> 1;
> +
> + if (data.addr == prev_addr) {
> + dev_warn(&bus->dev, "Duplicate SMBALERT# from dev "
> + "0x%02x, skipping\n", data.addr);
> + break;
> + }
> dev_dbg(&bus->dev, "SMBALERT# %s from dev 0x%02x\n",
> data.flag ? "true" : "false", data.addr);
>
> /* Notify driver for the device which issued the alert. */
> device_for_each_child(&bus->dev, &data, i2c_do_alert);
> + prev_addr = data.addr;
> }
>
> /* We handled all alerts; reenable level-triggered IRQs. */
>
> What do you think?
It's a start. If this is a level-triggered IRQ and the device is
still raising the IRQ ... we'd need something more drastic, since
the IRQ itself would be stuck on; wouldn't want to re-enable it.
Edge triggered IRQs would be easier to cope with.
Do you have a handle on why the device was malfunctioning?
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
