{"push_id":1411709809,"size":93,"distinct_size":1,"ref":"refs/heads/4.8/master","head":"4b32fc67f031534e240f26a9e43ddd468c4aca2b","before":"6db7cb960e00f72970b0522ed7499836262ca6da","commits":[{"sha":"c3ea1b15b71ec829759cfbce8338b72fe765fd94","author":{"name":"Takashi Iwai","email":"dd0a9a4ae370c51e6d7099900a4bf6656524e055@suse.de"},"message":"ALSA: info: Return error for invalid read/write\n\ncommit 6809cd682b82dfff47943850d1a8c714f971b5ca upstream.\n\nCurrently the ALSA proc handler allows read or write even if the proc\nfile were write-only or read-only.  It's mostly harmless, does thing\nbut allocating memory and ignores the input/output.  But it doesn't\ntell user about the invalid use, and it's confusing and inconsistent\nin comparison with other proc files.\n\nThis patch adds some sanity checks and let the proc handler returning\nan -EIO error when the invalid read/write is performed.\n\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/c3ea1b15b71ec829759cfbce8338b72fe765fd94"},{"sha":"9386a722d2500b3e9dc8751c434a6c3c5e4c3f5c","author":{"name":"Takashi Iwai","email":"dd0a9a4ae370c51e6d7099900a4bf6656524e055@suse.de"},"message":"ALSA: info: Limit the proc text input size\n\ncommit 027a9fe6835620422b6713892175716f3613dd9d upstream.\n\nThe ALSA proc handler allows currently the write in the unlimited size\nuntil kmalloc() fails.  But basically the write is supposed to be only\nfor small inputs, mostly for one line inputs, and we don't have to\nhandle too large sizes at all.  Since the kmalloc error results in the\nkernel warning, it's better to limit the size beforehand.\n\nThis patch adds the limit of 16kB, which must be large enough for the\ncurrently existing code.\n\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/9386a722d2500b3e9dc8751c434a6c3c5e4c3f5c"},{"sha":"9964230320d502be7dad8fddca911169504d96ac","author":{"name":"murray foster","email":"fb79390488397348e297627c72d3e93804a9aa07@gmail.com"},"message":"ASoC: cs4270: fix DAPM stream name mismatch\n\ncommit aa5f920993bda2095952177eea79bc8e58ae6065 upstream.\n\nMismatching stream names in DAPM route and widget definitions are\ncausing compilation errors. Fixing these names allows the cs4270\ndriver to compile and function.\n\n[Errors must be at probe time not compile time -- broonie]\n\nSigned-off-by: Murray Foster <mrafoster@gmail.com>\nAcked-by: Paul Handrigan <Paul.Handrigan@cirrus.com>\nSigned-off-by: Mark Brown <broonie@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/9964230320d502be7dad8fddca911169504d96ac"},{"sha":"2e594273d4c526a2a65c665619acd8ed46317fd0","author":{"name":"Sean Young","email":"745a5948f3a29be7b294faa8063f9998c214afbb@mess.org"},"message":"dib0700: fix nec repeat handling\n\ncommit ba13e98f2cebd55a3744c5ffaa08f9dca73bf521 upstream.\n\nWhen receiving a nec repeat, ensure the correct scancode is repeated\nrather than a random value from the stack.  This removes the need for\nthe bogus uninitialized_var() and also fixes the warnings:\n\n    drivers/media/usb/dvb-usb/dib0700_core.c: In function ‘dib0700_rc_urb_completion’:\n    drivers/media/usb/dvb-usb/dib0700_core.c:679: warning: ‘protocol’ may be used uninitialized in this function\n\n[sean addon: So after writing the patch and submitting it, I've bought the\n             hardware on ebay. Without this patch you get random scancodes\n             on nec repeats, which the patch indeed fixes.]\n\nSigned-off-by: Sean Young <sean@mess.org>\nTested-by: Sean Young <sean@mess.org>\nSigned-off-by: Arnd Bergmann <arnd@arndb.de>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/2e594273d4c526a2a65c665619acd8ed46317fd0"},{"sha":"5b5243b606ec0de2988d32207a537841d4ead721","author":{"name":"Vlastimil Babka","email":"920c003c51ff5a11a6ee976b813fb82ea89684e4@suse.cz"},"message":"mm, frontswap: make sure allocated frontswap map is assigned\n\ncommit 5e322beefc8699b5747cfb35539a9496034e4296 upstream.\n\nChristian Borntraeger reports:\n\nWith commit 8ea1d2a1985a (\"mm, frontswap: convert frontswap_enabled to\nstatic key\") kmemleak complains about a memory leak in swapon\n\n    unreferenced object 0x3e09ba56000 (size 32112640):\n      comm \"swapon\", pid 7852, jiffies 4294968787 (age 1490.770s)\n      hex dump (first 32 bytes):\n        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n      backtrace:\n         __vmalloc_node_range+0x194/0x2d8\n         vzalloc+0x58/0x68\n         SyS_swapon+0xd60/0x12f8\n         system_call+0xd6/0x270\n\nTurns out kmemleak is right.  We now allocate the frontswap map\ndepending on the kernel config (and no longer on the enablement)\n\n  swapfile.c:\n  [...]\n      if (IS_ENABLED(CONFIG_FRONTSWAP))\n                frontswap_map = vzalloc(BITS_TO_LONGS(maxpages) * sizeof(long));\n\nbut later on this is passed along\n  --> enable_swap_info(p, prio, swap_map, cluster_info, frontswap_map);\n\nand ignored if frontswap is disabled\n  --> frontswap_init(p->type, frontswap_map);\n\n  static inline void frontswap_init(unsigned type, unsigned long *map)\n  {\n        if (frontswap_enabled())\n                __frontswap_init(type, map);\n  }\n\nThing is, that frontswap map is never freed.\n\nThe leakage is relatively not that bad, because swapon is an infrequent\nand privileged operation.  However, if the first frontswap backend is\nregistered after a swap type has been already enabled, it will WARN_ON\nin frontswap_register_ops() and frontswap will not be available for the\nswap type.\n\nFix this by making sure the map is assigned by frontswap_init() as long\nas CONFIG_FRONTSWAP is enabled.\n\nFixes: 8ea1d2a1985a (\"mm, frontswap: convert frontswap_enabled to static key\")\nLink: http://lkml.kernel.org/r/20161026134220.2566-1-vbabka@suse.cz\nSigned-off-by: Vlastimil Babka <vbabka@suse.cz>\nReported-by: Christian Borntraeger <borntraeger@de.ibm.com>\nCc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>\nCc: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nCc: David Vrabel <david.vrabel@citrix.com>\nCc: Juergen Gross <jgross@suse.com>\nCc: \"Kirill A. Shutemov\" <kirill.shutemov@linux.intel.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/5b5243b606ec0de2988d32207a537841d4ead721"},{"sha":"c87739e5d029a61ef1bbaccd90d07194459f9640","author":{"name":"Hugh Dickins","email":"11bd16bbccd141ee47d9426ad06afbc74b915cf0@google.com"},"message":"shmem: fix pageflags after swapping DMA32 object\n\ncommit 9956edf37e65e93fbb76dcff1236dff2323d306a upstream.\n\nIf shmem_alloc_page() does not set PageLocked and PageSwapBacked, then\nshmem_replace_page() needs to do so for itself.  Without this, it puts\nnewpage on the wrong lru, re-unlocks the unlocked newpage, and system\ndescends into \"Bad page\" reports and freeze; or if CONFIG_DEBUG_VM=y, it\nhits an earlier VM_BUG_ON_PAGE(!PageLocked), depending on config.\n\nBut shmem_replace_page() is not a common path: it's only called when\nswapin (or swapoff) finds the page was already read into an unsuitable\nzone: usually all zones are suitable, but gem objects for a few drm\ndevices (gma500, omapdrm, crestline, broadwater) require zone DMA32 if\nthere's more than 4GB of ram.\n\nFixes: 800d8c63b2e9 (\"shmem: add huge pages support\")\nLink: http://lkml.kernel.org/r/alpine.LSU.2.11.1611062003510.11253@eggly.anvils\nSigned-off-by: Hugh Dickins <hughd@google.com>\nAcked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/c87739e5d029a61ef1bbaccd90d07194459f9640"},{"sha":"67c79e166d467c21778aaccc1f8992572c9062f7","author":{"name":"Jann Horn","email":"56d347afa87ea2ef19771afd2a88746144865893@thejh.net"},"message":"swapfile: fix memory corruption via malformed swapfile\n\ncommit dd111be69114cc867f8e826284559bfbc1c40e37 upstream.\n\nWhen root activates a swap partition whose header has the wrong\nendianness, nr_badpages elements of badpages are swabbed before\nnr_badpages has been checked, leading to a buffer overrun of up to 8GB.\n\nThis normally is not a security issue because it can only be exploited\nby root (more specifically, a process with CAP_SYS_ADMIN or the ability\nto modify a swap file/partition), and such a process can already e.g.\nmodify swapped-out memory of any other userspace process on the system.\n\nLink: http://lkml.kernel.org/r/1477949533-2509-1-git-send-email-jann@thejh.net\nSigned-off-by: Jann Horn <jann@thejh.net>\nAcked-by: Kees Cook <keescook@chromium.org>\nAcked-by: Jerome Marchand <jmarchan@redhat.com>\nAcked-by: Johannes Weiner <hannes@cmpxchg.org>\nCc: \"Kirill A. Shutemov\" <kirill.shutemov@linux.intel.com>\nCc: Vlastimil Babka <vbabka@suse.cz>\nCc: Hugh Dickins <hughd@google.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/67c79e166d467c21778aaccc1f8992572c9062f7"},{"sha":"e87bf4f558f1638df307ebadb7c8048f60cc12fe","author":{"name":"Naoya Horiguchi","email":"dd1049595340a06ff67286dc9114d25ba1f95e21@ah.jp.nec.com"},"message":"mm: hwpoison: fix thp split handling in memory_failure()\n\ncommit c3901e722b2975666f42748340df798114742d6d upstream.\n\nWhen memory_failure() runs on a thp tail page after pmd is split, we\ntrigger the following VM_BUG_ON_PAGE():\n\n   page:ffffd7cd819b0040 count:0 mapcount:0 mapping:         (null) index:0x1\n   flags: 0x1fffc000400000(hwpoison)\n   page dumped because: VM_BUG_ON_PAGE(!page_count(p))\n   ------------[ cut here ]------------\n   kernel BUG at /src/linux-dev/mm/memory-failure.c:1132!\n\nmemory_failure() passed refcount and page lock from tail page to head\npage, which is not needed because we can pass any subpage to\nsplit_huge_page().\n\nFixes: 61f5d698cc97 (\"mm: re-enable THP\")\nLink: http://lkml.kernel.org/r/1477961577-7183-1-git-send-email-n-horiguchi@ah.jp.nec.com\nSigned-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/e87bf4f558f1638df307ebadb7c8048f60cc12fe"},{"sha":"d6ee4f47e2e79c7b367ccc8df2959a3c080e1b83","author":{"name":"Mike Kravetz","email":"d107146bb715ad1d7b031c14b4c72b7561dc8356@oracle.com"},"message":"mm/hugetlb: fix huge page reservation leak in private mapping error paths\n\ncommit 96b96a96ddee4ba08ce4aeb8a558a3271fd4a7a7 upstream.\n\nError paths in hugetlb_cow() and hugetlb_no_page() may free a newly\nallocated huge page.\n\nIf a reservation was associated with the huge page, alloc_huge_page()\nconsumed the reservation while allocating.  When the newly allocated\npage is freed in free_huge_page(), it will increment the global\nreservation count.  However, the reservation entry in the reserve map\nwill remain.\n\nThis is not an issue for shared mappings as the entry in the reserve map\nindicates a reservation exists.  But, an entry in a private mapping\nreserve map indicates the reservation was consumed and no longer exists.\nThis results in an inconsistency between the reserve map and the global\nreservation count.  This 'leaks' a reserved huge page.\n\nCreate a new routine restore_reserve_on_error() to restore the reserve\nentry in these specific error paths.  This routine makes use of a new\nfunction vma_add_reservation() which will add a reserve entry for a\nspecific address/page.\n\nIn general, these error paths were rarely (if ever) taken on most\narchitectures.  However, powerpc contained arch specific code that that\nresulted in an extra fault and execution of these error paths on all\nprivate mappings.\n\nFixes: 67961f9db8c4 (\"mm/hugetlb: fix huge page reserve accounting for private mappings)\nLink: http://lkml.kernel.org/r/1476933077-23091-2-git-send-email-mike.kravetz@oracle.com\nSigned-off-by: Mike Kravetz <mike.kravetz@oracle.com>\nReported-by: Jan Stancek <jstancek@redhat.com>\nTested-by: Jan Stancek <jstancek@redhat.com>\nReviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>\nAcked-by: Hillf Danton <hillf.zj@alibaba-inc.com>\nCc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>\nCc: Michal Hocko <mhocko@suse.com>\nCc: Kirill A . Shutemov <kirill.shutemov@linux.intel.com>\nCc: Dave Hansen <dave.hansen@linux.intel.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/d6ee4f47e2e79c7b367ccc8df2959a3c080e1b83"},{"sha":"2f3e0b82ebe9781120e253702709f8ae52132b61","author":{"name":"Andrey Ryabinin","email":"93e46ad9a51c483bc64b86deb9d8d0d7dbbb3fe0@virtuozzo.com"},"message":"coredump: fix unfreezable coredumping task\n\ncommit 70d78fe7c8b640b5acfad56ad341985b3810998a upstream.\n\nIt could be not possible to freeze coredumping task when it waits for\n'core_state->startup' completion, because threads are frozen in\nget_signal() before they got a chance to complete 'core_state->startup'.\n\nInability to freeze a task during suspend will cause suspend to fail.\nAlso CRIU uses cgroup freezer during dump operation.  So with an\nunfreezable task the CRIU dump will fail because it waits for a\ntransition from 'FREEZING' to 'FROZEN' state which will never happen.\n\nUse freezer_do_not_count() to tell freezer to ignore coredumping task\nwhile it waits for core_state->startup completion.\n\nLink: http://lkml.kernel.org/r/1475225434-3753-1-git-send-email-aryabinin@virtuozzo.com\nSigned-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>\nAcked-by: Pavel Machek <pavel@ucw.cz>\nAcked-by: Oleg Nesterov <oleg@redhat.com>\nCc: Alexander Viro <viro@zeniv.linux.org.uk>\nCc: Tejun Heo <tj@kernel.org>\nCc: \"Rafael J. Wysocki\" <rjw@rjwysocki.net>\nCc: Michal Hocko <mhocko@kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/2f3e0b82ebe9781120e253702709f8ae52132b61"},{"sha":"4058116db4d0afb9b03d90869ae7063c589ada34","author":{"name":"Michael Holzheu","email":"b314df21e46473b2ba84dc59375d30b15cf9dee0@linux.vnet.ibm.com"},"message":"s390/hypfs: Use get_free_page() instead of kmalloc to ensure page alignment\n\ncommit 237d6e6884136923b6bd26d5141ebe1d065960c9 upstream.\n\nSince commit d86bd1bece6f (\"mm/slub: support left redzone\") it is no longer\nguaranteed that kmalloc(PAGE_SIZE) returns page aligned memory.\n\nAfter the above commit we get an error for diag224 because aligned\nmemory is required. This leads to the following user visible error:\n\n # mount none -t s390_hypfs /sys/hypervisor/\n mount: unknown filesystem type 's390_hypfs'\n\n # dmesg | grep hypfs\n hypfs.cccfb8: The hardware system does not provide all functions\n               required by hypfs\n hypfs.7a79f0: Initialization of hypfs failed with rc=-61\n\nFix this problem and use get_free_page() instead of kmalloc() to get\ncorrectly aligned memory.\n\nSigned-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>\nSigned-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/4058116db4d0afb9b03d90869ae7063c589ada34"},{"sha":"7fac0361f94e24b179c5a7d1cfc57790f33624b8","author":{"name":"Vineet Gupta","email":"a7e6bac69589bd9c485fe09b6cb3c1c86c8546ec@synopsys.com"},"message":"ARC: timer: rtc: implement read loop in \"C\" vs. inline asm\n\ncommit 922cc171998ac3dbe74d57011ef7ed57e9b0d7df upstream.\n\nThe current code doesn't even compile as somehow the inline assembly\ncan't see the register names defined as ARC_RTC_*\nI'm pretty sure It worked when I first got it merged, but the tools were\ndefinitely different then.\n\nSo better to write this in \"C\" anyways.\n\nAcked-by: Daniel Lezcano <daniel.lezcano@linaro.org>\nSigned-off-by: Vineet Gupta <vgupta@synopsys.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/7fac0361f94e24b179c5a7d1cfc57790f33624b8"},{"sha":"004e7c97f181ed4e66d9160c231caf55fb072312","author":{"name":"Bjorn Helgaas","email":"d58560f8a8eaa2bf0a57092b2469a9a49461ac56@google.com"},"message":"PCI: Don't attempt to claim shadow copies of ROM\n\ncommit 16d917b130d782b94fa02afc7bdf0d4aae689da4 upstream.\n\nIf we're using a shadow copy of a PCI device ROM, the shadow copy is in RAM\nand the device never sees accesses to it and doesn't respond to it.  We\ndon't have to route the shadow range to the PCI device, and the device\ndoesn't have to claim the range.\n\nPreviously we treated the shadow copy as though it were the ROM BAR, and we\nfailed to claim it because the region wasn't routed to the device:\n\n  pci 0000:01:00.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]\n  pci_bus 0000:01: Allocating resources\n  pci 0000:01:00.0: can't claim BAR 6 [mem 0x000c0000-0x000dffff]: no compatible bridge window\n\nThe failure path of pcibios_allocate_dev_rom_resource() cleared out the\nresource start address, which also caused the following ioremap() warning:\n\n  WARNING: CPU: 0 PID: 116 at /build/linux-akdJXO/linux-4.8.0/arch/x86/mm/ioremap.c:121 __ioremap_caller+0x1ec/0x370\n  ioremap on RAM at 0x0000000000000000 - 0x000000000001ffff\n\nHandle an option ROM shadow copy as RAM, without trying to insert it into\nthe iomem resource tree.\n\nThis fixes a regression caused by 0c0e0736acad (\"PCI: Set ROM shadow\nlocation in arch code, not in PCI core\"), which appeared in v4.6.  The\nregression causes video device initialization to fail.  This was reported\non AMD Turks, but it likely affects others as well.\n\nFixes: 0c0e0736acad (\"PCI: Set ROM shadow location in arch code, not in PCI core\")\nReported-and-tested-by: Vecu Bosseur <vecu.bosseur@gmail.com>\nLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1627496\nLink: https://bugzilla.kernel.org/show_bug.cgi?id=175391\nLink: https://bugzilla.redhat.com/show_bug.cgi?id=1352272\nSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/004e7c97f181ed4e66d9160c231caf55fb072312"},{"sha":"f5ad9646261585338c94cd57d06c0b61964576de","author":{"name":"Alexey Brodkin","email":"00e1475b58c40168fd81030071cb38630a735fc1@synopsys.com"},"message":"arc: Implement arch-specific dma_map_ops.mmap\n\ncommit a79a812131b07254c09cf325ec68c0d05aaed0b5 upstream.\n\nWe used to use generic implementation of dma_map_ops.mmap which is\ndma_common_mmap() but that only worked for simpler cached mappings when\nvaddr = paddr.\n\nIf a driver requests uncached DMA buffer kernel maps it to virtual\naddress so that MMU gets involved and page uncached status takes into\naccount. In that case usage of dma_common_mmap() lead to mapping of\nvaddr to vaddr for user-space which is obviously wrong. For more detals\nplease refer to verbose explanation here [1].\n\nSo here we implement our own version of mmap() which always deals\nwith dma_addr and maps underlying memory to user-space properly\n(note that DMA buffer mapped to user-space is always uncached\nbecause there's no way to properly manage cache from user-space).\n\n[1] https://lkml.org/lkml/2016/10/26/973\n\nReviewed-by: Catalin Marinas <catalin.marinas@arm.com>\nCc: Marek Szyprowski <m.szyprowski@samsung.com>\nSigned-off-by: Alexey Brodkin <abrodkin@synopsys.com>\nSigned-off-by: Vineet Gupta <vgupta@synopsys.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/f5ad9646261585338c94cd57d06c0b61964576de"},{"sha":"1d99fe3317e31f2ba58067d6766346a1688d83c6","author":{"name":"Mika Westerberg","email":"a8d1ecdad48d5197b32d89207ef409d7040b1cf4@linux.intel.com"},"message":"pinctrl: cherryview: Serialize register access in suspend/resume\n\ncommit 56211121c0825cd188caad05574fdc518d5cac6f upstream.\n\nIf async suspend is enabled, the driver may access registers concurrently\nwith another instance which may fail because of the bug in Cherryview GPIO\nhardware. Prevent this by taking the shared lock while accessing the\nhardware in suspend and resume hooks.\n\nSigned-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>\nSigned-off-by: Linus Walleij <linus.walleij@linaro.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/1d99fe3317e31f2ba58067d6766346a1688d83c6"},{"sha":"f062e738c19b508a3ad15b99940fa9ec93b9addb","author":{"name":"Mika Westerberg","email":"a8d1ecdad48d5197b32d89207ef409d7040b1cf4@linux.intel.com"},"message":"pinctrl: cherryview: Prevent possible interrupt storm on resume\n\ncommit d2cdf5dc58f6970e9d9d26e47974c21fe87983f3 upstream.\n\nWhen the system is suspended to S3 the BIOS might re-initialize certain\nGPIO pins back to their original state or it may re-program interrupt mask\nof others. For example Acer TravelMate B116-M had BIOS bug where certain\nGPIO pin (MF_ISH_GPIO_5) was programmed to trigger on high level, and the\npin state was high once the BIOS gave control to the OS on resume.\n\nThis triggers lots of messages like:\n\n irq 117, desc: ffff88017a61e600, depth: 1, count: 0, unhandled: 0\n ->handle_irq():  ffffffff8109b613, handle_bad_irq+0x0/0x1e0\n ->irq_data.chip(): ffffffffa0020180, chv_pinctrl_exit+0x2d84/0x12 [pinctrl_cherryview]\n ->action():           (null)\n    IRQ_NOPROBE set\n\nWe reset the mask back to known state in chv_pinctrl_resume() but that is\ncalled only after device interrupts have already been enabled.\n\nNow, this particular issue was fixed by upgrading the BIOS to the latest\n(v1.23) but not everybody upgrades their BIOSes so we fix it up in the\ndriver as well.\n\nPrevent the possible interrupt storm by moving suspend and resume hooks to\nbe called at _noirq time instead. Since device interrupts are still\ndisabled we can restore the mask back to known state before interrupt storm\nhappens.\n\nReported-by: Christian Steiner <christian.steiner@outlook.de>\nSigned-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>\nSigned-off-by: Linus Walleij <linus.walleij@linaro.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/f062e738c19b508a3ad15b99940fa9ec93b9addb"},{"sha":"10d24701f3f424940021c7c1a654c247ef04fb7b","author":{"name":"Laura Abbott","email":"1a58644182d4410bcfd1b17f9f7459a41bdc05dd@redhat.com"},"message":"cpupower: Correct return type of cpu_power_is_cpu_online() in cpufreq-set\n\ncommit c25badc9ceb612c6cc227a6fc4b0aaf678e3bcf9 upstream.\n\nWhen converting to a shared library in ac5a181d065d (\"cpupower: Add\ncpuidle parts into library\"), cpu_freq_cpu_exists() was converted to\ncpupower_is_cpu_online(). cpu_req_cpu_exists() returned 0 on success and\n-ENOSYS on failure whereas cpupower_is_cpu_online returns 1 on success.\nCheck for the correct return value in cpufreq-set.\n\nLink: https://bugzilla.redhat.com/show_bug.cgi?id=1374212\nFixes: ac5a181d065d (cpupower: Add cpuidle parts into library)\nReported-by: Julian Seward <jseward@acm.org>\nSigned-off-by: Laura Abbott <labbott@redhat.com>\nAcked-by: Thomas Renninger <trenn@suse.com>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/10d24701f3f424940021c7c1a654c247ef04fb7b"},{"sha":"bde8d3f733755edc95840cf4b57d9b6bc03c7c44","author":{"name":"Adrian Hunter","email":"daa46418375a26a999430d83f18360fac0856a49@intel.com"},"message":"mmc: sdhci: Fix CMD line reset interfering with ongoing data transfer\n\ncommit 6ebebeab5185f50d55c6a24d0abe47e5dac1b191 upstream.\n\nCMD line reset during an ongoing data transfer can cause the data transfer\nto hang.  Fix by delaying the reset until the data transfer is finished.\n\nSigned-off-by: Adrian Hunter <adrian.hunter@intel.com>\nSigned-off-by: Ulf Hansson <ulf.hansson@linaro.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/bde8d3f733755edc95840cf4b57d9b6bc03c7c44"},{"sha":"ce4dfe7d927ec5b37c594b370b8d646588e1c974","author":{"name":"Adrian Hunter","email":"daa46418375a26a999430d83f18360fac0856a49@intel.com"},"message":"mmc: sdhci: Fix unexpected data interrupt handling\n\ncommit 69b962a65a547690a356f9f76bc4f53db538ac49 upstream.\n\nIn the busy response case (i.e. !host->data), an unexpected data interrupt\nwould result in clearing the data command as though it had completed but\nwithout informing the upper layers and thus resulting in a hang.  Fix by\nonly clearing the data command for data interrupts that are expected.\n\nSigned-off-by: Adrian Hunter <adrian.hunter@intel.com>\nSigned-off-by: Ulf Hansson <ulf.hansson@linaro.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/ce4dfe7d927ec5b37c594b370b8d646588e1c974"},{"sha":"5289e59246dd32e49bff572e267168109e60051d","author":{"name":"Ulf Hansson","email":"3ad0d1c4b920d57f1a9faa9ebc13c3d9edadde58@linaro.org"},"message":"mmc: mmc: Use 500ms as the default generic CMD6 timeout\n\ncommit fe1b5700c70faac6e027982d59667bc6020de5a8 upstream.\n\nIn the eMMC 4.51 version of the spec, an EXT_CSD field called\nGENERIC_CMD6_TIME[248] was added. This allows cards to specify the maximum\ntime it may need to move out from its busy state, when a CMD6 command has\nbeen sent.\n\nIn cases when the card is compliant to versions < 4.51 of the eMMC spec,\nobviously the core needs to use a fall-back value for this timeout, which\ncurrently is set to 10 minutes. This value is completely in the wrong range\nand importantly in some cases it causes a card initialization to take more\nthan 10 minute to complete.\n\nEarlier this scenario was avoided as the mmc core used CMD13 to poll the\ncard, to find out when it stopped signaling busy. Commit 08573eaf1a70\n(\"mmc: mmc: do not use CMD13 to get status after speed mode switch\")\nchanged this behavior.\n\nInstead of reverting that commit, which would cause other issues, let's\ninstead start by picking a simple solution for the problem, by using a\n500ms default generic CMD6 timeout.\n\nThe reason for using exactly 500ms, comes from observations that shows it's\nquite common for cards to specify 250ms. 500ms is two times that value so\nlikely it should be enough for most cards.\n\nFixes: 08573eaf1a70 (\"mmc: mmc: do not use CMD13 to get status after speed\nmode switch\")\nSigned-off-by: Ulf Hansson <ulf.hansson@linaro.org>\nTested-by: Stephen Boyd <sboyd@codeaurora.org>\nTested-by: Linus Walleij <linus.walleij@linaro.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/5289e59246dd32e49bff572e267168109e60051d"}]}
{"actor":{"display_login":"heftig"}}