)]}'
{
  "log": [
    {
      "commit": "719234f9444552a8b3ac30a7c373db62e13c14f4",
      "tree": "a277e3dba46f5d211e85db8199d292517375d293",
      "parents": [
        "fc8d713ecd01acb312afed8c560130ea7284c6db"
      ],
      "author": {
        "name": "Jon Mason",
        "email": "jon.mason@intel.com",
        "time": "Mon Jan 21 15:28:51 2013 -0700"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Mon Jan 21 14:34:21 2013 -0800"
      },
      "message": "NTB: disable x86_32 support\n\nAtomic readq and writeq do not exist by default on some 32bit\narchitectures, thus causing compile errors due to non-existent symbols.\nSince NTB has not been tested 32bit, disable x86_32 support until such\ntime as this and any other issues can be properly discovered.\n\nSigned-off-by: Jon Mason \u003cjon.mason@intel.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n"
    },
    {
      "commit": "fce8a7bb5b4bfb8a27324703fd5b002ee9247e90",
      "tree": "03ea4f4939d399265ecfa5f11081895a969115e7",
      "parents": [
        "ea8a83a4b718f78a8ea2ce3f0237e78a23f8f12b"
      ],
      "author": {
        "name": "Jon Mason",
        "email": "jon.mason@intel.com",
        "time": "Fri Nov 16 19:27:12 2012 -0700"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Jan 17 19:11:14 2013 -0800"
      },
      "message": "PCI-Express Non-Transparent Bridge Support\n\nA PCI-Express non-transparent bridge (NTB) is a point-to-point PCIe bus\nconnecting 2 systems, providing electrical isolation between the two subsystems.\nA non-transparent bridge is functionally similar to a transparent bridge except\nthat both sides of the bridge have their own independent address domains.  The\nhost on one side of the bridge will not have the visibility of the complete\nmemory or I/O space on the other side of the bridge.  To communicate across the\nnon-transparent bridge, each NTB endpoint has one (or more) apertures exposed to\nthe local system.  Writes to these apertures are mirrored to memory on the\nremote system.  Communications can also occur through the use of doorbell\nregisters that initiate interrupts to the alternate domain, and scratch-pad\nregisters accessible from both sides.\n\nThe NTB device driver is needed to configure these memory windows, doorbell, and\nscratch-pad registers as well as use them in such a way as they can be turned\ninto a viable communication channel to the remote system.  ntb_hw.[ch]\ndetermines the usage model (NTB to NTB or NTB to Root Port) and abstracts away\nthe underlying hardware to provide access and a common interface to the doorbell\nregisters, scratch pads, and memory windows.  These hardware interfaces are\nexported so that other, non-mainlined kernel drivers can access these.\nntb_transport.[ch] also uses the exported interfaces in ntb_hw.[ch] to setup a\ncommunication channel(s) and provide a reliable way of transferring data from\none side to the other, which it then exports so that \"client\" drivers can access\nthem.  These client drivers are used to provide a standard kernel interface\n(i.e., Ethernet device) to NTB, such that Linux can transfer data from one\nsystem to the other in a standard way.\n\nSigned-off-by: Jon Mason \u003cjon.mason@intel.com\u003e\nReviewed-by: Nicholas Bellinger \u003cnab@linux-iscsi.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n"
    }
  ]
}