Re: [patch 2.6.27-rc7] i2c: smbalert# support

[David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>]

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