{"push_id":1249484179,"size":11,"distinct_size":11,"ref":"refs/heads/upstream","head":"801fe0bc98bbfad7de633bf5ea7deeb3babcdfef","before":"29ebdeab7701e966fb956600694cc0ad01de1296","commits":[{"sha":"a69e06503481c7acc090a19ce7033c9a79150814","author":{"name":"Joe Lawrence","email":"54448cb6bcb7f6b9e33bae1a9cc93249cb9c1e88@stratus.com"},"message":"usb: hub: take hub->hdev reference when processing from eventlist\n\ncommit c605f3cdff53a743f6d875b76956b239deca1272 upstream.\n\nDuring surprise device hotplug removal tests, it was observed that\nhub_events may try to call usb_lock_device on a device that has already\nbeen freed. Protect the usb_device by taking out a reference (under the\nhub_event_lock) when hub_events pulls it off the list, returning the\nreference after hub_events is finished using it.\n\nSigned-off-by: Joe Lawrence <joe.lawrence@stratus.com>\nSuggested-by: David Bulkow <david.bulkow@stratus.com> for using kref\nSuggested-by: Alan Stern <stern@rowland.harvard.edu> for placement\nAcked-by: Alan Stern <stern@rowland.harvard.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\n\nConflicts:\n\tdrivers/usb/core/hub.c","distinct":true,"url":"https://api.github.com/repos/FireLord1/android_kernel_motorola_msm8916/commits/a69e06503481c7acc090a19ce7033c9a79150814"},{"sha":"12246c05a2aa9597b9b525dde952539e73c3dbef","author":{"name":"Mark","email":"e146138bdc8ca4cea43838559721d5caa61f9da0@clara.co.uk"},"message":"storage: Add single-LUN quirk for Jaz USB Adapter\n\ncommit c66f1c62e85927357e7b3f4c701614dcb5c498a2 upstream.\n\nThe Iomega Jaz USB Adapter is a SCSI-USB converter cable. The hardware\nseems to be identical to e.g. the Microtech XpressSCSI, using a Shuttle/\nSCM chip set. However its firmware restricts it to only work with Jaz\ndrives.\n\nOn connecting the cable a message like this appears four times in the log:\n reset full speed USB device number 4 using uhci_hcd\n\nThat's non-fatal but the US_FL_SINGLE_LUN quirk fixes it.\n\nSigned-off-by: Mark Knibbs <markk@clara.co.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/FireLord1/android_kernel_motorola_msm8916/commits/12246c05a2aa9597b9b525dde952539e73c3dbef"},{"sha":"a0c16cc98017ea8d03c0646ac4994f63e5b9583e","author":{"name":"Mark","email":"e146138bdc8ca4cea43838559721d5caa61f9da0@clara.co.uk"},"message":"USB: storage: Add quirk for Adaptec USBConnect 2000 USB-to-SCSI Adapter\n\ncommit 67d365a57a51fb9dece6a5ceb504aa381cae1e5b upstream.\n\nThe Adaptec USBConnect 2000 is another SCSI-USB converter which uses\nShuttle Technology/SCM Microsystems chips. The US_FL_SCM_MULT_TARG quirk is\nrequired to use SCSI devices with ID other than 0.\n\nI don't have a USBConnect 2000, but based on the other entries for Shuttle/\nSCM-based converters this patch is very likely correct. I used 0x0000 and\n0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which\nbcdDevice value the product uses.\n\nSigned-off-by: Mark Knibbs <markk@clara.co.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/FireLord1/android_kernel_motorola_msm8916/commits/a0c16cc98017ea8d03c0646ac4994f63e5b9583e"},{"sha":"28734f13b927455b99b06966b60b7b60c429f3a0","author":{"name":"Mark","email":"e146138bdc8ca4cea43838559721d5caa61f9da0@clara.co.uk"},"message":"USB: storage: Add quirk for Ariston Technologies iConnect USB to SCSI adapter\n\ncommit b6a3ed677991558ce09046397a7c4d70530d15b3 upstream.\n\nHi,\n\nThe Ariston Technologies iConnect 025 and iConnect 050 (also known as e.g.\niSCSI-50) are SCSI-USB converters which use Shuttle Technology/SCM\nMicrosystems chips. Only the connectors differ; both have the same USB ID.\nThe US_FL_SCM_MULT_TARG quirk is required to use SCSI devices with ID other\nthan 0.\n\nI don't have one of these, but based on the other entries for Shuttle/\nSCM-based converters this patch is very likely correct. I used 0x0000 and\n0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which\nbcdDevice value the products use.\n\nSigned-off-by: Mark Knibbs <markk@clara.co.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/FireLord1/android_kernel_motorola_msm8916/commits/28734f13b927455b99b06966b60b7b60c429f3a0"},{"sha":"877f3ff8b5fa03317974100c385d70e722745ecb","author":{"name":"Mark","email":"e146138bdc8ca4cea43838559721d5caa61f9da0@clara.co.uk"},"message":"USB: storage: Add quirks for Entrega/Xircom USB to SCSI converters\n\ncommit c80b4495c61636edc58fe1ce300f09f24db28e10 upstream.\n\nThis patch adds quirks for Entrega Technologies (later Xircom PortGear) USB-\nSCSI converters. They use Shuttle Technology EUSB-01/EUSB-S1 chips. The\nUS_FL_SCM_MULT_TARG quirk is needed to allow multiple devices on the SCSI\nchain to be accessed. Without it only the (single) device with SCSI ID 0\ncan be used.\n\nThe standalone converter sold by Entrega had model number U1-SC25. Xircom\nacquired Entrega and re-branded the product line PortGear. The PortGear USB\nto SCSI Converter (model PGSCSI) is internally identical to the Entrega\nproduct, but later models may use a different USB ID. The Entrega-branded\nunits have USB ID 1645:0007, as does my Xircom PGSCSI, but the Windows and\nMacintosh drivers also support 085A:0028.\n\nEntrega also sold the \"Mac USB Dock\", which provides two USB ports, a Mac\n(8-pin mini-DIN) serial port and a SCSI port. It appears to the computer as\na four-port hub, USB-serial, and USB-SCSI converters. The USB-SCSI part may\nhave initially used the same ID as the standalone U1-SC25 (1645:0007), but\nlater production used 085A:0026.\n\nMy Xircom PortGear PGSCSI has bcdDevice=0x0100. Units with bcdDevice=0x0133\nprobably also exist.\n\nThis patch adds quirks for 1645:0007, 085A:0026 and 085A:0028. The Windows\ndriver INF file also mentions 085A:0032 \"PortStation SCSI Module\", but I\ncouldn't find any mention of that actually existing in the wild; perhaps it\nwas cancelled before release?\n\nSigned-off-by: Mark Knibbs <markk@clara.co.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/FireLord1/android_kernel_motorola_msm8916/commits/877f3ff8b5fa03317974100c385d70e722745ecb"},{"sha":"713d9336b777d701c908ff0f7d50a81347e67d0e","author":{"name":"Alan Stern","email":"5c4cbde65af01ad64f5b2177d0cd78ab5b01e5a1@rowland.harvard.edu"},"message":"USB: EHCI: unlink QHs even after the controller has stopped\n\ncommit 7312b5ddd47fee2356baa78c5516ef8e04eed452 upstream.\n\nOld code in ehci-hcd tries to expedite disabling endpoints after the\ncontroller has stopped, by destroying the endpoint's associated QH\nwithout first unlinking the QH.  This was necessary back when the\ndriver wasn't so careful about keeping track of the controller's\nstate.\n\nBut now we are careful about it, and the driver knows that when the\ncontroller isn't running, no unlinking delay is needed.  Furthermore,\nskipping the unlink step will trigger a BUG() in qh_destroy() when the\npreceding QH is released, because the link pointer will be non-NULL.\n\nRemoving the lines that skip the unlinking step and go directly to\nQH_STATE_IDLE fixes the problem.\n\nSigned-off-by: Alan Stern <stern@rowland.harvard.edu>\nReported-by: Joe Lawrence <joe.lawrence@stratus.com>\nTested-by: Joe Lawrence <joe.lawrence@stratus.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/FireLord1/android_kernel_motorola_msm8916/commits/713d9336b777d701c908ff0f7d50a81347e67d0e"},{"sha":"ef32e8f4ccab96fc97ac97f410b3d216083a6dd2","author":{"name":"Felipe Balbi","email":"a1170a0bbfdf20ea33742284efaaf12a58126ab7@ti.com"},"message":"usb: dwc3: omap: fix ordering for runtime pm calls\n\ncommit 81a60b7f5c143ab3cdcd9943c9b4b7c63c32fc31 upstream.\n\nwe don't to gate clocks until our children are\ndone with their remove path.\n\nFixes: af310e9 (usb: dwc3: omap: use runtime API's to enable clocks)\nSigned-off-by: Felipe Balbi <balbi@ti.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/FireLord1/android_kernel_motorola_msm8916/commits/ef32e8f4ccab96fc97ac97f410b3d216083a6dd2"},{"sha":"5d3b7bea237930c87183348c7a21552807a7a55a","author":{"name":"Shen Guang","email":"c9a0df85d5937e71c51995548fbda7f96269049a@gmail.com"},"message":"usb:hub set hub->change_bits when over-current happens\n\ncommit 08d1dec6f4054e3613f32051d9b149d4203ce0d2 upstream.\n\nWhen we are doing compliance test with xHCI, we found that if we\nenable CONFIG_USB_SUSPEND and plug in a bad device which causes\nover-current condition to the root port, software will not be noticed.\nThe reason is that current code don't set hub->change_bits in\nhub_activate() when over-current happens, and then hub_events() will\nnot check the port status because it thinks nothing changed.\nIf CONFIG_USB_SUSPEND is disabled, the interrupt pipe of the hub will\nreport the change and set hub->event_bits, and then hub_events() will\ncheck what events happened.In this case over-current can be detected.\n\nSigned-off-by: Shen Guang <shenguang10@gmail.com>\nAcked-by: Alan Stern <stern@rowland.harvard.edu>\nAcked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>\nCc: Frans Klaver <fransklaver@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/FireLord1/android_kernel_motorola_msm8916/commits/5d3b7bea237930c87183348c7a21552807a7a55a"},{"sha":"3a887d5913f9aab0c2eff2acdcd66a540f1c5b39","author":{"name":"Steve Dickson","email":"dbfe8ed8f67dc1b6d567928fb88ff64a364fa779@redhat.com"},"message":"NFSv4: nfs4_state_manager() vs. nfs_server_remove_lists()\n\ncommit 080af20cc945d110f9912d01cf6b66f94a375b8d upstream.\n\nThere is a race between nfs4_state_manager() and\nnfs_server_remove_lists() that happens during a nfsv3 mount.\n\nThe v3 mount notices there is already a supper block so\nnfs_server_remove_lists() called which uses the nfs_client_lock\nspin lock to synchronize access to the client list.\n\nAt the same time nfs4_state_manager() is running through\nthe client list looking for work to do, using the same\nlock. When nfs4_state_manager() wins the race to the\nlist, a v3 client pointer is found and not ignored\nproperly which causes the panic.\n\nMoving some protocol checks before the state checking\navoids the panic.\n\nSigned-off-by: Steve Dickson <steved@redhat.com>\nSigned-off-by: Trond Myklebust <trond.myklebust@primarydata.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/FireLord1/android_kernel_motorola_msm8916/commits/3a887d5913f9aab0c2eff2acdcd66a540f1c5b39"},{"sha":"0c00a663c618010c25f651ed45146ae1c6dcc37e","author":{"name":"Trond Myklebust","email":"74f7b75b0dfb06f182c703b16f16eeff3727673a@primarydata.com"},"message":"NFSv4: Fix another bug in the close/open_downgrade code\n\ncommit cd9288ffaea4359d5cfe2b8d264911506aed26a4 upstream.\n\nJames Drew reports another bug whereby the NFS client is now sending\nan OPEN_DOWNGRADE in a situation where it should really have sent a\nCLOSE: the client is opening the file for O_RDWR, but then trying to\ndo a downgrade to O_RDONLY, which is not allowed by the NFSv4 spec.\n\nReported-by: James Drews <drews@engr.wisc.edu>\nLink: http://lkml.kernel.org/r/541AD7E5.8020409@engr.wisc.edu\nFixes: aee7af356e15 (NFSv4: Fix problems with close in the presence...)\nSigned-off-by: Trond Myklebust <trond.myklebust@primarydata.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/FireLord1/android_kernel_motorola_msm8916/commits/0c00a663c618010c25f651ed45146ae1c6dcc37e"},{"sha":"801fe0bc98bbfad7de633bf5ea7deeb3babcdfef","author":{"name":"Mark Rutland","email":"7bbc68f29a82fb2eb4daac9d4df0c3f473a4ef26@arm.com"},"message":"ARM: 8128/1: abort: don't clear the exclusive monitors\n\ncommit 85868313177700d20644263a782351262d2aff84 upstream.\n\nThe ARMv6 and ARMv7 early abort handlers clear the exclusive monitors\nupon entry to the kernel, but this is redundant:\n\n  - We clear the monitors on every exception return since commit\n    200b812d0084 (\"Clear the exclusive monitor when returning from an\n    exception\"), so this is not necessary to ensure the monitors are\n    cleared before returning from a fault handler.\n\n  - Any dummy STREX will target a temporary scratch area in memory, and\n    may succeed or fail without corrupting useful data. Its status value\n    will not be used.\n\n  - Any other STREX in the kernel must be preceded by an LDREX, which\n    will initialise the monitors consistently and will not depend on the\n    earlier state of the monitors.\n\nTherefore we have no reason to care about the initial state of the\nexclusive monitors when a data abort is taken, and clearing the monitors\nprior to exception return (as we already do) is sufficient.\n\nThis patch removes the redundant clearing of the exclusive monitors from\nthe early abort handlers.\n\nSigned-off-by: Mark Rutland <mark.rutland@arm.com>\nAcked-by: Will Deacon <will.deacon@arm.com>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/FireLord1/android_kernel_motorola_msm8916/commits/801fe0bc98bbfad7de633bf5ea7deeb3babcdfef"}]}
{"actor":{"display_login":"FireLord1"}}