{"push_id":2762235810,"size":25,"distinct_size":0,"ref":"refs/heads/linaro/linux-linaro-lsk-v4.4","head":"4fa7c16a310c6abbf6873659655c3e9fb1bdc4ce","before":"606b3effb9ce2ab6f67eeecace381c701d411ecf","commits":[{"sha":"54a634c43ae75031c03126957edf667dba1439ec","author":{"name":"Felix Fietkau","email":"118ed6118e893d16e8c6e0776e0ebc290952c897@nbd.name"},"message":"MIPS: ath79: fix register address in ath79_ddr_wb_flush()\n\ncommit bc88ad2efd11f29e00a4fd60fcd1887abfe76833 upstream.\n\nath79_ddr_wb_flush_base has the type void __iomem *, so register offsets\nneed to be a multiple of 4 in order to access the intended register.\n\nSigned-off-by: Felix Fietkau <nbd@nbd.name>\nSigned-off-by: John Crispin <john@phrozen.org>\nSigned-off-by: Paul Burton <paul.burton@mips.com>\nFixes: 24b0e3e84fbf (\"MIPS: ath79: Improve the DDR controller interface\")\nPatchwork: https://patchwork.linux-mips.org/patch/19912/\nCc: Alban Bedel <albeu@free.fr>\nCc: James Hogan <jhogan@kernel.org>\nCc: Ralf Baechle <ralf@linux-mips.org>\nCc: linux-mips@linux-mips.org\nCc: stable@vger.kernel.org # 4.2+\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/54a634c43ae75031c03126957edf667dba1439ec"},{"sha":"48f41c0c5781e3450830f8ec68513bfa18a5451b","author":{"name":"Paolo Abeni","email":"6e4ffc2e3438feb7acb34f6b67e6ae17e700099c@redhat.com"},"message":"ip: hash fragments consistently\n\n[ Upstream commit 3dd1c9a1270736029ffca670e9bd0265f4120600 ]\n\nThe skb hash for locally generated ip[v6] fragments belonging\nto the same datagram can vary in several circumstances:\n* for connected UDP[v6] sockets, the first fragment get its hash\n  via set_owner_w()/skb_set_hash_from_sk()\n* for unconnected IPv6 UDPv6 sockets, the first fragment can get\n  its hash via ip6_make_flowlabel()/skb_get_hash_flowi6(), if\n  auto_flowlabel is enabled\n\nFor the following frags the hash is usually computed via\nskb_get_hash().\nThe above can cause OoO for unconnected IPv6 UDPv6 socket: in that\nscenario the egress tx queue can be selected on a per packet basis\nvia the skb hash.\nIt may also fool flow-oriented schedulers to place fragments belonging\nto the same datagram in different flows.\n\nFix the issue by copying the skb hash from the head frag into\nthe others at fragmentation time.\n\nBefore this commit:\nperf probe -a \"dev_queue_xmit skb skb->hash skb->l4_hash:b1@0/8 skb->sw_hash:b1@1/8\"\nnetperf -H $IPV4 -t UDP_STREAM -l 5 -- -m 2000 -n &\nperf record -e probe:dev_queue_xmit -e probe:skb_set_owner_w -a sleep 0.1\nperf script\nprobe:dev_queue_xmit: (ffffffff8c6b1b20) hash=3713014309 l4_hash=1 sw_hash=0\nprobe:dev_queue_xmit: (ffffffff8c6b1b20) hash=0 l4_hash=0 sw_hash=0\n\nAfter this commit:\nprobe:dev_queue_xmit: (ffffffff8c6b1b20) hash=2171763177 l4_hash=1 sw_hash=0\nprobe:dev_queue_xmit: (ffffffff8c6b1b20) hash=2171763177 l4_hash=1 sw_hash=0\n\nFixes: b73c3d0e4f0e (\"net: Save TX flow hash in sock and set in skbuf on xmit\")\nFixes: 67800f9b1f4e (\"ipv6: Call skb_get_hash_flowi6 to get skb->hash in ip6_make_flowlabel\")\nSigned-off-by: Paolo Abeni <pabeni@redhat.com>\nReviewed-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/48f41c0c5781e3450830f8ec68513bfa18a5451b"},{"sha":"73dad08709fee646875f5a81c07b05fb54582732","author":{"name":"Jack Morgenstein","email":"067deeb0d1a5180729b0e79bbb5b609fc5bbbab4@dev.mellanox.co.il"},"message":"net/mlx4_core: Save the qpn from the input modifier in RST2INIT wrapper\n\n[ Upstream commit 958c696f5a7274d9447a458ad7aa70719b29a50a ]\n\nFunction mlx4_RST2INIT_QP_wrapper saved the qp number passed in the qp\ncontext, rather than the one passed in the input modifier.\n\nHowever, the qp number in the qp context is not defined as a\nrequired parameter by the FW. Therefore, drivers may choose to not\nspecify the qp number in the qp context for the reset-to-init transition.\n\nThus, we must save the qp number passed in the command input modifier --\nwhich is always present. (This saved qp number is used as the input\nmodifier for command 2RST_QP when a slave's qp's are destroyed).\n\nFixes: c82e9aa0a8bc (\"mlx4_core: resource tracking for HCA resources used by guests\")\nSigned-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>\nSigned-off-by: Tariq Toukan <tariqt@mellanox.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/73dad08709fee646875f5a81c07b05fb54582732"},{"sha":"b04c9a08710606e2fa0a16f24541a270c00ef58c","author":{"name":"Roopa Prabhu","email":"d3f6ba90004ada8c36186a20548ed980b7e493d1@cumulusnetworks.com"},"message":"rtnetlink: add rtnl_link_state check in rtnl_configure_link\n\n[ Upstream commit 5025f7f7d506fba9b39e7fe8ca10f6f34cb9bc2d ]\n\nrtnl_configure_link sets dev->rtnl_link_state to\nRTNL_LINK_INITIALIZED and unconditionally calls\n__dev_notify_flags to notify user-space of dev flags.\n\ncurrent call sequence for rtnl_configure_link\nrtnetlink_newlink\n    rtnl_link_ops->newlink\n    rtnl_configure_link (unconditionally notifies userspace of\n                         default and new dev flags)\n\nIf a newlink handler wants to call rtnl_configure_link\nearly, we will end up with duplicate notifications to\nuser-space.\n\nThis patch fixes rtnl_configure_link to check rtnl_link_state\nand call __dev_notify_flags with gchanges = 0 if already\nRTNL_LINK_INITIALIZED.\n\nLater in the series, this patch will help the following sequence\nwhere a driver implementing newlink can call rtnl_configure_link\nto initialize the link early.\n\nmakes the following call sequence work:\nrtnetlink_newlink\n    rtnl_link_ops->newlink (vxlan) -> rtnl_configure_link (initializes\n                                                link and notifies\n                                                user-space of default\n                                                dev flags)\n    rtnl_configure_link (updates dev flags if requested by user ifm\n                         and notifies user-space of new dev flags)\n\nSigned-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/b04c9a08710606e2fa0a16f24541a270c00ef58c"},{"sha":"500e03f463835e74c75890d56d9a7ab63755aa2d","author":{"name":"Yuchung Cheng","email":"5b5a0a360fa35167ac197fe6359c229fde284cf2@google.com"},"message":"tcp: fix dctcp delayed ACK schedule\n\n[ Upstream commit b0c05d0e99d98d7f0cd41efc1eeec94efdc3325d ]\n\nPreviously, when a data segment was sent an ACK was piggybacked\non the data segment without generating a CA_EVENT_NON_DELAYED_ACK\nevent to notify congestion control modules. So the DCTCP\nca->delayed_ack_reserved flag could incorrectly stay set when\nin fact there were no delayed ACKs being reserved. This could result\nin sending a special ECN notification ACK that carries an older\nACK sequence, when in fact there was no need for such an ACK.\nDCTCP keeps track of the delayed ACK status with its own separate\nstate ca->delayed_ack_reserved. Previously it may accidentally cancel\nthe delayed ACK without updating this field upon sending a special\nACK that carries a older ACK sequence. This inconsistency would\nlead to DCTCP receiver never acknowledging the latest data until the\nsender times out and retry in some cases.\n\nPacketdrill script (provided by Larry Brakmo)\n\n0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3\n0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0\n0.000 setsockopt(3, SOL_TCP, TCP_CONGESTION, \"dctcp\", 5) = 0\n0.000 bind(3, ..., ...) = 0\n0.000 listen(3, 1) = 0\n\n0.100 < [ect0] SEW 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>\n0.100 > SE. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8>\n0.110 < [ect0] . 1:1(0) ack 1 win 257\n0.200 accept(3, ..., ...) = 4\n\n0.200 < [ect0] . 1:1001(1000) ack 1 win 257\n0.200 > [ect01] . 1:1(0) ack 1001\n\n0.200 write(4, ..., 1) = 1\n0.200 > [ect01] P. 1:2(1) ack 1001\n\n0.200 < [ect0] . 1001:2001(1000) ack 2 win 257\n0.200 write(4, ..., 1) = 1\n0.200 > [ect01] P. 2:3(1) ack 2001\n\n0.200 < [ect0] . 2001:3001(1000) ack 3 win 257\n0.200 < [ect0] . 3001:4001(1000) ack 3 win 257\n0.200 > [ect01] . 3:3(0) ack 4001\n\n0.210 < [ce] P. 4001:4501(500) ack 3 win 257\n\n+0.001 read(4, ..., 4500) = 4500\n+0 write(4, ..., 1) = 1\n+0 > [ect01] PE. 3:4(1) ack 4501\n\n+0.010 < [ect0] W. 4501:5501(1000) ack 4 win 257\n// Previously the ACK sequence below would be 4501, causing a long RTO\n+0.040~+0.045 > [ect01] . 4:4(0) ack 5501   // delayed ack\n\n+0.311 < [ect0] . 5501:6501(1000) ack 4 win 257  // More data\n+0 > [ect01] . 4:4(0) ack 6501     // now acks everything\n\n+0.500 < F. 9501:9501(0) ack 4 win 257\n\nReported-by: Larry Brakmo <brakmo@fb.com>\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nAcked-by: Neal Cardwell <ncardwell@google.com>\nAcked-by: Lawrence Brakmo <brakmo@fb.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/500e03f463835e74c75890d56d9a7ab63755aa2d"},{"sha":"17fea38e74ab24afb06970bbd9dc52db11a8034b","author":{"name":"Yuchung Cheng","email":"5b5a0a360fa35167ac197fe6359c229fde284cf2@google.com"},"message":"tcp: helpers to send special DCTCP ack\n\n[ Upstream commit 2987babb6982306509380fc11b450227a844493b ]\n\nRefactor and create helpers to send the special ACK in DCTCP.\n\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nAcked-by: Neal Cardwell <ncardwell@google.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/17fea38e74ab24afb06970bbd9dc52db11a8034b"},{"sha":"0b1d40e9e7738e3396ce414b1c62b911c285dfa3","author":{"name":"Yuchung Cheng","email":"5b5a0a360fa35167ac197fe6359c229fde284cf2@google.com"},"message":"tcp: do not cancel delay-AcK on DCTCP special ACK\n\n[ Upstream commit 27cde44a259c380a3c09066fc4b42de7dde9b1ad ]\n\nCurrently when a DCTCP receiver delays an ACK and receive a\ndata packet with a different CE mark from the previous one's, it\nsends two immediate ACKs acking previous and latest sequences\nrespectly (for ECN accounting).\n\nPreviously sending the first ACK may mark off the delayed ACK timer\n(tcp_event_ack_sent). This may subsequently prevent sending the\nsecond ACK to acknowledge the latest sequence (tcp_ack_snd_check).\nThe culprit is that tcp_send_ack() assumes it always acknowleges\nthe latest sequence, which is not true for the first special ACK.\n\nThe fix is to not make the assumption in tcp_send_ack and check the\nactual ack sequence before cancelling the delayed ACK. Further it's\nsafer to pass the ack sequence number as a local variable into\ntcp_send_ack routine, instead of intercepting tp->rcv_nxt to avoid\nfuture bugs like this.\n\nReported-by: Neal Cardwell <ncardwell@google.com>\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nAcked-by: Neal Cardwell <ncardwell@google.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/0b1d40e9e7738e3396ce414b1c62b911c285dfa3"},{"sha":"255924ea891f647451af3acbc40a3730dcb3255e","author":{"name":"Yuchung Cheng","email":"5b5a0a360fa35167ac197fe6359c229fde284cf2@google.com"},"message":"tcp: do not delay ACK in DCTCP upon CE status change\n\n[ Upstream commit a0496ef2c23b3b180902dd185d0d63ccbc624cf8 ]\n\nPer DCTCP RFC8257 (Section 3.2) the ACK reflecting the CE status change\nhas to be sent immediately so the sender can respond quickly:\n\n\"\"\" When receiving packets, the CE codepoint MUST be processed as follows:\n\n   1.  If the CE codepoint is set and DCTCP.CE is false, set DCTCP.CE to\n       true and send an immediate ACK.\n\n   2.  If the CE codepoint is not set and DCTCP.CE is true, set DCTCP.CE\n       to false and send an immediate ACK.\n\"\"\"\n\nPreviously DCTCP implementation may continue to delay the ACK. This\npatch fixes that to implement the RFC by forcing an immediate ACK.\n\nTested with this packetdrill script provided by Larry Brakmo\n\n0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3\n0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0\n0.000 setsockopt(3, SOL_TCP, TCP_CONGESTION, \"dctcp\", 5) = 0\n0.000 bind(3, ..., ...) = 0\n0.000 listen(3, 1) = 0\n\n0.100 < [ect0] SEW 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>\n0.100 > SE. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8>\n0.110 < [ect0] . 1:1(0) ack 1 win 257\n0.200 accept(3, ..., ...) = 4\n   +0 setsockopt(4, SOL_SOCKET, SO_DEBUG, [1], 4) = 0\n\n0.200 < [ect0] . 1:1001(1000) ack 1 win 257\n0.200 > [ect01] . 1:1(0) ack 1001\n\n0.200 write(4, ..., 1) = 1\n0.200 > [ect01] P. 1:2(1) ack 1001\n\n0.200 < [ect0] . 1001:2001(1000) ack 2 win 257\n+0.005 < [ce] . 2001:3001(1000) ack 2 win 257\n\n+0.000 > [ect01] . 2:2(0) ack 2001\n// Previously the ACK below would be delayed by 40ms\n+0.000 > [ect01] E. 2:2(0) ack 3001\n\n+0.500 < F. 9501:9501(0) ack 4 win 257\n\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nAcked-by: Neal Cardwell <ncardwell@google.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/255924ea891f647451af3acbc40a3730dcb3255e"},{"sha":"5fbec4801264cb3279ef6ac9c70bcbe2aaef89d5","author":{"name":"Eric Dumazet","email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com"},"message":"tcp: avoid collapses in tcp_prune_queue() if possible\n\n[ Upstream commit f4a3313d8e2ca9fd8d8f45e40a2903ba782607e7 ]\n\nRight after a TCP flow is created, receiving tiny out of order\npackets allways hit the condition :\n\nif (atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf)\n\ttcp_clamp_window(sk);\n\ntcp_clamp_window() increases sk_rcvbuf to match sk_rmem_alloc\n(guarded by tcp_rmem[2])\n\nCalling tcp_collapse_ofo_queue() in this case is not useful,\nand offers a O(N^2) surface attack to malicious peers.\n\nBetter not attempt anything before full queue capacity is reached,\nforcing attacker to spend lots of resource and allow us to more\neasily detect the abuse.\n\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nAcked-by: Soheil Hassas Yeganeh <soheil@google.com>\nAcked-by: Yuchung Cheng <ycheng@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/5fbec4801264cb3279ef6ac9c70bcbe2aaef89d5"},{"sha":"dc6ae4dffd656811dee7151b19545e4cd839d378","author":{"name":"Eric Dumazet","email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com"},"message":"tcp: detect malicious patterns in tcp_collapse_ofo_queue()\n\n[ Upstream commit 3d4bf93ac12003f9b8e1e2de37fe27983deebdcf ]\n\nIn case an attacker feeds tiny packets completely out of order,\ntcp_collapse_ofo_queue() might scan the whole rb-tree, performing\nexpensive copies, but not changing socket memory usage at all.\n\n1) Do not attempt to collapse tiny skbs.\n2) Add logic to exit early when too many tiny skbs are detected.\n\nWe prefer not doing aggressive collapsing (which copies packets)\nfor pathological flows, and revert to tcp_prune_ofo_queue() which\nwill be less expensive.\n\nIn the future, we might add the possibility of terminating flows\nthat are proven to be malicious.\n\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nAcked-by: Soheil Hassas Yeganeh <soheil@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/dc6ae4dffd656811dee7151b19545e4cd839d378"},{"sha":"a77bf88daa402cb52729fe4e46e1b7ce58f1f8ad","author":{"name":"Willem de Bruijn","email":"1ee125182537a91f90180f97fc3b3cb011bdf78a@google.com"},"message":"ip: in cmsg IP(V6)_ORIGDSTADDR call pskb_may_pull\n\n[ Upstream commit 2efd4fca703a6707cad16ab486eaab8fc7f0fd49 ]\n\nSyzbot reported a read beyond the end of the skb head when returning\nIPV6_ORIGDSTADDR:\n\n  BUG: KMSAN: kernel-infoleak in put_cmsg+0x5ef/0x860 net/core/scm.c:242\n  CPU: 0 PID: 4501 Comm: syz-executor128 Not tainted 4.17.0+ #9\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS\n  Google 01/01/2011\n  Call Trace:\n    __dump_stack lib/dump_stack.c:77 [inline]\n    dump_stack+0x185/0x1d0 lib/dump_stack.c:113\n    kmsan_report+0x188/0x2a0 mm/kmsan/kmsan.c:1125\n    kmsan_internal_check_memory+0x138/0x1f0 mm/kmsan/kmsan.c:1219\n    kmsan_copy_to_user+0x7a/0x160 mm/kmsan/kmsan.c:1261\n    copy_to_user include/linux/uaccess.h:184 [inline]\n    put_cmsg+0x5ef/0x860 net/core/scm.c:242\n    ip6_datagram_recv_specific_ctl+0x1cf3/0x1eb0 net/ipv6/datagram.c:719\n    ip6_datagram_recv_ctl+0x41c/0x450 net/ipv6/datagram.c:733\n    rawv6_recvmsg+0x10fb/0x1460 net/ipv6/raw.c:521\n    [..]\n\nThis logic and its ipv4 counterpart read the destination port from\nthe packet at skb_transport_offset(skb) + 4.\n\nWith MSG_MORE and a local SOCK_RAW sender, syzbot was able to cook a\npacket that stores headers exactly up to skb_transport_offset(skb) in\nthe head and the remainder in a frag.\n\nCall pskb_may_pull before accessing the pointer to ensure that it lies\nin skb head.\n\nLink: http://lkml.kernel.org/r/CAF=yD-LEJwZj5a1-bAAj2Oy_hKmGygV6rsJ_WOrAYnv-fnayiQ@mail.gmail.com\nReported-by: syzbot+9adb4b567003cac781f0@syzkaller.appspotmail.com\nSigned-off-by: Willem de Bruijn <willemb@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/a77bf88daa402cb52729fe4e46e1b7ce58f1f8ad"},{"sha":"92197cdb913a3f130b70550c856afc27cf710ea9","author":{"name":"Lubomir Rintel","email":"c9b9bbc6e9b0bc7e9cec5af1551c7b98adb9530c@v3.sk"},"message":"usb: cdc_acm: Add quirk for Castles VEGA3000\n\ncommit 1445cbe476fc3dd09c0b380b206526a49403c071 upstream.\n\nThe device (a POS terminal) implements CDC ACM, but has not union\ndescriptor.\n\nSigned-off-by: Lubomir Rintel <lkundrak@v3.sk>\nAcked-by: Oliver Neukum <oneukum@suse.com>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/92197cdb913a3f130b70550c856afc27cf710ea9"},{"sha":"ff180bcc594676b355476237a382ea10c6492c34","author":{"name":"Bin Liu","email":"80e886ddfd1f0046841c2d07e66ecf430023b0ba@ti.com"},"message":"usb: core: handle hub C_PORT_OVER_CURRENT condition\n\ncommit 249a32b7eeb3edb6897dd38f89651a62163ac4ed upstream.\n\nBased on USB2.0 Spec Section 11.12.5,\n\n  \"If a hub has per-port power switching and per-port current limiting,\n  an over-current on one port may still cause the power on another port\n  to fall below specific minimums. In this case, the affected port is\n  placed in the Power-Off state and C_PORT_OVER_CURRENT is set for the\n  port, but PORT_OVER_CURRENT is not set.\"\n\nso let's check C_PORT_OVER_CURRENT too for over current condition.\n\nFixes: 08d1dec6f405 (\"usb:hub set hub->change_bits when over-current happens\")\nCc: <stable@vger.kernel.org>\nTested-by: Alessandro Antenucci <antenucci@korg.it>\nSigned-off-by: Bin Liu <b-liu@ti.com>\nAcked-by: Alan Stern <stern@rowland.harvard.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/ff180bcc594676b355476237a382ea10c6492c34"},{"sha":"c420866afc161203d17f1fcd965a27a61ef70dd4","author":{"name":"Jerry Zhang","email":"197e2d05aab4646f19868e9232aea398cb9a923b@google.com"},"message":"usb: gadget: f_fs: Only return delayed status when len is 0\n\ncommit 4d644abf25698362bd33d17c9ddc8f7122c30f17 upstream.\n\nCommit 1b9ba000 (\"Allow function drivers to pause control\ntransfers\") states that USB_GADGET_DELAYED_STATUS is only\nsupported if data phase is 0 bytes.\n\nIt seems that when the length is not 0 bytes, there is no\nneed to explicitly delay the data stage since the transfer\nis not completed until the user responds. However, when the\nlength is 0, there is no data stage and the transfer is\nfinished once setup() returns, hence there is a need to\nexplicitly delay completion.\n\nThis manifests as the following bugs:\n\nPrior to 946ef68ad4e4 ('Let setup() return\nUSB_GADGET_DELAYED_STATUS'), when setup is 0 bytes, ffs\nwould require user to queue a 0 byte request in order to\nclear setup state. However, that 0 byte request was actually\nnot needed and would hang and cause errors in other setup\nrequests.\n\nAfter the above commit, 0 byte setups work since the gadget\nnow accepts empty queues to ep0 to clear the delay, but all\nother setups hang.\n\nFixes: 946ef68ad4e4 (\"Let setup() return USB_GADGET_DELAYED_STATUS\")\nSigned-off-by: Jerry Zhang <zhangjerry@google.com>\nCc: stable <stable@vger.kernel.org>\nAcked-by: Felipe Balbi <felipe.balbi@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/c420866afc161203d17f1fcd965a27a61ef70dd4"},{"sha":"0b14de0538aaa6c9b8c5d90b29e0a8dd698ba918","author":{"name":"Rafael J. Wysocki","email":"27ffc44a8ec6a212fba98cfc3246c6ce8ab131e0@intel.com"},"message":"driver core: Partially revert \"driver core: correct device's shutdown order\"\n\ncommit 722e5f2b1eec7de61117b7c0a7914761e3da2eda upstream.\n\nCommit 52cdbdd49853 (driver core: correct device's shutdown order)\nintroduced a regression by breaking device shutdown on some systems.\n\nNamely, the devices_kset_move_last() call in really_probe() added by\nthat commit is a mistake as it may cause parents to follow children\nin the devices_kset list which then causes shutdown to fail.  For\nexample, if a device has children before really_probe() is called\nfor it (which is not uncommon), that call will cause it to be\nreordered after the children in the devices_kset list and the\nordering of that list will not reflect the correct device shutdown\norder any more.\n\nAlso it causes the devices_kset list to be constantly reordered\nuntil all drivers have been probed which is totally pointless\noverhead in the majority of cases and it only covered an issue\nwith system shutdown, while system-wide suspend/resume potentially\nhad the same issue on the affected platforms (which was not covered).\n\nMoreover, the shutdown issue originally addressed by the change in\nreally_probe() made by commit 52cdbdd49853 is not present in 4.18-rc\nany more, since dra7 started to use the sdhci-omap driver which\ndoesn't disable any regulators during shutdown, so the really_probe()\npart of commit 52cdbdd49853 can be safely reverted.  [The original\nissue was related to the omap_hsmmc driver used by dra7 previously.]\n\nFor the above reasons, revert the really_probe() modifications made\nby commit 52cdbdd49853.\n\nThe other code changes made by commit 52cdbdd49853 are useful and\nthey need not be reverted.\n\nFixes: 52cdbdd49853 (driver core: correct device's shutdown order)\nLink: https://lore.kernel.org/lkml/CAFgQCTt7VfqM=UyCnvNFxrSw8Z6cUtAi3HUwR4_xPAc03SgHjQ@mail.gmail.com/\nReported-by: Pingfan Liu <kernelfans@gmail.com>\nTested-by: Pingfan Liu <kernelfans@gmail.com>\nReviewed-by: Kishon Vijay Abraham I <kishon@ti.com>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/0b14de0538aaa6c9b8c5d90b29e0a8dd698ba918"},{"sha":"e4c557649fda285e512f28a771038180cdeff6cf","author":{"name":"Anssi Hannula","email":"a67f875f3f4d9a809275c1d14e68c85c921fe2e8@bitwise.fi"},"message":"can: xilinx_can: fix RX loop if RXNEMP is asserted without RXOK\n\ncommit 32852c561bffd613d4ed7ec464b1e03e1b7b6c5c upstream.\n\nIf the device gets into a state where RXNEMP (RX FIFO not empty)\ninterrupt is asserted without RXOK (new frame received successfully)\ninterrupt being asserted, xcan_rx_poll() will continue to try to clear\nRXNEMP without actually reading frames from RX FIFO. If the RX FIFO is\nnot empty, the interrupt will not be cleared and napi_schedule() will\njust be called again.\n\nThis situation can occur when:\n\n(a) xcan_rx() returns without reading RX FIFO due to an error condition.\nThe code tries to clear both RXOK and RXNEMP but RXNEMP will not clear\ndue to a frame still being in the FIFO. The frame will never be read\nfrom the FIFO as RXOK is no longer set.\n\n(b) A frame is received between xcan_rx_poll() reading interrupt status\nand clearing RXOK. RXOK will be cleared, but RXNEMP will again remain\nset as the new message is still in the FIFO.\n\nI'm able to trigger case (b) by flooding the bus with frames under load.\n\nThere does not seem to be any benefit in using both RXNEMP and RXOK in\nthe way the driver does, and the polling example in the reference manual\n(UG585 v1.10 18.3.7 Read Messages from RxFIFO) also says that either\nRXOK or RXNEMP can be used for detecting incoming messages.\n\nFix the issue and simplify the RX processing by only using RXNEMP\nwithout RXOK.\n\nTested with the integrated CAN on Zynq-7000 SoC.\n\nFixes: b1201e44f50b (\"can: xilinx CAN controller support\")\nSigned-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/e4c557649fda285e512f28a771038180cdeff6cf"},{"sha":"7e572a170fc30ce4e6bff79b2a54f445a88457ac","author":{"name":"Anssi Hannula","email":"a67f875f3f4d9a809275c1d14e68c85c921fe2e8@bitwise.fi"},"message":"can: xilinx_can: fix recovery from error states not being propagated\n\ncommit 877e0b75947e2c7acf5624331bb17ceb093c98ae upstream.\n\nThe xilinx_can driver contains no mechanism for propagating recovery\nfrom CAN_STATE_ERROR_WARNING and CAN_STATE_ERROR_PASSIVE.\n\nAdd such a mechanism by factoring the handling of\nXCAN_STATE_ERROR_PASSIVE and XCAN_STATE_ERROR_WARNING out of\nxcan_err_interrupt and checking for recovery after RX and TX if the\ninterface is in one of those states.\n\nTested with the integrated CAN on Zynq-7000 SoC.\n\nFixes: b1201e44f50b (\"can: xilinx CAN controller support\")\nSigned-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/7e572a170fc30ce4e6bff79b2a54f445a88457ac"},{"sha":"d7dec444472632fcba1d4b3be0aac8d279a37cc4","author":{"name":"Anssi Hannula","email":"a67f875f3f4d9a809275c1d14e68c85c921fe2e8@bitwise.fi"},"message":"can: xilinx_can: fix device dropping off bus on RX overrun\n\ncommit 2574fe54515ed3487405de329e4e9f13d7098c10 upstream.\n\nThe xilinx_can driver performs a software reset when an RX overrun is\ndetected. This causes the device to enter Configuration mode where no\nmessages are received or transmitted.\n\nThe documentation does not mention any need to perform a reset on an RX\noverrun, and testing by inducing an RX overflow also indicated that the\ndevice continues to work just fine without a reset.\n\nRemove the software reset.\n\nTested with the integrated CAN on Zynq-7000 SoC.\n\nFixes: b1201e44f50b (\"can: xilinx CAN controller support\")\nSigned-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/d7dec444472632fcba1d4b3be0aac8d279a37cc4"},{"sha":"e5df9264649e13f0b6c2da9ce089a8ac41ef5121","author":{"name":"Anssi Hannula","email":"a67f875f3f4d9a809275c1d14e68c85c921fe2e8@bitwise.fi"},"message":"can: xilinx_can: keep only 1-2 frames in TX FIFO to fix TX accounting\n\ncommit 620050d9c2be15c47017ba95efe59e0832e99a56 upstream.\n\nThe xilinx_can driver assumes that the TXOK interrupt only clears after\nit has been acknowledged as many times as there have been successfully\nsent frames.\n\nHowever, the documentation does not mention such behavior, instead\nsaying just that the interrupt is cleared when the clear bit is set.\n\nSimilarly, testing seems to also suggest that it is immediately cleared\nregardless of the amount of frames having been sent. Performing some\nheavy TX load and then going back to idle has the tx_head drifting\nfurther away from tx_tail over time, steadily reducing the amount of\nframes the driver keeps in the TX FIFO (but not to zero, as the TXOK\ninterrupt always frees up space for 1 frame from the driver's\nperspective, so frames continue to be sent) and delaying the local echo\nframes.\n\nThe TX FIFO tracking is also otherwise buggy as it does not account for\nTX FIFO being cleared after software resets, causing\n  BUG!, TX FIFO full when queue awake!\nmessages to be output.\n\nThere does not seem to be any way to accurately track the state of the\nTX FIFO for local echo support while using the full TX FIFO.\n\nThe Zynq version of the HW (but not the soft-AXI version) has watermark\nprogramming support and with it an additional TX-FIFO-empty interrupt\nbit.\n\nModify the driver to only put 1 frame into TX FIFO at a time on soft-AXI\nand 2 frames at a time on Zynq. On Zynq the TXFEMP interrupt bit is used\nto detect whether 1 or 2 frames have been sent at interrupt processing\ntime.\n\nTested with the integrated CAN on Zynq-7000 SoC. The 1-frame-FIFO mode\nwas also tested.\n\nAn alternative way to solve this would be to drop local echo support but\nkeep using the full TX FIFO.\n\nv2: Add FIFO space check before TX queue wake with locking to\nsynchronize with queue stop. This avoids waking the queue when xmit()\nhad just filled it.\n\nv3: Keep local echo support and reduce the amount of frames in FIFO\ninstead as suggested by Marc Kleine-Budde.\n\nFixes: b1201e44f50b (\"can: xilinx CAN controller support\")\nSigned-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/e5df9264649e13f0b6c2da9ce089a8ac41ef5121"},{"sha":"f7efacee6f8aaa311726eed09470e970b59fd4e1","author":{"name":"Anssi Hannula","email":"a67f875f3f4d9a809275c1d14e68c85c921fe2e8@bitwise.fi"},"message":"can: xilinx_can: fix incorrect clear of non-processed interrupts\n\ncommit 2f4f0f338cf453bfcdbcf089e177c16f35f023c8 upstream.\n\nxcan_interrupt() clears ERROR|RXOFLV|BSOFF|ARBLST interrupts if any of\nthem is asserted. This does not take into account that some of them\ncould have been asserted between interrupt status read and interrupt\nclear, therefore clearing them without handling them.\n\nFix the code to only clear those interrupts that it knows are asserted\nand therefore going to be processed in xcan_err_interrupt().\n\nFixes: b1201e44f50b (\"can: xilinx CAN controller support\")\nSigned-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>\nCc: Michal Simek <michal.simek@xilinx.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/f7efacee6f8aaa311726eed09470e970b59fd4e1"}]}
{"actor":{"display_login":"Jackeagle"}}