Messages in this thread | | | Date | Fri, 4 Jul 2008 10:17:17 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH v2] handle failure of irqchip->set_type in setup_irq |
| |
On Fri, 4 Jul 2008 12:46:34 +0200 Uwe Kleine-K__nig <Uwe.Kleine-Koenig@digi.com> wrote:
> set_type returns an int indicating success or failure, but up to now > setup_irq ignores that. > > In my case this resulted in a machine hang: > gpio-keys requested IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING, but > arm/ns9xxx can only trigger on one direction so set_type didn't touch > the configuration which happens do default to a level sensitiveness and > returned -EINVAL. setup_irq ignored that and unmasked the irq. This > resulted in an endless triggering of the gpio-key interrupt service > routine which effectively killed the machine. > > With this patch applied setup_irq propagates the error to the caller. > > Note that before in the case > > chip && !chip->set_type && !chip->name > > a NULL pointer was feed to printk. This is fixed, too. >
hm, OK. Do I recall there being some urgency to this?
> + if (ret) { > + char buf[100]; > + > + snprintf(buf, sizeof(buf), KERN_ERR > + "setting flow type for irq %u failed (%%s)\n", > + irq); > + print_fn_descriptor_symbol(buf, chip->set_type); > + }
eww. We really mucked up that interface. I wonder if we can do better. Let me think about that.
| |