)]}'
{
  "log": [
    {
      "commit": "d91958815d214ea365b98cbff6215383897edcb6",
      "tree": "a50416a04c9ae84c4242dbec62d8f211d97ea4d2",
      "parents": [
        "19fd6231279be3c3bdd02ed99f9b0eb195978064"
      ],
      "author": {
        "name": "Matt LaPlante",
        "email": "kernel1@cyberdogtech.com",
        "time": "Fri Jul 25 19:45:33 2008 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@linux-foundation.org",
        "time": "Sat Jul 26 12:00:06 2008 -0700"
      },
      "message": "Documentation cleanup: trivial misspelling, punctuation, and grammar corrections.\n\nCc: Randy Dunlap \u003crandy.dunlap@oracle.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n"
    },
    {
      "commit": "0013b23d66a2768f5babbb0ea9f03ab067a990d8",
      "tree": "14d60a50bb68e422767a268cd737f70ef4e6e19d",
      "parents": [
        "b3ba31f84ea041c0945b5904d4c407ce14b2b72c"
      ],
      "author": {
        "name": "Németh Márton",
        "email": "nm127@freemail.hu",
        "time": "Sun Mar 09 20:54:37 2008 +0000"
      },
      "committer": {
        "name": "Richard Purdie",
        "email": "rpurdie@rpsys.net",
        "time": "Thu Apr 24 23:34:18 2008 +0100"
      },
      "message": "leds: disable triggers on brightness set\n\nDisable any active triggers when the brightness attribute is\nset to zero.\n\nSigned-off-by: Henrique de Moraes Holschuh \u003chmh@hmh.eng.br\u003e\nSigned-off-by: Márton Németh \u003cnm127@freemail.hu\u003e\nSigned-off-by: Richard Purdie \u003crpurdie@rpsys.net\u003e\n"
    },
    {
      "commit": "4c79141d28bc290ae307e3f81f5bc909c26faf6e",
      "tree": "9c6dc51c441dfc1c84cc27ece43087515c06967c",
      "parents": [
        "6c152beefbf90579d21afc4f7e075b1f801f9a75"
      ],
      "author": {
        "name": "Márton Németh",
        "email": "nm127@freemail.hu",
        "time": "Wed Oct 31 15:07:12 2007 +0100"
      },
      "committer": {
        "name": "Richard Purdie",
        "email": "rpurdie@rpsys.net",
        "time": "Thu Feb 07 09:49:38 2008 +0000"
      },
      "message": "leds: Add support for hardware accelerated LED flashing\n\nExtends the leds subsystem with a blink_set() callback function which can\nbe optionally implemented by a LED driver. If implemented, the driver can use\nthe hardware acceleration for blinking a LED.\n\nSigned-off-by: Márton Németh \u003cnm127@freemail.hu\u003e\nSigned-off-by: Richard Purdie \u003crpurdie@rpsys.net\u003e\n"
    },
    {
      "commit": "6c152beefbf90579d21afc4f7e075b1f801f9a75",
      "tree": "c5814496de9e29662d558deddb31e0a0c4549cd7",
      "parents": [
        "cec035de8265b18252742ef359b12e9694641112"
      ],
      "author": {
        "name": "Richard Purdie",
        "email": "rpurdie@rpsys.net",
        "time": "Wed Oct 31 15:00:07 2007 +0100"
      },
      "committer": {
        "name": "Richard Purdie",
        "email": "rpurdie@rpsys.net",
        "time": "Thu Feb 07 09:47:00 2008 +0000"
      },
      "message": "leds: Standardise LED naming scheme\n\nAs discussed on LKML some notion of \u0027function\u0027 is needed in\nLED naming. This patch adds this to the documentation and\nstandardises existing LED drivers.\n\nSigned-off-by: Richard Purdie \u003crpurdie@rpsys.net\u003e\n"
    },
    {
      "commit": "75c1d31d9ea71025b73430c696b727e8aa15872d",
      "tree": "7f63ad1a6e79467ceb04fd7113538156bc80cfd0",
      "parents": [
        "7529c301165079d0f149d0e54724829e602f8fc0"
      ],
      "author": {
        "name": "Richard Purdie",
        "email": "rpurdie@rpsys.net",
        "time": "Fri Mar 31 02:31:03 2006 -0800"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Fri Mar 31 12:18:56 2006 -0800"
      },
      "message": "[PATCH] LED: class documentation\n\nThe LED class/subsystem takes John Lenz\u0027s work and extends and alters it to\ngive what I think should be a fairly universal LED implementation.\n\nThe series consists of several logical units:\n\n* LED Core + Class implementation\n* LED Trigger Core implementation\n* LED timer trigger (example of a complex trigger)\n* LED device drivers for corgi, spitz and tosa Zaurus models\n* LED device driver for locomo LEDs\n* LED device driver for ARM ixp4xx LEDs\n* Zaurus charging LED trigger\n* IDE disk activity LED trigger\n* NAND MTD activity LED trigger\n\nWhy?\n\u003d\u003d\u003d\u003d\n\nLEDs are really simple devices usually amounting to a GPIO that can be turned\non and off so why do we need all this code?  On handheld or embedded devices\nthey\u0027re an important part of an often limited user interface.  Both users and\ndevelopers want to be able to control and configure what the LED does and the\nnumber of different things they\u0027d potentially want the LED to show is large.\n\nA subsystem is needed to try and provide all this different functionality in\nan architecture independent, simple but complete, generic and scalable manner.\n\nThe alternative is for everyone to implement just what they need hidden away\nin different corners of the kernel source tree and to provide an inconsistent\ninterface to userspace.\n\nOther Implementations\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nI\u0027m aware of the existing arm led implementation.  Currently the new subsystem\nand the arm code can coexist quite happily.  Its up to the arm community to\ndecide whether this new interface is acceptable to them.  As far as I can see,\nthe new interface can do everything the existing arm implementation can with\nthe advantage that the new code is architecture independent and much more\ngeneric, configurable and scalable.\n\nI\u0027m prepared to make the conversion to the LED subsystem (or assist with it)\nif appropriate.\n\nImplementation Details\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nI\u0027ve stripped a lot of code out of John\u0027s original LED class.  Colours were\nremoved as LED colour is now part of the device name.  Multiple colours are to\nbe handled as multiple led devices.  This means you get full control over each\ncolour.  I also removed the LED hardware timer code as the generic timer isn\u0027t\ngoing to add much overhead and is just as useful.  I also decided to have the\nLED core track the current LED status (to ease suspend/resume handling)\nremoving the need for brightness_get implementations in the LED drivers.\n\nAn underlying design philosophy is simplicity.  The aim is to keep a small\namount of code giving as much functionality as possible.\n\nThe major new idea is the led \"trigger\".  A trigger is a source of led events.\n Triggers can either be simple or complex.  A simple trigger isn\u0027t\nconfigurable and is designed to slot into existing subsystems with minimal\nadditional code.  Examples are the ide-disk, nand-disk and zaurus-charging\ntriggers.  With leds disabled, the code optimises away.  Examples are\nnand-disk and ide-disk.\n\nComplex triggers whilst available to all LEDs have LED specific parameters and\nwork on a per LED basis.  The timer trigger is an example.\n\nYou can change triggers in a similar manner to the way an IO scheduler is\nchosen (via /sys/class/leds/somedevice/trigger).\n\nSo far there are only a handful of examples but it should easy to add further\nLED triggers without too much interference into other subsystems.\n\nKnown Issues\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nThe LED Trigger core cannot be a module as the simple trigger functions would\ncause nightmare dependency issues.  I see this as a minor issue compared to\nthe benefits the simple trigger functionality brings.  The rest of the LED\nsubsystem can be modular.\n\nSome leds can be programmed to flash in hardware.  As this isn\u0027t a generic LED\ndevice property, I think this should be exported as a device specific sysfs\nattribute rather than part of the class if this functionality is required (eg.\n to keep the led flashing whilst the device is suspended).\n\nFuture Development\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nAt the moment, a trigger can\u0027t be created specifically for a single LED.\nThere are a number of cases where a trigger might only be mappable to a\nparticular LED.  The addition of triggers provided by the LED driver should\ncover this option and be possible to add without breaking the current\ninterface.\n\nA CPU activity trigger similar to that found in the arm led implementation\nshould be trivial to add.\n\nThis patch:\n\nAdd some brief documentation of the design decisions behind the LED class and\nhow it appears to users.\n\nSigned-off-by: Richard Purdie \u003crpurdie@rpsys.net\u003e\nCc: Russell King \u003crmk@arm.linux.org.uk\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    }
  ]
}