{"push_id":753799349,"size":125,"distinct_size":1,"ref":"refs/heads/4.1/master","head":"1385648b7fdeddc163cca00718562fa0ad122052","before":"d30b5c1c7ca2daf3d5b314ebe9fff11f43c204ee","commits":[{"sha":"bbf9f2c9cf06ccb1543c23501f77f6d34868d009","author":{"email":"2796b2a6f60f1cdadaf10e577f7c9240e2ad3d38@au1.ibm.com","name":"Ian Munsie"},"message":"cxl: Fix off by one error allowing subsequent mmap page to be accessed\n\ncommit 10a5894f2dedd8a26b3132497445b314c0d952c4 upstream.\n\nIt was discovered that if a process mmaped their problem state area they\nwere able to access one page more than expected, potentially allowing\nthem to access the problem state area of an unrelated process.\n\nThis was due to a simple off by one error in the mmap fault handler\nintroduced in 0712dc7e73e59d79bcead5d5520acf4e9e917e87 (\"cxl: Fix issues\nwhen unmapping contexts\"), which is fixed in this patch.\n\nFixes: 0712dc7e73e5 (\"cxl: Fix issues when unmapping contexts\")\nSigned-off-by: Ian Munsie <imunsie@au1.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/bbf9f2c9cf06ccb1543c23501f77f6d34868d009"},{"sha":"4a0c377cda3533ff80c60c4fd46f787aff4715c3","author":{"email":"cf1af486034ab0119a20f38a060e40da25f4cea3@axtens.net","name":"Daniel Axtens"},"message":"cxl: Check if afu is not null in cxl_slbia\n\ncommit 2c069a118fe1d80c47dca84e1561045fc7f3cc9e upstream.\n\nThe pointer to an AFU in the adapter's list of AFUs can be null\nif we're in the process of removing AFUs. The afu_list_lock\ndoesn't guard against this.\n\nSay we have 2 slices, and we're in the process of removing cxl.\n - We remove the AFUs in order (see cxl_remove). In cxl_remove_afu\n   for AFU 0, we take the lock, set adapter->afu[0] = NULL, and\n   release the lock.\n - Then we get an slbia. In cxl_slbia we take the lock, and set\n   afu = adapter->afu[0], which is NULL.\n - Therefore our attempt to check afu->enabled will blow up.\n\nTherefore, check if afu is a null pointer before dereferencing it.\n\nSigned-off-by: Daniel Axtens <dja@axtens.net>\nAcked-by: Michael Neuling <mikey@neuling.org>\nAcked-by: Ian Munsie <imunsie@au1.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/4a0c377cda3533ff80c60c4fd46f787aff4715c3"},{"sha":"5f0f854a0a8185240c934c77e8c9092313ba932e","author":{"email":"fac76aafe57fc9acb24e05f5dba9b58a43a0a645@linux.vnet.ibm.com","name":"Shreyas B. Prabhu"},"message":"powerpc/powernv: Fix race in updating core_idle_state\n\ncommit b32aadc1a8ed84afbe924cd2ced31cd6a2e67074 upstream.\n\ncore_idle_state is maintained for each core. It uses 0-7 bits to track\nwhether a thread in the core has entered fastsleep or winkle. 8th bit is\nused as a lock bit.\nThe lock bit is set in these 2 scenarios-\n - The thread is first in subcore to wakeup from sleep/winkle.\n - If its the last thread in the core about to enter sleep/winkle\n\nWhile the lock bit is set, if any other thread in the core wakes up, it\nloops until the lock bit is cleared before proceeding in the wakeup\npath. This helps prevent race conditions w.r.t fastsleep workaround and\nprevents threads from switching to process context before core/subcore\nresources are restored.\n\nBut, in the path to sleep/winkle entry, we currently don't check for\nlock-bit. This exposes us to following race when running with subcore\non-\n\nFirst thread in the subcorea\t\tAnother thread in the same\nwaking up\t\t   \t\tcore entering sleep/winkle\n\nlwarx   r15,0,r14\nori     r15,r15,PNV_CORE_IDLE_LOCK_BIT\nstwcx.  r15,0,r14\n[Code to restore subcore state]\n\n\t\t\t\t\t\tlwarx   r15,0,r14\n\t\t\t\t\t\t[clear thread bit]\n\t\t\t\t\t\tstwcx.  r15,0,r14\n\nandi.   r15,r15,PNV_CORE_IDLE_THREAD_BITS\nstw     r15,0(r14)\n\nHere, after the thread entering sleep clears its thread bit in\ncore_idle_state, the value is overwritten by the thread waking up.\nIn such cases when the core enters fastsleep, code mistakes an idle\nthread as running. Because of this, the first thread waking up from\nfastsleep which is supposed to resync timebase skips it. So we can\nend up having a core with stale timebase value.\n\nThis patch fixes the above race by looping on the lock bit even while\nentering the idle states.\n\nSigned-off-by: Shreyas B. Prabhu <shreyas@linux.vnet.ibm.com>\nFixes: 7b54e9f213f76 'powernv/powerpc: Add winkle support for offline cpus'\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/5f0f854a0a8185240c934c77e8c9092313ba932e"},{"sha":"d474669e907ea28024def319bfcdef6a2c21d6ac","author":{"email":"6b8646d310837fed93a129ed3c979b90c7f2674f@gmail.com","name":"Dmitry Torokhov"},"message":"Revert \"Input: synaptics - allocate 3 slots to keep stability in image sensors\"\n\ncommit dbf3c370862d73fcd2c74ca55e254bb02143238d upstream.\n\nThis reverts commit 63c4fda3c0bb841b1aad1298fc7fe94058fc79f8 as it\ncauses issues with detecting 3-finger taps.\n\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100481\nAcked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/d474669e907ea28024def319bfcdef6a2c21d6ac"},{"sha":"78eb5efb6f79ca8fbd03cd0082e6bb22ca37fb48","author":{"email":"d3a7a82a6ff309c7c46b71cf01386d84d6ca7c2a@bell.net","name":"John David Anglin"},"message":"parisc: Fix some PTE/TLB race conditions and optimize __flush_tlb_range based on timing results\n\ncommit 01ab60570427caa24b9debc369e452e86cd9beb4 upstream.\n\nThe increased use of pdtlb/pitlb instructions seemed to increase the\nfrequency of random segmentation faults building packages. Further, we\nhad a number of cases where TLB inserts would repeatedly fail and all\nforward progress would stop. The Haskell ghc package caused a lot of\ntrouble in this area. The final indication of a race in pte handling was\nthis syslog entry on sibaris (C8000):\n\n swap_free: Unused swap offset entry 00000004\n BUG: Bad page map in process mysqld  pte:00000100 pmd:019bbec5\n addr:00000000ec464000 vm_flags:00100073 anon_vma:0000000221023828 mapping: (null) index:ec464\n CPU: 1 PID: 9176 Comm: mysqld Not tainted 4.0.0-2-parisc64-smp #1 Debian 4.0.5-1\n Backtrace:\n  [<0000000040173eb0>] show_stack+0x20/0x38\n  [<0000000040444424>] dump_stack+0x9c/0x110\n  [<00000000402a0d38>] print_bad_pte+0x1a8/0x278\n  [<00000000402a28b8>] unmap_single_vma+0x3d8/0x770\n  [<00000000402a4090>] zap_page_range+0xf0/0x198\n  [<00000000402ba2a4>] SyS_madvise+0x404/0x8c0\n\nNote that the pte value is 0 except for the accessed bit 0x100. This bit\nshouldn't be set without the present bit.\n\nIt should be noted that the madvise system call is probably a trigger for many\nof the random segmentation faults.\n\nIn looking at the kernel code, I found the following problems:\n\n1) The pte_clear define didn't take TLB lock when clearing a pte.\n2) We didn't test pte present bit inside lock in exception support.\n3) The pte and tlb locks needed to merged in order to ensure consistency\nbetween page table and TLB. This also has the effect of serializing TLB\nbroadcasts on SMP systems.\n\nThe attached change implements the above and a few other tweaks to try\nto improve performance. Based on the timing code, TLB purges are very\nslow (e.g., ~ 209 cycles per page on rp3440). Thus, I think it\nbeneficial to test the split_tlb variable to avoid duplicate purges.\nProbably, all PA 2.0 machines have combined TLBs.\n\nI dropped using __flush_tlb_range in flush_tlb_mm as I realized all\napplications and most threads have a stack size that is too large to\nmake this useful. I added some comments to this effect.\n\nSince implementing 1 through 3, I haven't had any random segmentation\nfaults on mx3210 (rp3440) in about one week of building code and running\nas a Debian buildd.\n\nSigned-off-by: John David Anglin <dave.anglin@bell.net>\nSigned-off-by: Helge Deller <deller@gmx.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/78eb5efb6f79ca8fbd03cd0082e6bb22ca37fb48"},{"sha":"0ab58712e54f3a3258072feb15ab14bfbc42fa02","author":{"email":"aa5b4d6ac057e7b0849afbbced06a03fc6c87d45@wanadoo.fr","name":"Christophe Jaillet"},"message":"parisc: mm: Fix a memory leak related to pmd not attached to the pgd\n\ncommit 4c4ac9a48ac512c6b5a6cca06cfad2ad96e8caaa upstream.\n\nCommit 0e0da48dee8d (\"parisc: mm: don't count preallocated pmds\")\nintroduced a memory leak.\n\nAfter this commit, the 'return' statement in pmd_free is executed in all\ncases. Even for pmd that are not attached to the pgd.  So 'free_pages'\ncan never be called anymore, leading to a memory leak.\n\nSigned-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>\nAcked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>\nAcked-by: Mikulas Patocka <mpatocka@redhat.com>\nAcked-by: Helge Deller <deller@gmx.de>\nSigned-off-by: Helge Deller <deller@gmx.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/0ab58712e54f3a3258072feb15ab14bfbc42fa02"},{"sha":"7185dab0dbe1f8e2cae26dd759475aa146e1f071","author":{"email":"94b2a0a74cb42a2dd0cf1b763601af7f13907aa9@free.fr","name":"Robert Jarzmik"},"message":"ARM: pxa: fix dm9000 platform data regression\n\ncommit a927ef895e288e79f1bfed221f27d7bfa37e907f upstream.\n\nSince dm9000 driver added support for a vcc regulator, platform data\nbased platforms have their ethernet broken, as the regulator claiming\nreturns -EPROBE_DEFER and prevents dm9000 loading.\n\nThis patch fixes this for all pxa boards using dm9000, by using the\nspecific regulator_has_full_constraints() function.\n\nThis was discovered and tested on the cm-x300 board.\n\nFixes: 7994fe55a4a2 (\"dm9000: Add regulator and reset support to dm9000\")\nSigned-off-by: Robert Jarzmik <robert.jarzmik@free.fr>\nAcked-by: Igor Grinberg <grinberg@compulab.co.il>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/7185dab0dbe1f8e2cae26dd759475aa146e1f071"},{"sha":"c0c4945b2c39ca6a543664cbccce26b400d66562","author":{"email":"eba86029bdfc5762d0419aa8dd4fd0368b2d01d4@ti.com","name":"Roger Quadros"},"message":"ARM: dts: dra7x-evm: Prevent glitch on DCAN1 pinmux\n\ncommit 2acb5c301edf39ab6d066687ce70da1166e4de9e upstream.\n\nDriver core sets \"default\" pinmux on on probe and CAN driver\nsets \"sleep\" pinmux during register. This causes a small window\nwhere the CAN pins are in \"default\" state with the DCAN module\nbeing disabled.\n\nChange the \"default\" state to be like sleep so this glitch is\navoided. Add a new \"active\" state that is used by the driver\nwhen CAN is actually active.\n\nSigned-off-by: Roger Quadros <rogerq@ti.com>\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/zen-kernel/zen-kernel/commits/c0c4945b2c39ca6a543664cbccce26b400d66562"},{"sha":"0784a0b533fc6526b2f899ce9fe50d745f791fba","author":{"email":"eba86029bdfc5762d0419aa8dd4fd0368b2d01d4@ti.com","name":"Roger Quadros"},"message":"ARM: dts: am57xx-beagle-x15: Provide supply for usb2_phy2\n\ncommit 9ab402aed38b95d9ce453108622be0fc6f167568 upstream.\n\nWithout this USB2 breaks if USB1 is disabled or USB1\ninitializes after USB2 e.g. due to deferred probing.\n\nFixes: 5a0f93c6576a (\"ARM: dts: Add am57xx-beagle-x15\")\nSigned-off-by: Roger Quadros <rogerq@ti.com>\nSigned-off-by: Tony Lindgren <tony@atomide.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/0784a0b533fc6526b2f899ce9fe50d745f791fba"},{"sha":"50c301372e86ce52a897ead3f55044811a9ebb57","author":{"email":"2a0259761cc3e88db42be5300c1579a67c77e65e@samsung.com","name":"Marek Szyprowski"},"message":"ARM: 8404/1: dma-mapping: fix off-by-one error in bitmap size check\n\ncommit 462859aa7bbe1ac83ec4377a0a06fe60778f3f27 upstream.\n\nnr_bitmaps member of mapping structure stores the number of already\nallocated bitmaps and it is interpreted as loop iterator (it starts from\n0 not from 1), so a comparison against number of possible bitmap\nextensions should include this fact. This patch fixes this by changing\nthe extension failure condition. This issue has been introduced by\ncommit 4d852ef8c2544ce21ae41414099a7504c61164a0 (\"arm: dma-mapping: Add\nsupport to extend DMA IOMMU mappings\").\n\nReported-by: Hyungwon Hwang <human.hwang@samsung.com>\nSigned-off-by: Marek Szyprowski <m.szyprowski@samsung.com>\nReviewed-by: Hyungwon Hwang <human.hwang@samsung.com>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/50c301372e86ce52a897ead3f55044811a9ebb57"},{"sha":"9af14dc3d33cba85698bbfea62bcf8fee56a7c76","author":{"email":"48c9e973d8f86eb0cdae200124c5925db7587c4e@pengutronix.de","name":"Lucas Stach"},"message":"ARM: imx6: gpc: always enable PU domain if CONFIG_PM is not set\n\ncommit d438462c20a300139c2e5e65b96cadaa21b58d9a upstream.\n\nIf CONFIG_PM is not set the PU power domain needs to be enabled always,\notherwise there are two failure scenarios which will hang the system if\none of the devices in the PU domain is accessed.\n\n1. New DTs (4.1+) drop the \"always-on\" property from the PU regulator, so\nif it isn't properly enabled by the GPC code it will be disabled at the\nend of boot.\n\n2. If the bootloader already disabled the PU domain the GPC explicitly\nneeds to enable it again, even if the kernel doesn't do any power\nmanagement. This is a bit hypothetical, as it requires to boot a\nmainline kernel on a downstream bootloader, as no mainline bootloader\ndisables the PM domains.\n\nSigned-off-by: Lucas Stach <l.stach@pengutronix.de>\nAcked-by: Philipp Zabel <p.zabel@pengutronix.de>\nSigned-off-by: Shawn Guo <shawn.guo@linaro.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/9af14dc3d33cba85698bbfea62bcf8fee56a7c76"},{"sha":"a6130c5e14b2f824c0b7e5e9dddd46529616c6af","author":{"email":"5cdbcb0e11d2b5ebc39222958c54a1c6329d0c9d@imgtec.com","name":"Markos Chandras"},"message":"MIPS: Fix erroneous JR emulation for MIPS R6\n\ncommit 143fefc8f315cd10e046e6860913c421c3385cb1 upstream.\n\nCommit 5f9f41c474befb4ebbc40b27f65bb7d649241581 (\"MIPS: kernel: Prepare\nthe JR instruction for emulation on MIPS R6\") added support for\nemulating the JR instruction on MIPS R6 cores but that introduced a bug\nwhich could be triggered when hitting a JALR opcode because the code used\nthe wrong field in the 'r_format' struct to determine the instruction\nopcode. This lead to crashes because an emulated JALR instruction was\ntreated as a JR one when the R6 emulator was turned off.\n\nFixes: 5f9f41c474be (\"MIPS: kernel: Prepare the JR instruction for emulation on MIPS R6\")\nSigned-off-by: Markos Chandras <markos.chandras@imgtec.com>\nCc: linux-mips@linux-mips.org\nPatchwork: https://patchwork.linux-mips.org/patch/10583/\nSigned-off-by: Ralf Baechle <ralf@linux-mips.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/a6130c5e14b2f824c0b7e5e9dddd46529616c6af"},{"sha":"7ed06198d9b38b8a6c8e8a0944a4a6c3f03e5a35","author":{"email":"5cdbcb0e11d2b5ebc39222958c54a1c6329d0c9d@imgtec.com","name":"Markos Chandras"},"message":"MIPS: c-r4k: Fix cache flushing for MT cores\n\ncommit cccf34e9411c41b0cbfb41980fe55fc8e7c98fd2 upstream.\n\nMT_SMP is not the only SMP option for MT cores. The MT_SMP option\nallows more than one VPE per core to appear as a secondary CPU in the\nsystem. Because of how CM works, it propagates the address-based\ncache ops to the secondary cores but not the index-based ones.\nBecause of that, the code does not use IPIs to flush the L1 caches on\nsecondary cores because the CM would have done that already. However,\nthe CM functionality is independent of the type of SMP kernel so even in\nnon-MT kernels, IPIs are not necessary. As a result of which, we change\nthe conditional to depend on the CM presence. Moreover, since VPEs on\nthe same core share the same L1 caches, there is no need to send an\nIPI on all of them so we calculate a suitable cpumask with only one\nVPE per core.\n\nSigned-off-by: Markos Chandras <markos.chandras@imgtec.com>\nCc: linux-mips@linux-mips.org\nPatchwork: https://patchwork.linux-mips.org/patch/10654/\nSigned-off-by: Ralf Baechle <ralf@linux-mips.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/7ed06198d9b38b8a6c8e8a0944a4a6c3f03e5a35"},{"sha":"219485e36468309cc71f7580d633a0b416d8e985","author":{"email":"85f1bffadddedccfafc0ae065a06aa636075387f@imgtec.com","name":"Paul Burton"},"message":"MIPS: Require O32 FP64 support for MIPS64 with O32 compat\n\ncommit 4e9d324d4288b082497c30bc55b8ad13acc7cf01 upstream.\n\nMIPS32r6 code requires FP64 (ie. FR=1) support. Building a kernel with\nsupport for MIPS32r6 binaries but without support for O32 with FP64 is\ntherefore a problem which can lead to incorrectly executed userland.\n\nCONFIG_MIPS_O32_FP64_SUPPORT is already selected when the kernel is\nconfigured for MIPS32r6, but not when the kernel is configured for\nMIPS64r6 with O32 compat support. Select CONFIG_MIPS_O32_FP64_SUPPORT in\nsuch configurations to prevent building kernels which execute MIPS32r6\nuserland incorrectly.\n\nSigned-off-by: Paul Burton <paul.burton@imgtec.com>\nCc: Markos Chandras <markos.chandras@imgtec.com>\nCc: linux-mips@linux-mips.org\nCc: Matthew Fortune <matthew.fortune@imgtec.com>\nCc: linux-kernel@vger.kernel.org\nPatchwork: https://patchwork.linux-mips.org/patch/10674/\nSigned-off-by: Ralf Baechle <ralf@linux-mips.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/219485e36468309cc71f7580d633a0b416d8e985"},{"sha":"cea0f568222b53b21242c50445776fccd4a1b8b8","author":{"email":"5cdbcb0e11d2b5ebc39222958c54a1c6329d0c9d@imgtec.com","name":"Markos Chandras"},"message":"MIPS: fpu.h: Allow 64-bit FPU on a 64-bit MIPS R6 CPU\n\ncommit fcc53b5f6c38acbf5d311ffc3e0da517491c6f7b upstream.\n\nCommit 6134d94923d0 (\"MIPS: asm: fpu: Allow 64-bit FPU on MIPS32 R6\")\nadded support for 64-bit FPU on a 32-bit MIPS R6 processor but it missed\nthe 64-bit CPU case leading to FPU failures when requesting FR=1 mode\n(which is always the case for MIPS R6 userland) when running a 32-bit\nkernel on a 64-bit CPU. We also fix the MIPS R2 case.\n\nSigned-off-by: Markos Chandras <markos.chandras@imgtec.com>\nFixes: 6134d94923d0 (\"MIPS: asm: fpu: Allow 64-bit FPU on MIPS32 R6\")\nReviewed-by: Paul Burton <paul.burton@imgtec.com>\nCc: linux-mips@linux-mips.org\nPatchwork: https://patchwork.linux-mips.org/patch/10734/\nSigned-off-by: Ralf Baechle <ralf@linux-mips.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/cea0f568222b53b21242c50445776fccd4a1b8b8"},{"sha":"153fa24b8f6763c51915c59feed10dad045bd880","author":{"email":"06a38fb2ed1a2d0a17f4f06761ac2e5ace5a31ab@hartkopp.net","name":"Oliver Hartkopp"},"message":"can: replace timestamp as unique skb attribute\n\ncommit d3b58c47d330de8c29898fe9746f7530408f8a59 upstream.\n\nCommit 514ac99c64b \"can: fix multiple delivery of a single CAN frame for\noverlapping CAN filters\" requires the skb->tstamp to be set to check for\nidentical CAN skbs.\n\nWithout timestamping to be required by user space applications this timestamp\nwas not generated which lead to commit 36c01245eb8 \"can: fix loss of CAN frames\nin raw_rcv\" - which forces the timestamp to be set in all CAN related skbuffs\nby introducing several __net_timestamp() calls.\n\nThis forces e.g. out of tree drivers which are not using alloc_can{,fd}_skb()\nto add __net_timestamp() after skbuff creation to prevent the frame loss fixed\nin mainline Linux.\n\nThis patch removes the timestamp dependency and uses an atomic counter to\ncreate an unique identifier together with the skbuff pointer.\n\nBtw: the new skbcnt element introduced in struct can_skb_priv has to be\ninitialized with zero in out-of-tree drivers which are not using\nalloc_can{,fd}_skb() too.\n\nSigned-off-by: Oliver Hartkopp <socketcan@hartkopp.net>\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/zen-kernel/zen-kernel/commits/153fa24b8f6763c51915c59feed10dad045bd880"},{"sha":"78574b4bdc49fb0d7d5d3218beb069d259b2b631","author":{"email":"d8c69075be49b0738b690ec4af0e9025b8c97c9e@cogentembedded.com","name":"Sergei Shtylyov"},"message":"can: rcar_can: fix IRQ check\n\ncommit 5e63e6baa159fa8c787cf783dbf3d77fbea97331 upstream.\n\nrcar_can_probe() regards 0 as a wrong IRQ #, despite platform_get_irq() that it\ncalls returns negative error code in that case. This leads to the following\nbeing printed to the console when attempting to open the device:\n\nerror requesting interrupt fffffffa\n\nbecause  rcar_can_open() calls request_irq() with a negative IRQ #, and that\nfunction naturally fails with -EINVAL.\n\nCheck for the negative error codes instead and propagate them upstream instead\nof just returning -ENODEV.\n\nFixes: fd1159318e55 (\"can: add Renesas R-Car CAN driver\")\nSigned-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>\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/zen-kernel/zen-kernel/commits/78574b4bdc49fb0d7d5d3218beb069d259b2b631"},{"sha":"436eacc4992c0b51ebea61a8a7ac81807f44eb6e","author":{"email":"6d70bf1860a04c01a8a418747624f76785b0ab76@garmin.com","name":"J.D. Schroeder"},"message":"can: c_can: Fix default pinmux glitch at init\n\ncommit 033365191136c97f88c81b7bd0011414db28bb4e upstream.\n\nThe previous change 3973c526ae9c (net: can: c_can: Disable pins when CAN\ninterface is down) causes a slight glitch on the pinctrl settings when used.\nSince commit ab78029 (drivers/pinctrl: grab default handles from device core),\nthe device core will automatically set the default pins. This causes the pins\nto be momentarily set to the default and then to the sleep state in\nregister_c_can_dev(). By adding an optional \"enable\" state, boards can set the\ndefault pin state to be disabled and avoid the glitch when the switch from\ndefault to sleep first occurs. If the \"enable\" state is not available\nc_can_pinctrl_select_state() falls back to using the \"default\" pinctrl state.\n\n[Roger Q] - Forward port to v4.2 and use pinctrl_get_select().\n\nSigned-off-by: J.D. Schroeder <jay.schroeder@garmin.com>\nSigned-off-by: Roger Quadros <rogerq@ti.com>\nReviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>\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/zen-kernel/zen-kernel/commits/436eacc4992c0b51ebea61a8a7ac81807f44eb6e"},{"sha":"23596d7deb0401e36aef49e96d252d8095cdff79","author":{"email":"d8c69075be49b0738b690ec4af0e9025b8c97c9e@cogentembedded.com","name":"Sergei Shtylyov"},"message":"can: rcar_can: print signed IRQ #\n\ncommit c1a4c87b06fa564d6e2760a12d4e5a09badc684b upstream.\n\nPrinting IRQ # using \"%x\" and \"%u\" unsigned formats isn't quite correct as\n'ndev->irq' is of  type *int*, so  the \"%d\" format  needs to be used instead.\n\nWhile fixing this, beautify the dev_info() message in rcar_can_probe() a bit.\n\nFixes: fd1159318e55 (\"can: add Renesas R-Car CAN driver\")\nSigned-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>\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/zen-kernel/zen-kernel/commits/23596d7deb0401e36aef49e96d252d8095cdff79"},{"sha":"8a5d1e374b59ffaf10bd64c319cdca7560d49c4c","author":{"email":"eb0877843acc39f8ef6f7269937dee931c372d23@agner.ch","name":"Stefan Agner"},"message":"can: mcp251x: fix resume when device is down\n\ncommit 25b401c1816ae64bcc5dcb1d39ab41812522a0ce upstream.\n\nIf a valid power regulator or a dummy regulator is used (which\nhappens to be the case when no regulator is specified), restart_work\nis queued no matter whether the device was running or not at suspend\ntime. Since work queues get initialized in the ndo_open callback,\nresuming leads to a NULL pointer exception.\n\nReverse exactly the steps executed at suspend time:\n- Enable the power regulator in any case\n- Enable the transceiver regulator if the device was running, even in\n  case we have a power regulator\n- Queue restart_work only in case the device was running\n\nFixes: bf66f3736a94 (\"can: mcp251x: Move to threaded interrupts instead of workqueues.\")\nSigned-off-by: Stefan Agner <stefan@agner.ch>\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/zen-kernel/zen-kernel/commits/8a5d1e374b59ffaf10bd64c319cdca7560d49c4c"}]}