)]}'
{
  "commit": "82736f4d1d2b7063b829cc93171a6e5aea8a9c49",
  "tree": "3e0e7bf57638dcb1321496440a11623beb005458",
  "parents": [
    "f606ddf42fd4edc558eeb48bfee66d2c591571d2"
  ],
  "author": {
    "name": "Uwe Kleine-König",
    "email": "Uwe.Kleine-Koenig@digi.com",
    "time": "Wed Jul 23 21:28:54 2008 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Thu Jul 24 10:47:24 2008 -0700"
  },
  "message": "generic irqs: handle failure of irqchip-\u003eset_type in setup_irq\n\nset_type returns an int indicating success or failure, but up to now\nsetup_irq ignores that.\n\nIn my case this resulted in a machine hang:\n\ngpio-keys requested IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING, but\narm/ns9xxx can only trigger on one direction so set_type didn\u0027t touch\nthe configuration which happens do default to a level sensitiveness and\nreturned -EINVAL.  setup_irq ignored that and unmasked the irq.  This\nresulted in an endless triggering of the gpio-key interrupt service\nroutine which effectively killed the machine.\n\nWith this patch applied setup_irq propagates the error to the caller.\n\nNote that before in the case\n\n\tchip \u0026\u0026 !chip-\u003eset_type \u0026\u0026 !chip-\u003ename\n\na NULL pointer was feed to printk.  This is fixed, too.\n\nSigned-off-by: Uwe Kleine-König \u003cUwe.Kleine-Koenig@digi.com\u003e\nCc: Ingo Molnar \u003cmingo@elte.hu\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "3cfc0fefb5ee671e1565862f1b54ee431af4eb8a",
      "old_mode": 33188,
      "old_path": "kernel/irq/manage.c",
      "new_id": "5bc6e5ecc493bcf3d35e54cdcffca0fb79ac1303",
      "new_mode": 33188,
      "new_path": "kernel/irq/manage.c"
    }
  ]
}