)]}'
{
  "commit": "3ac06b905655b3ef2fd2196bab36e4587e1e4e4f",
  "tree": "ec6dceb64acec0124f0a09e79df2acfd4cab0f35",
  "parents": [
    "4fedd0bf479558e50924c6d88f9197336742d20f"
  ],
  "author": {
    "name": "Lars Poeschel",
    "email": "poeschel@lemonage.de",
    "time": "Tue Jan 07 13:34:37 2014 +0100"
  },
  "committer": {
    "name": "Greg Kroah-Hartman",
    "email": "gregkh@linuxfoundation.org",
    "time": "Fri Feb 07 08:40:54 2014 -0800"
  },
  "message": "tty: n_gsm: Fix for modems with brk in modem status control\n\n3GPP TS 07.10 states in section 5.4.6.3.7:\n\"The length byte contains the value 2 or 3 ... depending on the break\nsignal.\" The break byte is optional and if it is sent, the length is\n3. In fact the driver was not able to work with modems that send this\nbreak byte in their modem status control message. If the modem just\nsends the break byte if it is really set, then weird things might\nhappen.\nThe code for deconding the modem status to the internal linux\npresentation in gsm_process_modem has already a big comment about\nthis 2 or 3 byte length thing and it is already able to decode the\nbrk, but the code calling the gsm_process_modem function in\ngsm_control_modem does not encode it and hand it over the right way.\nThis patch fixes this.\nWithout this fix if the modem sends the brk byte in it\u0027s modem status\ncontrol message the driver will hang when opening a muxed channel.\n\nSigned-off-by: Lars Poeschel \u003cpoeschel@lemonage.de\u003e\nCc: stable \u003cstable@vger.kernel.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "f34461c5f14e102cbf64dba861e46a4a94820ecb",
      "old_mode": 33188,
      "old_path": "drivers/tty/n_gsm.c",
      "new_id": "2ebe47b78a3e3ba48093d46164bee6247a32295e",
      "new_mode": 33188,
      "new_path": "drivers/tty/n_gsm.c"
    }
  ]
}