)]}'
{
  "commit": "e70c412ee45332db2636a8f5a35a0685efb0e4aa",
  "tree": "98340f89baa09af04f67f4be5184363c54f2ef2f",
  "parents": [
    "e543ae896626a54c0c05e3c434312d6d033d450c"
  ],
  "author": {
    "name": "Hans J. Koch",
    "email": "hjk@linutronix.de",
    "time": "Sat Dec 06 02:23:13 2008 +0100"
  },
  "committer": {
    "name": "Greg Kroah-Hartman",
    "email": "gregkh@suse.de",
    "time": "Tue Jan 06 10:44:44 2009 -0800"
  },
  "message": "UIO: Pass information about ioports to userspace (V2)\n\nDevices sometimes have memory where all or parts of it can not be mapped to\nuserspace. But it might still be possible to access this memory from\nuserspace by other means. An example are PCI cards that advertise not only\nmappable memory but also ioport ranges. On x86 architectures, these can be\naccessed with ioperm, iopl, inb, outb, and friends. Mike Frysinger (CCed)\nreported a similar problem on Blackfin arch where it doesn\u0027t seem to be easy\nto mmap non-cached memory but it can still be accessed from userspace.\n\nThis patch allows kernel drivers to pass information about such ports to\nuserspace. Similar to the existing mem[] array, it adds a port[] array to\nstruct uio_info. Each port range is described by start, size, and porttype.\n\nIf a driver fills in at least one such port range, the UIO core will simply\npass this information to userspace by creating a new directory \"portio\"\nunderneath /sys/class/uio/uioN/. Similar to the \"mem\" directory, it will\ncontain a subdirectory (portX) for each port range given.\n\nNote that UIO simply passes this information to userspace, it performs no\naction whatsoever with this data. It\u0027s userspace\u0027s responsibility to obtain\naccess to these ports and to solve arch dependent issues. The \"porttype\"\nattribute tells userspace what kind of port it is dealing with.\n\nThis mechanism could also be used to give userspace information about GPIOs\nrelated to a device. You frequently find such hardware in embedded devices,\nso I added a UIO_PORT_GPIO definition. I\u0027m not really sure if this is a good\nidea since there are other solutions to this problem, but it won\u0027t hurt much\nanyway.\n\nSigned-off-by: Hans J. Koch \u003chjk@linutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@suse.de\u003e\n\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "2d2440cd57a947d195d1f099d1a0ac64bdd56031",
      "old_mode": 33188,
      "old_path": "drivers/uio/uio.c",
      "new_id": "4ca85a113aa251e03387da5402e6a9d65a43a421",
      "new_mode": 33188,
      "new_path": "drivers/uio/uio.c"
    },
    {
      "type": "modify",
      "old_id": "cdf338d94b7f450b42fbb1a12779cdbc7c920248",
      "old_mode": 33188,
      "old_path": "include/linux/uio_driver.h",
      "new_id": "20be327bfbb45d12913ded11edbd0d2098e8168b",
      "new_mode": 33188,
      "new_path": "include/linux/uio_driver.h"
    }
  ]
}