)]}'
{
  "commit": "8a74c3e77635a088fced9cd9def3eed01a217037",
  "tree": "b442df07db64556abff1ad9cd48c0c389b00ade7",
  "parents": [
    "bf16200689118d19de1b8d2a3c314fc21f5dc7bb"
  ],
  "author": {
    "name": "Luis R. Rodriguez",
    "email": "mcgrof@kernel.org",
    "time": "Wed Jul 29 13:53:26 2015 -0700"
  },
  "committer": {
    "name": "Luis R. Rodriguez",
    "email": "mcgrof@kernel.org",
    "time": "Thu Apr 14 11:01:30 2016 -0700"
  },
  "message": "firmware: add an extensible system data helpers\n\nThe firmware API has evolved over the years slowly, as it\ngrows we extend it by adding new routines or at times we extend\nexisting routines with more or less arguments. This doesn\u0027t scale\nwell, when new arguments are added to existing routines it means\nwe need to traverse the kernel with a slew of collateral\nevolutions to adjust old driver users. The firmware API is also\nnow being used for things outside of the scope of what typically\nwould be considered \"firmware\", an example here is the p54 driver\nenables users to provide a custom EEPROM through this interface.\nAnother example is optional CPU microcode updates.\n\nThere are other subsystems which would like to make use of the\nAPIs for similar things but have different requirements and\ncriteria which they\u0027d like to be met for the requested file.\nIf different requirements are needed it would again mean adding\nmore arguments and making a slew of collateral evolutions, or\nadding yet-another-new-API-call.\n\nInstead of extending the existing firmware API even more this\nprovides an new extensible API which can be used to supercede the\nold firmware API without causing a series of collateral evolutions\nas requirements grow. This leaves the old firmware API as-is,\nignores all consideration for usermode-helpers, labels the new API\nto reflect its broad use outside of the scope of firmware: system\ndata helpers, and builds on top of the original firmware core code.\n\nThe new extensible \"system data\" set of helpers accepts that there\nreally are only two types of requests for accessing system data:\n\na) synchronous requests\nb) asynchronous requests\n\nBoth of these requests may have a different set of requirements\nwhich must be met. These requirements can simply be passed as a\ndescriptors to each type of request. The descriptor can be extended\nover time to support different requirements as the kernel evolves.\n\nUsing the new system data helpers is only necessary if you have\nrequirements outside of what the existing old firmware API accepts.\nWe encourage developers to leave the old API as-is and extend the\nnew descriptors and system data code to provide support for new\nfeatures.\n\nA few simple features added as part of the new set of system data\nrequest APIs, other than making the new API easily extensible for\nthe future:\n\n - By default the kernel will free the system data file for you after\n   your callbacks are called, you however are allowed to request to that\n   you wish to keep the system data file on the descriptor. This is\n   dealt with by requiring a consumer callback for the system data file.\n - Allow both asynchronous and synchronous request to specify that system data\n   files are optional. With the old APIs we had added one full API call,\n   request_firmware_direct() just for this purpose -- although it should be\n   noted another of its goal was to also skip the usermode helper.\n   The system data request APIs allow for you to annotate that a system\n   data file is optional for both synchronous or asynchronous requests\n   through the same two basic set of APIs.\n - Usermode helpers are completely ignored, always\n - The system data request APIs currently match the old synchronous firmware\n   API calls to refcounted firmware_class module, but it should be easy\n   to add support now to enable also refcounting the caller\u0027s module\n   should it be be needed. Likewise the system data request APIs match the\n   old asynchronous firmware API call and refcounts the caller\u0027s module.\n\nIn order to try to help phase out user mode helpers this makes no use of\nthe old user mode helper code *at all*, and if we wish to can easily\nphase this code out with time then.\n\nv5 changes:\n\n* 0-day-bot make htmldocs warning fixes\n\nSigned-off-by: Luis R. Rodriguez \u003cmcgrof@kernel.org\u003e\n",
  "tree_diff": [
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "53378ce4fcd0ffa9d4163903b50594f76e78a2f1",
      "new_mode": 33188,
      "new_path": "Documentation/firmware_class/system_data.txt"
    },
    {
      "type": "modify",
      "old_id": "61a323a6b2cfe7348c63f49eadcd858100dc8a03",
      "old_mode": 33188,
      "old_path": "MAINTAINERS",
      "new_id": "09f5d3fc0bb8148bc8fa98a8ad21b47a90648a39",
      "new_mode": 33188,
      "new_path": "MAINTAINERS"
    },
    {
      "type": "modify",
      "old_id": "773fc30997697711c2ff926ab49ed88d272cdbcc",
      "old_mode": 33188,
      "old_path": "drivers/base/firmware_class.c",
      "new_id": "67546014980174b83412e540382ea1ffb06c9e50",
      "new_mode": 33188,
      "new_path": "drivers/base/firmware_class.c"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "83f961b548f02b3387d0c48b378053077dfd356b",
      "new_mode": 33188,
      "new_path": "include/linux/sysdata.h"
    }
  ]
}