{"push_id":2311412541,"size":237,"distinct_size":0,"ref":"refs/heads/caf/linux-next/akpm","head":"c8cefc87ae4fc4adbd32befc6ab5d0c8f0b97f97","before":"e6f00959cebde9d13aeba831ce6a0b25a1ef95c1","commits":[{"sha":"fe9748b7b41cee11f8db57fb8b20bc540a33102a","author":{"name":"Karol Herbst","email":"0cdd2e34a1552634273d6d9f3e982be484582592@redhat.com"},"message":"drm/nouveau/pmu/fuc: don't use movw directly anymore\n\nFixes failure to compile with recent envyas as a result of the 'movw'\nalias being removed for v5.\n\nA bit of history:\n\nv3 only has a 16-bit sign-extended immediate mov op. In order to set\nthe high bits, there's a separate 'sethi' op. envyas validates that\nthe value passed to mov(imm) is between -0x8000 and 0x7fff. In order\nto simplify macros that load both the low and high word, a 'movw'\nalias was added which takes an unsigned 16-bit immediate. However the\nactual hardware op still sign extends.\n\nv5 has a full 32-bit immediate mov op. The v3 16-bit immediate mov op\nis gone (loads 0 into the dst reg). However due to a bug in envyas,\nthe movw alias still existed, and selected the no-longer-present v3\n16-bit immediate mov op. As a result usage of movw on v5 is the same\nas mov with a 0x0 argument.\n\nThe proper fix throughout is to only ever use the 'movw' alias in\ncombination with 'sethi'. Anything else should get the sign-extended\nvalidation to ensure that the intended value ends up in the\ndestination register.\n\nChanges in fuc3 binaries is the result of a different encoding being\nselected for a mov with an 8-bit value.\n\nv2: added commit message written by Ilia, thanks for that!\nv3: messed up rebasing, now it should apply\n\nSigned-off-by: Karol Herbst <kherbst@redhat.com>\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/fe9748b7b41cee11f8db57fb8b20bc540a33102a"},{"sha":"94ee54dc808aa5a13630b082d6f892d0cf7bf527","author":{"name":"Christoph Böhmwalder","email":"7db460c0f9d9685cafdd2700fe8206673871322a@boehmwalder.at"},"message":"drm/nouveau/drm/nouveau/mmu: fix odd_ptr_err.cocci warnings\n\nThe kbuild test bot complained about a new coccinelle warning nearby,\nwhich sparked a discussion about the assignment to 'memory' inside of\nthe conditional expression.  See Link below for the original post.\n\nFix the assignment to silence the coccinelle warning and also make the\ncode look a little nicer.\n\nLink: https://lists.freedesktop.org/archives/nouveau/2017-November/029242.html\nSigned-off-by: Christoph Böhmwalder <christoph@boehmwalder.at>\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>\nReviewed-by: Karol Herbst <kherbst@redhat.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/94ee54dc808aa5a13630b082d6f892d0cf7bf527"},{"sha":"ee0d58100296d9b1a2aa23b913c09e8f297449a4","author":{"name":"Arnd Bergmann","email":"72a0f6d3b182607e6d5c44b93e1abb7b23ee18f3@arndb.de"},"message":"drm/nouveau: nouveau: use correct string length\n\ngcc-8 reports\n\ndrivers/gpu/drm/nouveau/nvkm/engine/pm/base.c: In function 'nvkm_perfmon_mthd':\ninclude/linux/string.h:265:9: error: '__builtin_strncpy' specified bound 64 equals destination size [-Werror=stringop-truncation]\n\nWe need one less byte or call strlcpy() to make it a\nnul-terminated string.\n\nSigned-off-by: Arnd Bergmann <arnd@arndb.de>\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/ee0d58100296d9b1a2aa23b913c09e8f297449a4"},{"sha":"b7997a35f936e92de0f69231c3ba6aa7cc6c20f1","author":{"name":"Ben Skeggs","email":"63a676a8a1b300e6f5baea1ffe7bc1e56ba63d0e@redhat.com"},"message":"drm/nouveau/secboot/r370: move a bunch of r375 stuff to a new implementation\n\nIt's entirely possibly that the other r375 code is relevant to r370 too,\nbut I've not confirmed this, so I'll leave it where it is for now.\n\nNVIDIA's copyright headers maintained, as it's still all their code.\n\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>\nReviewed-by: Gourav Samaiya <gsamaiya@nvidia.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/b7997a35f936e92de0f69231c3ba6aa7cc6c20f1"},{"sha":"dcc80c89477891e173d999fa8a13edf10d37b639","author":{"name":"Ben Skeggs","email":"63a676a8a1b300e6f5baea1ffe7bc1e56ba63d0e@redhat.com"},"message":"drm/nouveau/secboot/r370: implement support for booting LS SEC2 ucode\n\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>\nReviewed-by: Gourav Samaiya <gsamaiya@nvidia.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/dcc80c89477891e173d999fa8a13edf10d37b639"},{"sha":"2c5ac5ba4f855b8cb3f20c52c1a1e0773e671164","author":{"name":"Ben Skeggs","email":"63a676a8a1b300e6f5baea1ffe7bc1e56ba63d0e@redhat.com"},"message":"drm/nouveau/secboot/gp108: implement on top of acr_r370\n\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>\nReviewed-by: Gourav Samaiya <gsamaiya@nvidia.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/2c5ac5ba4f855b8cb3f20c52c1a1e0773e671164"},{"sha":"27cda223327505a19d912536dff205ccdc5c5c2a","author":{"name":"Ben Skeggs","email":"63a676a8a1b300e6f5baea1ffe7bc1e56ba63d0e@redhat.com"},"message":"drm/nouveau/fbcon: add module parameter to select bits-per-pixel\n\nUseful for debugging.\n\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/27cda223327505a19d912536dff205ccdc5c5c2a"},{"sha":"561464ea543c2f39f07ac2da91043555fa133601","author":{"name":"Ben Skeggs","email":"63a676a8a1b300e6f5baea1ffe7bc1e56ba63d0e@redhat.com"},"message":"drm/nouveau/bo: add helper functions for handling pinned+mapped buffers\n\nThis is a common, awkward sequence.  Let's wrap it up!\n\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/561464ea543c2f39f07ac2da91043555fa133601"},{"sha":"11fc017dfb1efffa93d803f7182d026962ea2aae","author":{"name":"Ben Skeggs","email":"63a676a8a1b300e6f5baea1ffe7bc1e56ba63d0e@redhat.com"},"message":"drm/nouveau/kms/nv50: prepare for double-buffered LUTs\n\nWe need to double-buffer LUTs to handle their update atomically.\n\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/11fc017dfb1efffa93d803f7182d026962ea2aae"},{"sha":"e75182f68b7b3a073e33b89ee4c1688160755930","author":{"name":"Ilia Mirkin","email":"b2ef0ae728ba642680a7b0ef24aed39533e21358@alum.mit.edu"},"message":"drm/nouveau/kms/nv50: use \"low res\" lut for indexed mode\n\nThis is what was done prior to the big refactor in kernel 3.8, and what\nwas done by xf86-video-nv. Experimentally, it seems like there's some\nsort of issue with the high-res lut to be used there. Tested on G92.\n\nThis ends up mattering because fbcon/fbdev chooses the C8 fb format for\nlow-vram systems, which can occur with some IGP-based configurations\nwith little \"stolen\" vram.\n\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80675\nSigned-off-by: Ilia Mirkin <imirkin@alum.mit.edu>\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/e75182f68b7b3a073e33b89ee4c1688160755930"},{"sha":"90df522912ac1fa88836fa1b1b9fa102a48d1f33","author":{"name":"Ben Skeggs","email":"63a676a8a1b300e6f5baea1ffe7bc1e56ba63d0e@redhat.com"},"message":"drm/nouveau/kms/nv50: use INTERPOLATE_257_UNITY_RANGE LUT on newer chipsets\n\nFor some reason forgotten by history, we've been using a 1025-entry LUT\nmode, and sparsely filling it with the 256-entry LUT we're handed.\n\nUntil we land support for the full atomic colour management properties,\nthis commit switches to using the 257-entry mode to fix colour mapping\nwith depth 30 framebuffers.\n\nReported-by: Ilia Mirkin <imirkin@alum.mit.edu>\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/90df522912ac1fa88836fa1b1b9fa102a48d1f33"},{"sha":"f4778f08a038d48ab8528416a51bf7ad231f9cc1","author":{"name":"Ben Skeggs","email":"63a676a8a1b300e6f5baea1ffe7bc1e56ba63d0e@redhat.com"},"message":"drm/nouveau/kms/nv50: fix handling of gamma since atomic conversion\n\nWe've still been directly using the legacy crtc gamma_set() hook even\nafter conversion to atomic modesetting.\n\nFor userspace clients this was fine, however, fbcon will use the atomic\nproperty when it's running on an atomic driver, which means we miss its\ncolormap updates - which is particularly bad for 8bpp framebuffers!\n\nThis commit converts the driver to use the atomic property + the helper\nfunction implementing the legacy hook on top of atomic.\n\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80675\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/f4778f08a038d48ab8528416a51bf7ad231f9cc1"},{"sha":"b138eca661ccee2b43f8ef3cfd952a5c71c1dc90","author":{"name":"Lyude Paul","email":"ce64de17b181b27992b265f32a57bc9f122808fd@redhat.com"},"message":"drm/nouveau: Add support for basic clockgating on Kepler1\n\nThis adds support for enabling automatic clockgating on nvidia GPUs for\nKepler1. While this is not technically a clockgating level, it does\nenable clockgating using the clockgating values initially set by the\nvbios (which should be safe to use).\n\nThis introduces two therm helpers for controlling basic clockgating:\n\tnvkm_therm_clkgate_enable() - enables clockgating through\n\tCG_CTRL, done after initializing the GPU fully\n\tnvkm_therm_clkgate_fini() - prepares clockgating for suspend or\n\tdriver unload\n\nA lot of this code was originally going to be based off of fermi;\nhowever it turns out that while Fermi's the first line of GPUs that\nintroduced this kind of power saving, Fermi requires more fine tuned\ncontrol of the CG_CTRL registers from the driver while reclocking that\nwe don't entirely understand yet.\n\nFor the simple parts we will be sharing with Fermi for certain however,\nwe at least add those into a new subdev/therm/gf100.h header.\n\nSigned-off-by: Lyude Paul <lyude@redhat.com>\nReviewed-by: Martin Peres <martin.peres@free.fr>\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/b138eca661ccee2b43f8ef3cfd952a5c71c1dc90"},{"sha":"1bab09acc9b165c5cd87dc46bc983372e103ae5d","author":{"name":"Lyude Paul","email":"ce64de17b181b27992b265f32a57bc9f122808fd@redhat.com"},"message":"drm/nouveau: Add support for BLCG on Kepler1\n\nThis enables BLCG optimization for kepler1. When using clockgating,\nnvidia's firmware has a set of registers which are initially programmed\nby the vbios with various engine delays and other mysterious settings\nthat are safe enough to bring up the GPU. However, the values used by\nthe vbios are more power hungry then they need to be, so the nvidia driver\nwrites it's own more optimized set of BLCG settings before enabling\nCG_CTRL. This adds support for programming the optimized BLCG values\nduring engine/subdev init, which enables rather significant power\nsavings.\n\nThis introduces the nvkm_therm_clkgate_init() helper, which we use to\nprogram the optimized BLCG settings before enabling clockgating with\nnvkm_therm_clkgate_enable.\n\nAs well, this commit shares a lot more code with Fermi since BLCG is\nmostly the same there as far as we can tell. In the future, it's likely\nwe'll reformat the clkgate_packs for kepler1 so that they share a list\nof mmio packs with Fermi.\n\nSigned-off-by: Lyude Paul <lyude@redhat.com>\nReviewed-by: Martin Peres <martin.peres@free.fr>\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/1bab09acc9b165c5cd87dc46bc983372e103ae5d"},{"sha":"7d094d29584ff5a571be45dcdab5659d97f01020","author":{"name":"Lyude Paul","email":"ce64de17b181b27992b265f32a57bc9f122808fd@redhat.com"},"message":"drm/nouveau: Add support for BLCG on Kepler2\n\nSame as the previous patch, but for Kepler2 now\n\nSigned-off-by: Lyude Paul <lyude@redhat.com>\nReviewed-by: Martin Peres <martin.peres@free.fr>\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/7d094d29584ff5a571be45dcdab5659d97f01020"},{"sha":"a0f79082bd1740137371f989dbdcbc19a52d3557","author":{"name":"Lyude Paul","email":"ce64de17b181b27992b265f32a57bc9f122808fd@redhat.com"},"message":"drm/nouveau: Add support for SLCG for Kepler2\n\nThat's right, there's still more power saving to go! Starting with\nkepler 2, nvidia hardware has an additional level of clockgating known\nas second level clockgating.  The details of this are not exact, but it\nseems to work by waiting for a collection of dependent hardware blocks\nto be gated before taking affect. As with the previous series, this\nresults in another noticeable drop in power consumption and is\nprogrammed in the same manner.\n\nSigned-off-by: Lyude Paul <lyude@redhat.com>\nReviewed-by: Martin Peres <martin.peres@free.fr>\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/a0f79082bd1740137371f989dbdcbc19a52d3557"},{"sha":"3ea74559d851b0e3f611da45d0dd9d505c4f44d5","author":{"name":"Lyude Paul","email":"ce64de17b181b27992b265f32a57bc9f122808fd@redhat.com"},"message":"drm/nouveau: Introduce NvPmEnableGating option\n\nThis adds the NvPmEnableGating config option to nouveau, which can be\nused to enable or disable clockgating for supported chipsets. Enabling\ncan be done by passing\n\n\tconfig=NvPmEnableGating=1\n\nTo nouveau. If your chipset supports it, you'll see a message in your\nkernel log indicating that clockgating is enabled. Since clockgating has\nonly had limited testing thus far, we leave this option disabled by\ndefault for now.\n\nSigned-off-by: Lyude Paul <lyude@redhat.com>\nReviewed-by: Martin Peres <martin.peres@free.fr>\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/3ea74559d851b0e3f611da45d0dd9d505c4f44d5"},{"sha":"e64fe9db2d1a31f6475ab1d5758860e7aa0cbb88","author":{"name":"Luis de Bethencourt","email":"9efc00209c16d128d4805749ca5906d62f798307@kernel.org"},"message":"drm/nouveau/mmu: Fix trailing semicolon\n\nThe trailing semicolon is an empty statement that does no operation.\nRemoving it since it doesn't do anything.\n\nSigned-off-by: Luis de Bethencourt <luisbg@kernel.org>\nReviewed-by: Karol Herbst <kherbst@redhat.com>\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/e64fe9db2d1a31f6475ab1d5758860e7aa0cbb88"},{"sha":"b515483e12b81da8cb62f1ff2461d6c29cf5115f","author":{"name":"Arnd Bergmann","email":"72a0f6d3b182607e6d5c44b93e1abb7b23ee18f3@arndb.de"},"message":"drm/nouveau/clk: fix gcc-7 -Wint-in-bool-context warning\n\ngcc thinks that interpreting a multiplication result as a bool\nis confusing:\n\ndrivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c: In function 'read_pll':\ndrivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:133:8: error: '*' in boolean context, suggest '&&' instead [-Werror=int-in-bool-context]\n\nAdding a temporary variable to contain the divisor helps make\nit clear what is going on and avoids that warning.\n\nSigned-off-by: Arnd Bergmann <arnd@arndb.de>\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/b515483e12b81da8cb62f1ff2461d6c29cf5115f"},{"sha":"531d5f7f5d137694a69e101c7cfb44103564c500","author":{"name":"Kees Cook","email":"999bfbbf6e15a9d6aba3dfebadcec55340f87c3f@chromium.org"},"message":"socket: Provide put_cmsg_whitelist() for constant size copies\n\nMost callers of put_cmsg() use a \"sizeof(foo)\" for the length argument.\nBut within put_cmsg(), the copy_to_user() call is made with a dynamic\nlength, as a result of the cmsg header calculations. This means that\nhardened usercopy will examine the copy, even though it was technically\na fixed size and should be implicitly whitelisted.\n\nMost callers of put_cmsg() are copying out of stack or kmalloc, so these\ncases aren't a problem for hardened usercopy. However, some try to copy\nout of the skbuff_head_cache slab, including the \"cb\" region. Since\nwhitelisting the slab area would leave other protocol definition of the\n\"cb\" region exposed to usercopy bugs, this creates put_cmsg_whitelist(),\nwhich internally uses sizeof() to provide a constant-sized length and\na stack bounce buffer, in order to explicitly whitelist an otherwise\ndisallowed slab region.\n\nOriginal report was:\n\nBad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLAB object 'skbuff_head_cache' (offset 64, size 16)!\nWARNING: CPU: 0 PID: 3663 at mm/usercopy.c:81 usercopy_warn+0xdb/0x100 mm/usercopy.c:76\n...\n __check_heap_object+0x89/0xc0 mm/slab.c:4426\n check_heap_object mm/usercopy.c:236 [inline]\n __check_object_size+0x272/0x530 mm/usercopy.c:259\n check_object_size include/linux/thread_info.h:112 [inline]\n check_copy_size include/linux/thread_info.h:143 [inline]\n copy_to_user include/linux/uaccess.h:154 [inline]\n put_cmsg+0x233/0x3f0 net/core/scm.c:242\n sock_recv_errqueue+0x200/0x3e0 net/core/sock.c:2913\n packet_recvmsg+0xb2e/0x17a0 net/packet/af_packet.c:3296\n sock_recvmsg_nosec net/socket.c:803 [inline]\n sock_recvmsg+0xc9/0x110 net/socket.c:810\n ___sys_recvmsg+0x2a4/0x640 net/socket.c:2179\n __sys_recvmmsg+0x2a9/0xaf0 net/socket.c:2287\n SYSC_recvmmsg net/socket.c:2368 [inline]\n SyS_recvmmsg+0xc4/0x160 net/socket.c:2352\n entry_SYSCALL_64_fastpath+0x29/0xa0\n\nReported-by: syzbot+e2d6cfb305e9f3911dea@syzkaller.appspotmail.com\nFixes: 6d07d1cd300f (\"usercopy: Restrict non-usercopy caches to size 0\")\nSigned-off-by: Kees Cook <keescook@chromium.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/531d5f7f5d137694a69e101c7cfb44103564c500"}]}
{"actor":{"display_login":"akhilnarang"}}