)]}'
{
  "commit": "7a18e96dcbdec3c96876444ae2c7e36ce458e151",
  "tree": "c4a8ed0442eba1035fb7420f8598c955b1735032",
  "parents": [
    "f6f94e2ab1b33f0082ac22d71f66385a60d8157f"
  ],
  "author": {
    "name": "Thomas Renninger",
    "email": "trenn@suse.de",
    "time": "Thu Oct 21 18:24:57 2010 +0200"
  },
  "committer": {
    "name": "Len Brown",
    "email": "len.brown@intel.com",
    "time": "Fri Oct 22 01:21:30 2010 -0400"
  },
  "message": "ACPI: Make Embedded Controller command timeout delay configurable\n\nHere and then there show up machines which need higher timeout values.\nFinding this on affected machines can be cumbersome, because\nACPI_EC_DELAY is a compile option -\u003e make it configurable via boot param.\n\nThis can even be provided writable at runtime via:\n/sys/modules/acpi/parameters/ec_delay\n\nKnown machines where this helps:\nSome HP machines where for whatever reasons specific EC accesses take\nvery long at resume from S3 (in _WAK function).\nThe AE_TIME error is passed upwards and the ACPI interpreter will\nnot execute the rest of the _WAK function which results in not properly\ninitialized devices/variables with different side-effects.\n\nAfaik, on some MSI machines this helped as well.\n\nIf this param is needed there probably are underlying problems like:\n  - EC firmware bug\n  - A kernel EC driver bug\n  - An ACPI interpreter behavior (e.g. timings when specific\n    EC accesses happen and how) which the EC does not like\n  - ...\nwhich should get evaluated further, but often are nasty or\nimpossible to fix from OS side.\n\nSigned-off-by: Thomas Renninger \u003ctrenn@suse.de\u003e\nSigned-off-by: Len Brown \u003clen.brown@intel.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "f31291ba94d092ec3a9cc9b6a51fc0383ee1d56a",
      "old_mode": 33188,
      "old_path": "drivers/acpi/ec.c",
      "new_id": "372ff80b7b0c93f88f6f2ea9e100c0fdd2aaf6bf",
      "new_mode": 33188,
      "new_path": "drivers/acpi/ec.c"
    }
  ]
}