)]}'
{
  "log": [
    {
      "commit": "64f68e5d15bee47e0d6d0c57a1cf52cedd9b3527",
      "tree": "e000cea46fd57d876d725224d2b51b74cec35572",
      "parents": [
        "24398e39c8ee4a9d9123eed322b859ece4d16cac"
      ],
      "author": {
        "name": "Johannes Berg",
        "email": "johannes.berg@intel.com",
        "time": "Wed Mar 28 10:58:37 2012 +0200"
      },
      "committer": {
        "name": "John W. Linville",
        "email": "linville@tuxdriver.com",
        "time": "Tue Apr 10 14:54:08 2012 -0400"
      },
      "message": "mac80211: remove channel type argument from rate_update\n\nThe channel type argument to the rate_update()\ncallback isn\u0027t really the correct way to give\nthe rate control algorithm about the desired\nRX bandwidth of the peer.\n\nRemove this argument, and instead update the\nSTA capabilities with 20/40 appropriately. The\nSMPS update done by this callback works in the\nsame way, so this makes the callback cleaner.\n\nSigned-off-by: Johannes Berg \u003cjohannes.berg@intel.com\u003e\nSigned-off-by: John W. Linville \u003clinville@tuxdriver.com\u003e\n"
    },
    {
      "commit": "3117bbdb7899d43927c8ce4fe885ab7c1231c121",
      "tree": "d2fc142e77a9d90d9054f45e666457c901bd8975",
      "parents": [
        "e9ac0745c734d39cb55ce45f1fb03a85c972b35a"
      ],
      "author": {
        "name": "Paul Stewart",
        "email": "pstew@chromium.org",
        "time": "Tue Mar 13 07:46:18 2012 -0700"
      },
      "committer": {
        "name": "John W. Linville",
        "email": "linville@tuxdriver.com",
        "time": "Tue Mar 13 14:55:53 2012 -0400"
      },
      "message": "mac80211: Don\u0027t let regulatory make us deaf\n\nWhen regulatory information changes our HT behavior (e.g,\nwhen we get a country code from the AP we have just associated\nwith), we should use this information to change the power with\nwhich we transmit, and what channels we transmit.  Sometimes\nthe channel parameters we derive from regulatory information\ncontradicts the parameters we used in association.  For example,\nwe could have associated specifying HT40, but the regulatory\nrules we apply may forbid HT40 operation.\n\nIn the situation above, we should reconfigure ourselves to\ntransmit in HT20 only, however it makes no sense for us to\ndisable receive in HT40, since if we associated with these\nparameters, the AP has every reason to expect we can and\nwill receive packets this way.  The code in mac80211 does\nnot have the capability of sending the appropriate action\nframes to signal a change in HT behaviour so the AP has\nno clue we can no longer receive frames encoded this way.\nIn some broken AP implementations, this can leave us\neffectively deaf if the AP never retries in lower HT rates.\n\nThis change breaks up the channel_type parameter in the\nieee80211_enable_ht function into a separate receive and\ntransmit part.  It honors the channel flags set by regulatory\nin order to configure the rate control algorithm, but uses\nthe capability flags to configure the channel on the radio,\nsince these were used in association to set the AP\u0027s transmit\nrate.\n\nSigned-off-by: Paul Stewart \u003cpstew@chromium.org\u003e\nCc: Sam Leffler \u003csleffler@chromium.org\u003e\nCc: Johannes Berg \u003cjohannes@sipsolutions.net\u003e\nReviewed-by: Luis R Rodriguez \u003cmcgrof@frijolero.org\u003e\nSigned-off-by: John W. Linville \u003clinville@tuxdriver.com\u003e\n"
    },
    {
      "commit": "e9980e6d20a5c4d3f52359142ab3569171759a5b",
      "tree": "d117e03b078a089a6554ebe8c28f1e4c545102f8",
      "parents": [
        "75ac9a28a0c6b818ba1aba874b6b3ae17241552c"
      ],
      "author": {
        "name": "Johannes Berg",
        "email": "johannes.berg@intel.com",
        "time": "Mon Jan 09 13:57:36 2012 +0100"
      },
      "committer": {
        "name": "John W. Linville",
        "email": "linville@tuxdriver.com",
        "time": "Tue Jan 24 14:08:39 2012 -0500"
      },
      "message": "mac80211: refactor __ieee80211_get_channel_mode\n\nUse a switch statement instead of a list of if\nstatements. Also include AP_VLAN in the list\nand skip them since the AP interface will also\nbe looked at.\n\nSigned-off-by: Johannes Berg \u003cjohannes.berg@intel.com\u003e\nSigned-off-by: John W. Linville \u003clinville@tuxdriver.com\u003e\n"
    },
    {
      "commit": "9db372fdd5de9e0464c77a9d3db2a3b356db8668",
      "tree": "25b417873775cf02d9f1d05cf70d70d5b3897986",
      "parents": [
        "efff395e97fffd55c60c77c09a18deba8d84e2c0"
      ],
      "author": {
        "name": "Felix Fietkau",
        "email": "nbd@openwrt.org",
        "time": "Fri Mar 11 21:45:51 2011 +0100"
      },
      "committer": {
        "name": "John W. Linville",
        "email": "linville@tuxdriver.com",
        "time": "Mon Mar 14 14:46:58 2011 -0400"
      },
      "message": "mac80211: fix channel type recalculation with HT and non-HT interfaces\n\nWhen running an AP interface along with the cooked monitor interface created\nby hostapd, adding an interface and deleting it again triggers a channel type\nrecalculation during which the (non-HT) monitor interface takes precedence\nover the HT AP interface, thus causing the channel type to be set to non-HT.\nFix this by ensuring that a more wide channel type will not be overwritten\nby a less wide channel type.\n\nSigned-off-by: Felix Fietkau \u003cnbd@openwrt.org\u003e\nSigned-off-by: John W. Linville \u003clinville@tuxdriver.com\u003e\n"
    },
    {
      "commit": "46a5ebaf02d69e26ee0f47a0b8d2d9bc619240d4",
      "tree": "77bc5ceee61ce125c4b608d7b979bf8d033ffdcc",
      "parents": [
        "f5521b13880f4f4f612e1d20dd4f565122d16e04"
      ],
      "author": {
        "name": "Johannes Berg",
        "email": "johannes.berg@intel.com",
        "time": "Wed Sep 15 13:28:15 2010 +0200"
      },
      "committer": {
        "name": "John W. Linville",
        "email": "linville@tuxdriver.com",
        "time": "Thu Sep 16 15:46:00 2010 -0400"
      },
      "message": "cfg80211/mac80211: use lockdep_assert_held\n\nInstead of using a WARN_ON(!mutex_is_locked())\nuse lockdep_assert_held() which compiles away\ncompletely when lockdep isn\u0027t enabled, and\nalso is a more accurate assertion since it\nchecks that the current thread is holding the\nmutex.\n\nSigned-off-by: Johannes Berg \u003cjohannes.berg@intel.com\u003e\nSigned-off-by: John W. Linville \u003clinville@tuxdriver.com\u003e\n"
    },
    {
      "commit": "368a07d26ae99c80678a968946744fd83e7708d0",
      "tree": "40284ed5b7a683ce44f95e479fcd3c996090442e",
      "parents": [
        "c6a6368b32aa4fd145e840c8d8dac6923fae2688"
      ],
      "author": {
        "name": "Johannes Berg",
        "email": "johannes@sipsolutions.net",
        "time": "Fri May 28 14:26:23 2010 +0200"
      },
      "committer": {
        "name": "John W. Linville",
        "email": "linville@tuxdriver.com",
        "time": "Fri May 28 13:41:27 2010 -0400"
      },
      "message": "mac80211: make a function static\n\nsparse correctly complains that\n__ieee80211_get_channel_mode is not static.\n\nSigned-off-by: Johannes Berg \u003cjohannes@sipsolutions.net\u003e\nSigned-off-by: John W. Linville \u003clinville@tuxdriver.com\u003e\n"
    },
    {
      "commit": "0aaffa9b9699894aab3266195a529baf9f96ac29",
      "tree": "26fe5f5277ac6d7061ea723f92d4038b0c28b0b8",
      "parents": [
        "f444de05d20e27cdd960c13fcbcfca3099f03143"
      ],
      "author": {
        "name": "Johannes Berg",
        "email": "johannes@sipsolutions.net",
        "time": "Wed May 05 15:28:27 2010 +0200"
      },
      "committer": {
        "name": "John W. Linville",
        "email": "linville@tuxdriver.com",
        "time": "Fri May 07 14:55:51 2010 -0400"
      },
      "message": "mac80211: improve HT channel handling\n\nCurrently, when one interface switches HT mode,\nall others will follow along. This is clearly\nundesirable, since the new one might switch to\nno-HT while another one is operating in HT.\n\nAddress this issue by keeping track of the HT\nmode per interface, and allowing only changes\nthat are compatible, i.e. switching into HT40+\nis not possible when another interface is in\nHT40-, in that case the second one needs to\nfall back to HT20.\n\nAlso, to allow drivers to know what\u0027s going on,\nstore the per-interface HT mode (channel type)\nin the virtual interface\u0027s bss_conf.\n\nSigned-off-by: Johannes Berg \u003cjohannes@sipsolutions.net\u003e\nSigned-off-by: John W. Linville \u003clinville@tuxdriver.com\u003e\n"
    },
    {
      "commit": "f444de05d20e27cdd960c13fcbcfca3099f03143",
      "tree": "a7fbef60420d88dda5840e06094be21ee3eb1dc0",
      "parents": [
        "ac8dd506e40ee2c7fcc61654a44c32555a0a8d6c"
      ],
      "author": {
        "name": "Johannes Berg",
        "email": "johannes@sipsolutions.net",
        "time": "Wed May 05 15:25:02 2010 +0200"
      },
      "committer": {
        "name": "John W. Linville",
        "email": "linville@tuxdriver.com",
        "time": "Fri May 07 14:55:50 2010 -0400"
      },
      "message": "cfg80211/mac80211: better channel handling\n\nCurrently (all tested with hwsim) you can do stupid\nthings like setting up an AP on a certain channel,\nthen adding another virtual interface and making\nthat associate on another channel -- this will make\nthe beaconing to move channel but obviously without\nthe necessary IEs data update.\n\nIn order to improve this situation, first make the\nconfiguration APIs (cfg80211 and nl80211) aware of\nmulti-channel operation -- we\u0027ll eventually need\nthat in the future anyway. There\u0027s one userland API\nchange and one API addition. The API change is that\nnow SET_WIPHY must be called with virtual interface\nindex rather than only wiphy index in order to take\neffect for that interface -- luckily all current\nusers (hostapd) do that. For monitor interfaces, the\nold setting is preserved, but monitors are always\nslaved to other devices anyway so no guarantees.\n\nThe second userland API change is the introduction\nof a per virtual interface SET_CHANNEL command, that\nhostapd should use going forward to make it easier\nto understand what\u0027s going on (it can automatically\ndetect a kernel with this command).\n\nOther than mac80211, no existing cfg80211 drivers\nare affected by this change because they only allow\na single virtual interface.\n\nmac80211, however, now needs to be aware that the\nchannel settings are per interface now, and needs\nto disallow (for now) real multi-channel operation,\nwhich is another important part of this patch.\n\nOne of the immediate benefits is that you can now\nstart hostapd to operate on a hardware that already\nhas a connection on another virtual interface, as\nlong as you specify the same channel.\n\nNote that two things are left unhandled (this is an\nimprovement -- not a complete fix):\n\n * different HT/no-HT modes\n\n   currently you could start an HT AP and then\n   connect to a non-HT network on the same channel\n   which would configure the hardware for no HT;\n   that can be fixed fairly easily\n\n * CSA\n\n   An AP we\u0027re connected to on a virtual interface\n   might indicate switching channels, and in that\n   case we would follow it, regardless of how many\n   other interfaces are operating; this requires\n   more effort to fix but is pretty rare after all\n\nSigned-off-by: Johannes Berg \u003cjohannes@sipsolutions.net\u003e\nSigned-off-by: John W. Linville \u003clinville@tuxdriver.com\u003e\n"
    }
  ]
}