)]}'
{
  "commit": "65e5b1e9eb3f777ab7535b74b490e882eeec79d7",
  "tree": "ada7fa5c67ca18ca2bdcd5056241fea7e4528fac",
  "parents": [
    "7639dad93a5564579987abded4ec05e3db13659d"
  ],
  "author": {
    "name": "Linus Walleij",
    "email": "linus.walleij@linaro.org",
    "time": "Fri Feb 19 15:14:29 2016 +0100"
  },
  "committer": {
    "name": "Linus Walleij",
    "email": "linus.walleij@linaro.org",
    "time": "Mon May 23 10:15:20 2016 +0200"
  },
  "message": "chrdev: allocate dynamic chardevs in all unused holes\n\nThis is a duct-tape-and-chewing-gum solution to the problem\nwith the major numbers running out when allocating major\nnumbers dynamically.\n\nTo avoid collisions in the major space, we supply a bitmap with\n\"holes\" that exist in the lower range of major numbers [0-254]\nand pick numbers from there, beginning with the unused char\ndevice 8 and moving up through 26, 40, 60-63, 93-94, 102,\n120-127, 159, 213-215, 222-223 and 234-254.\n\nThe algorithm will behave like the old dynamic assignment\nto begin with: dynamic majors will be assigned starting with\n254, 253, ... but when it reaches 234 it will make a jump\nand assign 223 and so on.\n\nIt will also FAIL if we actually fill up all free major\nnumbers. This seems to me like the reasonable thing to do\nsince the other numbers are, after all, reserved.\n\nThis also deletes the comment /* temporary */ which must be\none of the biggest lies ever.\n\nThis also updates the Documentation/devices.txt document to\nreflect that all these numbers are used for dynamic assignment.\n\nReported-by: Ying Huang \u003cying.huang@linux.intel.com\u003e\nCc: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nCc: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\nCc: Alan Cox \u003calan@linux.intel.com\u003e\nCc: Arnd Bergmann \u003carnd@arndb.de\u003e\nSigned-off-by: Linus Walleij \u003clinus.walleij@linaro.org\u003e\n---\nChangeLog v4-\u003ev5:\n- Create a new macro, BITS32() in \u003clinux/bitops.\u003e that allow\n  us to make an intuitive bitmask for the existing major\n  number. This reuses GENMASK(), clamps the arguments and\n  switch them around: to me it is atleast most intuitive to\n  have the lower bit before the higher one.\n- Use BITS32() and BIT_MASK() to define the bitlist for\n  available devices.\n- Assign dynamic majors from the top down (254, 253...) like\n  the old code was doing. I tried assigning bottom up\n  (8, 20,...) but that gave rise to \"interesting\" phenomena\n  on Intels test servers running random QEMU: character\n  devices in the lower range would stop probing properly,\n  even if they have a major number not colliding with the\n  dynamic assignment. At one time IDE tape (major 37) and\n  one time ISDN (major 45). No clue as to why.\nChangeLog v3-\u003ev4:\n- Create the BITS() macro in a separate patch. This was\n  more tangled up than I thought, as the nice build servers\n  quickly told me.\nChangeLog v2-\u003ev3:\n- Of course I had a dangling hunk for pr_dbg()-\u003epr_debug()\n  in my working tree. Mea culpa.\n- Fix the redefinition of BITS() in select.c to use the\n  more precise name FDS_BITS() over the generic plural.\nChangeLog v1-\u003ev2:\n- Follow-up on the previous RFC patch, this uses Torvald\u0027s\n  suggested bitmap approach to allocate devices instead of\n  a list of free numbers.\n- As a result of using find_first_zero_bit(), the major\n  numbers are assigned from low to high instead from high\n  to low. It\u0027s a bit scarier but I guess drivers using\n  dynamic numbers should be all right with it, I\u0027m more\n  worried about userspaces expecting dynamic majors to\n  be in the [234,254] range. Input welcome, maybe I\u0027m\n  just chicken.\n- This still needs to be applied on top of the previous\n  fix to start warning about going below major 234. If\n  you prefer to just get this patch and get rid of the\n  problem then tell me.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "4035eca87144c47527ff46ee4ed937d8f97b8f2d",
      "old_mode": 33188,
      "old_path": "Documentation/devices.txt",
      "new_id": "2a4242be2fcd34c3f984a68aa7e436a921f1c875",
      "new_mode": 33188,
      "new_path": "Documentation/devices.txt"
    },
    {
      "type": "modify",
      "old_id": "687471dc04a0a515f4a8dc4953297e6156880b64",
      "old_mode": 33188,
      "old_path": "fs/char_dev.c",
      "new_id": "b647cc813a2c4dae33d4eeeab067a917e9b09f42",
      "new_mode": 33188,
      "new_path": "fs/char_dev.c"
    },
    {
      "type": "modify",
      "old_id": "299e76b59fe9b0330254f608863f7237ed97c802",
      "old_mode": 33188,
      "old_path": "include/linux/bitops.h",
      "new_id": "eebd4b1c100ad68d154dcb1baa308913e884b6e0",
      "new_mode": 33188,
      "new_path": "include/linux/bitops.h"
    },
    {
      "type": "modify",
      "old_id": "b8b3c72c2aae3d246f0af562c9b4a99f2eaa7924",
      "old_mode": 33188,
      "old_path": "include/linux/fs.h",
      "new_id": "10d3d8f8a65b20c2c103b5c5b60666bb2f021fff",
      "new_mode": 33188,
      "new_path": "include/linux/fs.h"
    }
  ]
}