{"push_id":1268347109,"size":93,"distinct_size":93,"ref":"refs/heads/cm-13.0","head":"d62b750406aa722b92281bad9f0564603530fe88","before":"2c972a589c7b69b8632d8d1f9bc9f1d78746851c","commits":[{"sha":"bdfd64fcdedd210303926faed7532acde6eae2ae","author":{"name":"David Härdeman","email":"d8099b0f90e53c29d29eb12a7a3caa5af4f12681@hardeman.nu"},"message":"rc-core: fix remove uevent generation\n\ncommit a66b0c41ad277ae62a3ae6ac430a71882f899557 upstream.\n\nThe input_dev is already gone when the rc device is being unregistered\nso checking for its presence only means that no remove uevent will be\ngenerated.\n\nSigned-off-by: David Härdeman <david@hardeman.nu>\nSigned-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/bdfd64fcdedd210303926faed7532acde6eae2ae"},{"sha":"7bbff64bd333e806dfffc5560419226dd6db1f89","author":{"name":"Bjorn Helgaas","email":"d58560f8a8eaa2bf0a57092b2469a9a49461ac56@google.com"},"message":"PCI: Fix TI816X class code quirk\n\ncommit d1541dc977d376406f4584d8eb055488655c98ec upstream.\n\nIn fixup_ti816x_class(), we assigned \"class = PCI_CLASS_MULTIMEDIA_VIDEO\".\nBut PCI_CLASS_MULTIMEDIA_VIDEO is only the two-byte base class/sub-class\nand needs to be shifted to make space for the low-order interface byte.\n\nShift PCI_CLASS_MULTIMEDIA_VIDEO to set the correct class code.\n\nFixes: 63c4408074cb (\"PCI: Add quirk for setting valid class for TI816X Endpoint\")\nSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>\nCC: Hemant Pedanekar <hemantp@ti.com>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/7bbff64bd333e806dfffc5560419226dd6db1f89"},{"sha":"e4c5622320f110c9e88d83206c6851a408beecaa","author":{"name":"Bob Copeland","email":"b4a5ea001e047040e8c9075b67a268293138da2c@bobcopeland.com"},"message":"mac80211: enable assoc check for mesh interfaces\n\ncommit 3633ebebab2bbe88124388b7620442315c968e8f upstream.\n\nWe already set a station to be associated when peering completes, both\nin user space and in the kernel.  Thus we should always have an\nassociated sta before sending data frames to that station.\n\nFailure to check assoc state can cause crashes in the lower-level driver\ndue to transmitting unicast data frames before driver sta structures\n(e.g. ampdu state in ath9k) are initialized.  This occurred when\nforwarding in the presence of fixed mesh paths: frames were transmitted\nto stations with whom we hadn't yet completed peering.\n\nReported-by: Alexis Green <agreen@cococorp.com>\nTested-by: Jesse Jones <jjones@cococorp.com>\nSigned-off-by: Bob Copeland <me@bobcopeland.com>\nSigned-off-by: Johannes Berg <johannes.berg@intel.com>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/e4c5622320f110c9e88d83206c6851a408beecaa"},{"sha":"2db4b2b1bba7e2032f13e35a07bf958c13bea099","author":{"name":"Mark Rustad","email":"a6f85b2a4dfc3e6d3bc1b3ece83b334db41c6a43@intel.com"},"message":"PCI: Add dev_flags bit to access VPD through function 0\n\ncommit 932c435caba8a2ce473a91753bad0173269ef334 upstream.\n\nAdd a dev_flags bit, PCI_DEV_FLAGS_VPD_REF_F0, to access VPD through\nfunction 0 to provide VPD access on other functions.  This is for hardware\ndevices that provide copies of the same VPD capability registers in\nmultiple functions.  Because the kernel expects that each function has its\nown registers, both the locking and the state tracking are affected by VPD\naccesses to different functions.\n\nOn such devices for example, if a VPD write is performed on function 0,\n*any* later attempt to read VPD from any other function of that device will\nhang.  This has to do with how the kernel tracks the expected value of the\nF bit per function.\n\nConcurrent accesses to different functions of the same device can not only\nhang but also corrupt both read and write VPD data.\n\nWhen hangs occur, typically the error message:\n\n  vpd r/w failed.  This is likely a firmware bug on this device.\n\nwill be seen.\n\nNever set this bit on function 0 or there will be an infinite recursion.\n\nSigned-off-by: Mark Rustad <mark.d.rustad@intel.com>\nSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>\nAcked-by: Alexander Duyck <alexander.h.duyck@redhat.com>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/2db4b2b1bba7e2032f13e35a07bf958c13bea099"},{"sha":"c9db5acacc069cbd8b229a3dac241ec474daf40c","author":{"name":"Mark Rustad","email":"a6f85b2a4dfc3e6d3bc1b3ece83b334db41c6a43@intel.com"},"message":"PCI: Add VPD function 0 quirk for Intel Ethernet devices\n\ncommit 7aa6ca4d39edf01f997b9e02cf6d2fdeb224f351 upstream.\n\nSet the PCI_DEV_FLAGS_VPD_REF_F0 flag on all Intel Ethernet device\nfunctions other than function 0, so that on multi-function devices, we will\nalways read VPD from function 0 instead of from the other functions.\n\n[bhelgaas: changelog]\nSigned-off-by: Mark Rustad <mark.d.rustad@intel.com>\nSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>\nAcked-by: Alexander Duyck <alexander.h.duyck@redhat.com>\n[bwh: Backported to 3.2:\n - Put the class check in the new function as there is no\n   DECLARE_PCI_FIXUP_CLASS_EARLY(\n - Adjust context]\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/c9db5acacc069cbd8b229a3dac241ec474daf40c"},{"sha":"5a87319b7552e97970397845cc62b2cb9e07da55","author":{"name":"Thomas Huth","email":"88e8c2c9848c27f046284b2ccf48cd5b58fafc02@redhat.com"},"message":"powerpc/rtas: Introduce rtas_get_sensor_fast() for IRQ handlers\n\ncommit 1c2cb594441d02815d304cccec9742ff5c707495 upstream.\n\nThe EPOW interrupt handler uses rtas_get_sensor(), which in turn\nuses rtas_busy_delay() to wait for RTAS becoming ready in case it\nis necessary. But rtas_busy_delay() is annotated with might_sleep()\nand thus may not be used by interrupts handlers like the EPOW handler!\nThis leads to the following BUG when CONFIG_DEBUG_ATOMIC_SLEEP is\nenabled:\n\n BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:496\n in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/1\n CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.2.0-rc2-thuth #6\n Call Trace:\n [c00000007ffe7b90] [c000000000807670] dump_stack+0xa0/0xdc (unreliable)\n [c00000007ffe7bc0] [c0000000000e1f14] ___might_sleep+0x134/0x180\n [c00000007ffe7c20] [c00000000002aec0] rtas_busy_delay+0x30/0xd0\n [c00000007ffe7c50] [c00000000002bde4] rtas_get_sensor+0x74/0xe0\n [c00000007ffe7ce0] [c000000000083264] ras_epow_interrupt+0x44/0x450\n [c00000007ffe7d90] [c000000000120260] handle_irq_event_percpu+0xa0/0x300\n [c00000007ffe7e70] [c000000000120524] handle_irq_event+0x64/0xc0\n [c00000007ffe7eb0] [c000000000124dbc] handle_fasteoi_irq+0xec/0x260\n [c00000007ffe7ef0] [c00000000011f4f0] generic_handle_irq+0x50/0x80\n [c00000007ffe7f20] [c000000000010f3c] __do_irq+0x8c/0x200\n [c00000007ffe7f90] [c0000000000236cc] call_do_irq+0x14/0x24\n [c00000007e6f39e0] [c000000000011144] do_IRQ+0x94/0x110\n [c00000007e6f3a30] [c000000000002594] hardware_interrupt_common+0x114/0x180\n\nFix this issue by introducing a new rtas_get_sensor_fast() function\nthat does not use rtas_busy_delay() - and thus can only be used for\nsensors that do not cause a BUSY condition - known as \"fast\" sensors.\n\nThe EPOW sensor is defined to be \"fast\" in sPAPR - mpe.\n\nFixes: 587f83e8dd50 (\"powerpc/pseries: Use rtas_get_sensor in RAS code\")\nSigned-off-by: Thomas Huth <thuth@redhat.com>\nReviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/5a87319b7552e97970397845cc62b2cb9e07da55"},{"sha":"f7aba371041e405e73f29023c6c65698b2e62b6c","author":{"name":"Chuck Lever","email":"038685acf1ee4025ac374ddb5227621ea96609b9@oracle.com"},"message":"svcrdma: Fix send_reply() scatter/gather set-up\n\ncommit 9d11b51ce7c150a69e761e30518f294fc73d55ff upstream.\n\nThe Linux NFS server returns garbage in the data payload of inline\nNFS/RDMA READ replies. These are READs of under 1000 bytes or so\nwhere the client has not provided either a reply chunk or a write\nlist.\n\nThe NFS server delivers the data payload for an NFS READ reply to\nthe transport in an xdr_buf page list. If the NFS client did not\nprovide a reply chunk or a write list, send_reply() is supposed to\nset up a separate sge for the page containing the READ data, and\nanother sge for XDR padding if needed, then post all of the sges via\na single SEND Work Request.\n\nThe problem is send_reply() does not advance through the xdr_buf\nwhen setting up scatter/gather entries for SEND WR. It always calls\ndma_map_xdr with xdr_off set to zero. When there's more than one\nsge, dma_map_xdr() sets up the SEND sge's so they all point to the\nxdr_buf's head.\n\nThe current Linux NFS/RDMA client always provides a reply chunk or\na write list when performing an NFS READ over RDMA. Therefore, it\ndoes not exercise this particular case. The Linux server has never\nhad to use more than one extra sge for building RPC/RDMA replies\nwith a Linux client.\n\nHowever, an NFS/RDMA client _is_ allowed to send small NFS READs\nwithout setting up a write list or reply chunk. The NFS READ reply\nfits entirely within the inline reply buffer in this case. This is\nperhaps a more efficient way of performing NFS READs that the Linux\nNFS/RDMA client may some day adopt.\n\nFixes: b432e6b3d9c1 ('svcrdma: Change DMA mapping logic to . . .')\nBugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=285\nSigned-off-by: Chuck Lever <chuck.lever@oracle.com>\nSigned-off-by: J. Bruce Fields <bfields@redhat.com>\n[lizf: Backported to 3.4: adjust context]\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/f7aba371041e405e73f29023c6c65698b2e62b6c"},{"sha":"ce87ef5e27af10fb322e75113cc9e6a9e21cd1da","author":{"name":"NeilBrown","email":"2d905a3497a379bccf401a15c6d441d61e66863c@suse.com"},"message":"md/raid0: update queue parameter in a safer location.\n\ncommit 199dc6ed5179251fa6158a461499c24bdd99c836 upstream.\n\nWhen a (e.g.) RAID5 array is reshaped to RAID0, the updating\nof queue parameters (e.g. max number of sectors per bio) is\ndone in the wrong place.\nIt should be part of ->run, but it is actually part of ->takeover.\nThis means it happens before level_store() calls:\n\n\tblk_set_stacking_limits(&mddev->queue->limits);\n\nand so it ineffective.  This can lead to errors from underlying\ndevices.\n\nSo move all the relevant settings out of create_stripe_zones()\nand into raid0_run().\n\nAs this can lead to a bug-on it is suitable for any -stable\nkernel which supports reshape to RAID0.  So 2.6.35 or later.\nAs the bug has been present for five years there is no urgency,\nso no need to rush into -stable.\n\nFixes: 9af204cf720c (\"md: Add support for Raid5->Raid0 and Raid10->Raid0 takeover\")\nReported-by: Yi Zhang <yizhan@redhat.com>\nSigned-off-by: NeilBrown <neilb@suse.com>\n[lizf: Backported to 3.4:\n - adjust context\n - remove changes to discard and write-same features]\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/ce87ef5e27af10fb322e75113cc9e6a9e21cd1da"},{"sha":"def58c439652c3994bd678f721f5522a971dc4b6","author":{"name":"Sudip Mukherjee","email":"c6168390db7a9fc0fa65a07cf1437477e6f774a9@gmail.com"},"message":"auxdisplay: ks0108: fix refcount\n\ncommit bab383de3b84e584b0f09227151020b2a43dc34c upstream.\n\nparport_find_base() will implicitly do parport_get_port() which\nincreases the refcount. Then parport_register_device() will again\nincrement the refcount. But while unloading the module we are only\ndoing parport_unregister_device() decrementing the refcount only once.\nWe add an parport_put_port() to neutralize the effect of\nparport_get_port().\n\nSigned-off-by: Sudip Mukherjee <sudip@vectorindia.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/def58c439652c3994bd678f721f5522a971dc4b6"},{"sha":"d30d641ed46e8203e6fd258b1917fb374907cffd","author":{"name":"Masahiro Yamada","email":"642490827508ea1a46cbcea45eb79617d0758c10@socionext.com"},"message":"devres: fix devres_get()\n\ncommit 64526370d11ce8868ca495723d595b61e8697fbf upstream.\n\nCurrently, devres_get() passes devres_free() the pointer to devres,\nbut devres_free() should be given with the pointer to resource data.\n\nFixes: 9ac7849e35f7 (\"devres: device resource management\")\nSigned-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>\nAcked-by: Tejun Heo <tj@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/d30d641ed46e8203e6fd258b1917fb374907cffd"},{"sha":"b095e65eb087e2853018171f98dcadc5ec12940d","author":{"name":"Paul Bolle","email":"9321cd92933daf9a2a45952d44f5811c9d660b31@tiscali.nl"},"message":"windfarm: decrement client count when unregistering\n\ncommit fe2b592173ff0274e70dc44d1d28c19bb995aa7c upstream.\n\nwf_unregister_client() increments the client count when a client\nunregisters. That is obviously incorrect. Decrement that client count\ninstead.\n\nFixes: 75722d3992f5 (\"[PATCH] ppc64: Thermal control for SMU based machines\")\n\nSigned-off-by: Paul Bolle <pebolle@tiscali.nl>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/b095e65eb087e2853018171f98dcadc5ec12940d"},{"sha":"ad315dc13407e9b4614dde63f8d9872bfea576e0","author":{"name":"NeilBrown","email":"2d905a3497a379bccf401a15c6d441d61e66863c@suse.com"},"message":"NFSv4: don't set SETATTR for O_RDONLY|O_EXCL\n\ncommit efcbc04e16dfa95fef76309f89710dd1d99a5453 upstream.\n\nIt is unusual to combine the open flags O_RDONLY and O_EXCL, but\nit appears that libre-office does just that.\n\n[pid  3250] stat(\"/home/USER/.config\", {st_mode=S_IFDIR|0700, st_size=8192, ...}) = 0\n[pid  3250] open(\"/home/USER/.config/libreoffice/4-suse/user/extensions/buildid\", O_RDONLY|O_EXCL <unfinished ...>\n\nNFSv4 takes O_EXCL as a sign that a setattr command should be sent,\nprobably to reset the timestamps.\n\nWhen it was an O_RDONLY open, the SETATTR command does not\nidentify any actual attributes to change.\nIf no delegation was provided to the open, the SETATTR uses the\nall-zeros stateid and the request is accepted (at least by the\nLinux NFS server - no harm, no foul).\n\nIf a read-delegation was provided, this is used in the SETATTR\nrequest, and a Netapp filer will justifiably claim\nNFS4ERR_BAD_STATEID, which the Linux client takes as a sign\nto retry - indefinitely.\n\nSo only treat O_EXCL specially if O_CREAT was also given.\n\nSigned-off-by: NeilBrown <neilb@suse.com>\nSigned-off-by: Trond Myklebust <trond.myklebust@primarydata.com>\n[lizf: Backported to 3.4: adjust context]\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/ad315dc13407e9b4614dde63f8d9872bfea576e0"},{"sha":"ef296846ea3e5fe32ec4b3c51221cd28d7178315","author":{"name":"Peter Chen","email":"1bd50f75c460ec6fb073f71822628b73bde58ca9@freescale.com"},"message":"usb: host: ehci-sys: delete useless bus_to_hcd conversion\n\ncommit 0521cfd06e1ebcd575e7ae36aab068b38df23850 upstream.\n\nThe ehci platform device's drvdata is the pointer of struct usb_hcd\nalready, so we doesn't need to call bus_to_hcd conversion again.\n\nSigned-off-by: Peter Chen <peter.chen@freescale.com>\nAcked-by: Alan Stern <stern@rowland.harvard.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/ef296846ea3e5fe32ec4b3c51221cd28d7178315"},{"sha":"7c7dd71ac314b970409a5ff56363c89dbd8614db","author":{"name":"Matthijs Kooijman","email":"c8af2bc7ba7cdc257b9fbfead0c199b3d9143404@stdin.nl"},"message":"USB: ftdi_sio: Added custom PID for CustomWare products\n\ncommit 1fb8dc36384ae1140ee6ccc470de74397606a9d5 upstream.\n\nCustomWare uses the FTDI VID with custom PIDs for their ShipModul MiniPlex\nproducts.\n\nSigned-off-by: Matthijs Kooijman <matthijs@stdin.nl>\nSigned-off-by: Johan Hovold <johan@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/7c7dd71ac314b970409a5ff56363c89dbd8614db"},{"sha":"92feca95b7f9122afcee8564fd910ad6530d59cd","author":{"name":"Tyler Hicks","email":"b853e817f42e1bd11d7bbff11aaeae82a476f658@canonical.com"},"message":"eCryptfs: Invalidate dcache entries when lower i_nlink is zero\n\ncommit 5556e7e6d30e8e9b5ee51b0e5edd526ee80e5e36 upstream.\n\nConsider eCryptfs dcache entries to be stale when the corresponding\nlower inode's i_nlink count is zero. This solves a problem caused by the\nlower inode being directly modified, without going through the eCryptfs\nmount, leaving stale eCryptfs dentries cached and the eCryptfs inode's\ni_nlink count not being cleared.\n\nSigned-off-by: Tyler Hicks <tyhicks@canonical.com>\nReported-by: Richard Weinberger <richard@nod.at>\n[bwh: Backported to 3.2:\n - Test d_revalidate pointer directly rather than a DCACHE_OP flag\n - Open-code d_inode()\n - Adjust context]\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/92feca95b7f9122afcee8564fd910ad6530d59cd"},{"sha":"93fd31b106a6371b784a7ab5f1231176c2573342","author":{"name":"Stephen Chandler Paul","email":"1f81f7ac2b1fc68743525d150f68a4801a32c99d@redhat.com"},"message":"DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd\n\ncommit 924f92bf12bfbef3662619e3ed24a1cea7c1cbcd upstream.\n\nMost of the time this isn't an issue since hotplugging an adaptor will\ntrigger a crtc mode change which in turn, causes the driver to probe\nevery DisplayPort for a dpcd. However, in cases where hotplugging\ndoesn't cause a mode change (specifically when one unplugs a monitor\nfrom a DisplayPort connector, then plugs that same monitor back in\nseconds later on the same port without any other monitors connected), we\nnever probe for the dpcd before starting the initial link training. What\nhappens from there looks like this:\n\n\t- GPU has only one monitor connected. It's connected via\n\t  DisplayPort, and does not go through an adaptor of any sort.\n\n\t- User unplugs DisplayPort connector from GPU.\n\n\t- Change in HPD is detected by the driver, we probe every\n\t  DisplayPort for a possible connection.\n\n\t- Probe the port the user originally had the monitor connected\n\t  on for it's dpcd. This fails, and we clear the first (and only\n\t  the first) byte of the dpcd to indicate we no longer have a\n\t  dpcd for this port.\n\n\t- User plugs the previously disconnected monitor back into the\n\t  same DisplayPort.\n\n\t- radeon_connector_hotplug() is called before everyone else,\n\t  and tries to handle the link training. Since only the first\n\t  byte of the dpcd is zeroed, the driver is able to complete\n\t  link training but does so against the wrong dpcd, causing it\n\t  to initialize the link with the wrong settings.\n\n\t- Display stays blank (usually), dpcd is probed after the\n\t  initial link training, and the driver prints no obvious\n\t  messages to the log.\n\nIn theory, since only one byte of the dpcd is chopped off (specifically,\nthe byte that contains the revision information for DisplayPort), it's\nnot entirely impossible that this bug may not show on certain monitors.\nFor instance, the only reason this bug was visible on my ASUS PB238\nmonitor was due to the fact that this monitor using the enhanced framing\nsymbol sequence, the flag for which is ignored if the radeon driver\nthinks that the DisplayPort version is below 1.1.\n\nSigned-off-by: Stephen Chandler Paul <cpaul@redhat.com>\nReviewed-by: Jerome Glisse <jglisse@redhat.com>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/93fd31b106a6371b784a7ab5f1231176c2573342"},{"sha":"caae2b6b3c8c7b1fd5d5e87220ee02ff774261f4","author":{"name":"David Daney","email":"9254d8d8e26c28d9d5214a480ee48e4515534fd3@cavium.com"},"message":"of/address: Don't loop forever in of_find_matching_node_by_address().\n\ncommit 3a496b00b6f90c41bd21a410871dfc97d4f3c7ab upstream.\n\nIf the internal call to of_address_to_resource() fails, we end up\nlooping forever in of_find_matching_node_by_address().  This can be\ncaused by a defective device tree, or calling with an incorrect\nmatches argument.\n\nFix by calling of_find_matching_node() unconditionally at the end of\nthe loop.\n\nSigned-off-by: David Daney <david.daney@cavium.com>\nSigned-off-by: Rob Herring <robh@kernel.org>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/caae2b6b3c8c7b1fd5d5e87220ee02ff774261f4"},{"sha":"42723298fbaeb1a8146e9c77fcd339ff513c7ab3","author":{"name":"Grant Likely","email":"15a470d40626c210e744e415735c8bda8fdbce03@linaro.org"},"message":"drivercore: Fix unregistration path of platform devices\n\ncommit 7f5dcaf1fdf289767a126a0a5cc3ef39b5254b06 upstream.\n\nThe unregister path of platform_device is broken. On registration, it\nwill register all resources with either a parent already set, or\ntype==IORESOURCE_{IO,MEM}. However, on unregister it will release\neverything with type==IORESOURCE_{IO,MEM}, but ignore the others. There\nare also cases where resources don't get registered in the first place,\nlike with devices created by of_platform_populate()*.\n\nFix the unregister path to be symmetrical with the register path by\nchecking the parent pointer instead of the type field to decide which\nresources to unregister. This is safe because the upshot of the\nregistration path algorithm is that registered resources have a parent\npointer, and non-registered resources do not.\n\n* It can be argued that of_platform_populate() should be registering\n  it's resources, and they argument has some merit. However, there are\n  quite a few platforms that end up broken if we try to do that due to\n  overlapping resources in the device tree. Until that is fixed, we need\n  to solve the immediate problem.\n\nCc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>\nCc: Wolfram Sang <wsa@the-dreams.de>\nCc: Rob Herring <robh@kernel.org>\nCc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nCc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>\nSigned-off-by: Grant Likely <grant.likely@linaro.org>\nTested-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>\nTested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>\nSigned-off-by: Rob Herring <robh@kernel.org>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/42723298fbaeb1a8146e9c77fcd339ff513c7ab3"},{"sha":"dac9176bf35de00878dbb36aedf7d40a8696014f","author":{"name":"Trond Myklebust","email":"74f7b75b0dfb06f182c703b16f16eeff3727673a@primarydata.com"},"message":"SUNRPC: xs_reset_transport must mark the connection as disconnected\n\ncommit 0c78789e3a030615c6650fde89546cadf40ec2cc upstream.\n\nIn case the reconnection attempt fails.\n\nSigned-off-by: Trond Myklebust <trond.myklebust@primarydata.com>\n[lizf: Backported to 3.4: add definition of variable xprt]\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/dac9176bf35de00878dbb36aedf7d40a8696014f"},{"sha":"d57f950032009a5e5d47ea9ea4c3e1a67a35154f","author":{"name":"Noa Osherovich","email":"5ecb6bfdb1cd2131d0645621186ccff52c180a8b@mellanox.com"},"message":"IB/mlx4: Use correct SL on AH query under RoCE\n\ncommit 5e99b139f1b68acd65e36515ca347b03856dfb5a upstream.\n\nThe mlx4 IB driver implementation for ib_query_ah used a wrong offset\n(28 instead of 29) when link type is Ethernet. Fixed to use the correct one.\n\nFixes: fa417f7b520e ('IB/mlx4: Add support for IBoE')\nSigned-off-by: Shani Michaeli <shanim@mellanox.com>\nSigned-off-by: Noa Osherovich <noaos@mellanox.com>\nSigned-off-by: Or Gerlitz <ogerlitz@mellanox.com>\nSigned-off-by: Doug Ledford <dledford@redhat.com>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/sigma-1/android_kernel_samsung_lt03wifi/commits/d57f950032009a5e5d47ea9ea4c3e1a67a35154f"}]}
{"actor":{"display_login":"sigma-1"}}