{"push_id":700887995,"size":1000,"distinct_size":0,"ref":"refs/heads/linux-next/akpm","head":"95bc0492c9bed4e47a942faea6b2293496d1ad51","before":"f7303b2387bf4da7915e4905e7f8d0d95a531a7d","commits":[{"sha":"e0dd268a2c983acf2b52130b489b3b5724e26b39","author":{"email":"181323dd666a182bc2d953e52d0ac3ab54cd8391@pengutronix.de","name":"Uwe Kleine-König"},"message":"leds: aat1290: pass flags parameter to devm_gpiod_get\n\nSince 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)\nwhich appeared in v3.17-rc1, the gpiod_get* functions take an additional\nparameter that allows to specify direction and initial value for output.\n\nIn this case the driver cannot easily be simplified but as the flags\nparameter will become mandatory soon this change is necessary\nbeforehand.\n\nSigned-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>\nAcked-by: Jacek Anaszewski <j.anaszewski@samsung.com>\nSigned-off-by: Bryan Wu <cooloney@gmail.com>","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/e0dd268a2c983acf2b52130b489b3b5724e26b39"},{"sha":"ee2aad42e4b6eaa9721196f07f7d5d8d049e6530","author":{"email":"09a735f7eb72c187e2a850d6e35405365edf772e@cavium.com","name":"Robert Richter"},"message":"ahci: Add generic MSI-X support for single interrupts to SATA PCI driver\n\nThis patch adds generic MSI-X support for single interrupts to the\nSATA PCI driver. MSI-X support is needed for host controller that only\nhave MSI-X support implemented, but no MSI or intx. This patch only\nadds support for single interrupts, multiple per-port MSI-X interrupts\nare not yet implemented.\n\nThe new implementation still initializes MSIs first. Only if that\nfails, the code tries to enable MSI-X. If that fails too, setup is\ncontinued with intx interrupts.\n\nTo not break other chips by this generic code change, there are the\nfollowing precautions:\n\n * Interrupt ranges are not enabled at all.\n\n * Only single interrupt mode is enabled for msix cap devices. Thus,\n   only one interrupt will be setup.\n\n * During the discussion with Tejun we agreed to change the init\n   sequence from msix-msi-intx to msi-msix-intx. Thus, if a device\n   offers msi and init does not fail, the msix init code will not be\n   executed. This is equivalent to current code.\n\nWith this, the code only setups single mode msix as a last resort if\nmsi fails. No interrupt range is enabled at all. Only one interrupt\nwill be enabled.\n\ntj: comment edits.\n\nChanges of the patch series:\n\nv5:\n * updated patch subject that the patch only implements single IRQ\n * moved Cavium specific code to a separate patch\n * detect Cavium ThunderX device with PCI_CLASS_STORAGE_SATA_AHCI\n   instead of vendor/dev id\n * added more comments to the code\n * enable single msix support for all kind of devices (removing strict\n   check)\n * rebased onto update libata/for-4.2 with patch 1, 2 applied\n\nv4:\n * removed implementation of ahci_init_intx()\n * improved patch descriptions\n * rebased onto libata/for-4.2\n\nv3:\n * store irq number in struct ahci_host_priv\n * change initialization order from msix-msi-intx to msi-msix-intx\n * improve comments in ahci_init_msix()\n * improve error message in ahci_init_msix()\n * do not enable MSI-X if MSI is actively disabled for the device\n\nv2:\n * determine irq vector from pci_dev->msi_list\n\nBased on a patch from Sunil Goutham <sgoutham@cavium.com>.\n\nSigned-off-by: Robert Richter <rrichter@cavium.com>\nSigned-off-by: Tejun Heo <tj@kernel.org>","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/ee2aad42e4b6eaa9721196f07f7d5d8d049e6530"},{"sha":"b7ae128d728c42583dac9db48dce9a44bc0fb900","author":{"email":"09a735f7eb72c187e2a850d6e35405365edf772e@cavium.com","name":"Robert Richter"},"message":"ahci: Add support for Cavium's ThunderX host controller\n\nThis patch adds support for Cavium's ThunderX host controller. The\ncontroller resides on the SoC and is a AHCI compatible SATA controller\nwith one port, compliant with Serial ATA 3.1 and AHCI Revision 1.31.\nThere can exists multiple SATA controllers on the SoC.\n\nThe controller depends on MSI-X support since the PCI ECAM controller\non the SoC does not implement MSI nor lagacy intx interrupt support.\nThus, during device initialization, if MSI fails MSI-X will be used to\nenable the device's interrupts.\n\nThe controller uses non-standard BAR0 for its register range. The\nalready existing device lookup (vendor and device id) that is already\nimplemented for other host controllers is used to change the PCI BAR.\n\nSigned-off-by: Robert Richter <rrichter@cavium.com>\nSigned-off-by: Tejun Heo <tj@kernel.org>","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/b7ae128d728c42583dac9db48dce9a44bc0fb900"},{"sha":"9253987d5eac59f82cc419c8d8b90ae09313b582","author":{"email":"546b05909706652891a87f7bfe385ae147f61f91@kernel.org","name":"Tejun Heo"},"message":"Merge branch 'for-4.2' into for-next","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/9253987d5eac59f82cc419c8d8b90ae09313b582"},{"sha":"ba8d134e75deb1904b146a4decb0bc6a217333cd","author":{"email":"50c3c575ce2bb12c45e20736ce59e86fe81915b4@ti.com","name":"Nishanth Menon"},"message":"rtc: ds1307: Enable the mcp794xx alarm after programming time\n\nAlarm interrupt enable register is at offset 0x7, while the time\nregisters for the alarm follow that. When we program Alarm interrupt\nenable prior to programming the time, it is possible that previous\ntime value could be close or match at the time of alarm enable\nresulting in interrupt trigger which is unexpected (and does not match\nthe time we expect it to trigger).\n\nTo prevent this scenario from occuring, program the ALM0_EN bit only\nafter the alarm time is appropriately programmed.\n\nOfcourse, I2C programming is non-atomic, so there are loopholes where\nthe interrupt wont trigger if the time requested is in the past at\nthe time of programming the ALM0_EN bit. However, we will not have\nunexpected interrupts while the time is programmed after the interrupt\nare enabled.\n\nSigned-off-by: Nishanth Menon <nm@ti.com>\nReviewed-by: Grygorii Strashko <grygorii.strashko@linaro.org>\nSigned-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/ba8d134e75deb1904b146a4decb0bc6a217333cd"},{"sha":"5dc75a07f884c2a1704aa7fdad640026c85290b5","author":{"email":"f2c659f01951776204a6c5b902787d9019fbeebd@arndb.de","name":"Arnd Bergmann"},"message":"rtc: pfc8563: fix uninitialized variable warning\n\nGcc is unable to prove that alm_pending is always initialized\nwhen it is used, so it prints a harmless warning:\n\ndrivers/rtc/rtc-pcf8563.c: In function 'pcf8563_probe':\ndrivers/rtc/rtc-pcf8563.c:449:5: warning: 'alm_pending' may be used uninitialized in this function [-Wmaybe-uninitialized]\n\nThis uses the same conditional expression that is used inside of\nthe pcf8563_get_alarm_mode() function, to help gcc figure it out\nand shut up that warning, and make the ARM defconfigs build again\nwith no warnings.\n\nSigned-off-by: Arnd Bergmann <arnd@arndb.de>\nFixes: a45d528aab8b (\"rtc: pcf8563: clear expired alarm at boot time\")\nSigned-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/5dc75a07f884c2a1704aa7fdad640026c85290b5"},{"sha":"7180dddf7c32c49975c7e7babf2b60ed450cb760","author":{"email":"fe4655370dc87a32329d591d6e8472329333dfad@redhat.com","name":"Prarit Bhargava"},"message":"intel_pstate: Fix overflow in busy_scaled due to long delay\n\nThe kernel may delay interrupts for a long time which can result in timers\nbeing delayed. If this occurs the intel_pstate driver will crash with a\ndivide by zero error:\n\ndivide error: 0000 [#1] SMP\nModules linked in: btrfs zlib_deflate raid6_pq xor msdos ext4 mbcache jbd2 binfmt_misc arc4 md4 nls_utf8 cifs dns_resolver tcp_lp bnep bluetooth rfkill fuse dm_service_time iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ftp ip6t_rpfilter ip6t_REJECT ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter ip_tables intel_powerclamp coretemp vfat fat kvm_intel iTCO_wdt iTCO_vendor_support ipmi_devintf sr_mod kvm crct10dif_pclmul\n crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel cdc_ether lrw usbnet cdrom mii gf128mul glue_helper ablk_helper cryptd lpc_ich mfd_core pcspkr sb_edac edac_core ipmi_si ipmi_msghandler ioatdma wmi shpchp acpi_pad nfsd auth_rpcgss nfs_acl lockd uinput dm_multipath sunrpc xfs libcrc32c usb_storage sd_mod crc_t10dif crct10dif_common ixgbe mgag200 syscopyarea sysfillrect sysimgblt mdio drm_kms_helper ttm igb drm ptp pps_core dca i2c_algo_bit megaraid_sas i2c_core dm_mirror dm_region_hash dm_log dm_mod\nCPU: 113 PID: 0 Comm: swapper/113 Tainted: G        W   --------------   3.10.0-229.1.2.el7.x86_64 #1\nHardware name: IBM x3950 X6 -[3837AC2]-/00FN827, BIOS -[A8E112BUS-1.00]- 08/27/2014\ntask: ffff880fe8abe660 ti: ffff880fe8ae4000 task.ti: ffff880fe8ae4000\nRIP: 0010:[<ffffffff814a9279>]  [<ffffffff814a9279>] intel_pstate_timer_func+0x179/0x3d0\nRSP: 0018:ffff883fff4e3db8  EFLAGS: 00010206\nRAX: 0000000027100000 RBX: ffff883fe6965100 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000010 RDI: 000000002e53632d\nRBP: ffff883fff4e3e20 R08: 000e6f69a5a125c0 R09: ffff883fe84ec001\nR10: 0000000000000002 R11: 0000000000000005 R12: 00000000000049f5\nR13: 0000000000271000 R14: 00000000000049f5 R15: 0000000000000246\nFS:  0000000000000000(0000) GS:ffff883fff4e0000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7668601000 CR3: 000000000190a000 CR4: 00000000001407e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400\nStack:\n ffff883fff4e3e58 ffffffff81099dc1 0000000000000086 0000000000000071\n ffff883fff4f3680 0000000000000071 fbdc8a965e33afee ffffffff810b69dd\n ffff883fe84ec000 ffff883fe6965108 0000000000000100 ffffffff814a9100\nCall Trace:\n <IRQ>\n\n [<ffffffff81099dc1>] ? run_posix_cpu_timers+0x51/0x840\n [<ffffffff810b69dd>] ? trigger_load_balance+0x5d/0x200\n [<ffffffff814a9100>] ? pid_param_set+0x130/0x130\n [<ffffffff8107df56>] call_timer_fn+0x36/0x110\n [<ffffffff814a9100>] ? pid_param_set+0x130/0x130\n [<ffffffff8107fdcf>] run_timer_softirq+0x21f/0x320\n [<ffffffff81077b2f>] __do_softirq+0xef/0x280\n [<ffffffff816156dc>] call_softirq+0x1c/0x30\n [<ffffffff81015d95>] do_softirq+0x65/0xa0\n [<ffffffff81077ec5>] irq_exit+0x115/0x120\n [<ffffffff81616355>] smp_apic_timer_interrupt+0x45/0x60\n [<ffffffff81614a1d>] apic_timer_interrupt+0x6d/0x80\n <EOI>\n\n [<ffffffff814a9c32>] ? cpuidle_enter_state+0x52/0xc0\n [<ffffffff814a9c28>] ? cpuidle_enter_state+0x48/0xc0\n [<ffffffff814a9d65>] cpuidle_idle_call+0xc5/0x200\n [<ffffffff8101d14e>] arch_cpu_idle+0xe/0x30\n [<ffffffff810c67c1>] cpu_startup_entry+0xf1/0x290\n [<ffffffff8104228a>] start_secondary+0x1ba/0x230\nCode: 42 0f 00 45 89 e6 48 01 c2 43 8d 44 6d 00 39 d0 73 26 49 c1 e5 08 89 d2 4d 63 f4 49 63 c5 48 c1 e2 08 48 c1 e0 08 48 63 ca 48 99 <48> f7 f9 48 98 4c 0f af f0 49 c1 ee 08 8b 43 78 c1 e0 08 44 29\nRIP  [<ffffffff814a9279>] intel_pstate_timer_func+0x179/0x3d0\n RSP <ffff883fff4e3db8>\n\nThe kernel values for cpudata for CPU 113 were:\n\nstruct cpudata {\n  cpu = 113,\n  timer = {\n    entry = {\n      next = 0x0,\n      prev = 0xdead000000200200\n    },\n    expires = 8357799745,\n    base = 0xffff883fe84ec001,\n    function = 0xffffffff814a9100 <intel_pstate_timer_func>,\n    data = 18446612406765768960,\n<snip>\n    i_gain = 0,\n    d_gain = 0,\n    deadband = 0,\n    last_err = 22489\n  },\n  last_sample_time = {\n    tv64 = 4063132438017305\n  },\n  prev_aperf = 287326796397463,\n  prev_mperf = 251427432090198,\n  sample = {\n    core_pct_busy = 23081,\n    aperf = 2937407,\n    mperf = 3257884,\n    freq = 2524484,\n    time = {\n      tv64 = 4063149215234118\n    }\n  }\n}\n\nwhich results in the time between samples = last_sample_time - sample.time\n= 4063149215234118 - 4063132438017305 = 16777216813 which is 16.777 seconds.\n\nThe duration between reads of the APERF and MPERF registers overflowed a s32\nsized integer in intel_pstate_get_scaled_busy()'s call to div_fp().  The result\nis that int_tofp(duration_us) == 0, and the kernel attempts to divide by 0.\n\nWhile the kernel shouldn't be delaying for a long time, it can and does\nhappen and the intel_pstate driver should not panic in this situation.  This\npatch changes the div_fp() function to use div64_s64() to allow for \"long\"\ndivision.  This will avoid the overflow condition on long delays.\n\n[v2]: use div64_s64() in div_fp()\n\nSigned-off-by: Prarit Bhargava <prarit@redhat.com>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/7180dddf7c32c49975c7e7babf2b60ed450cb760"},{"sha":"84e3b420420e78babb5a981a91943f59bd156f21","author":{"email":"3efd2a027b14fd890cd23a9ef6d1134b4e5ad850@skynet.be","name":"Fabian Frederick"},"message":"tpm_ibmvtpm: remove unneccessary message level.\n\nKERN_ERR is implicitely declared in pr_err()\n\nSigned-off-by: Fabian Frederick <fabf@skynet.be>\nSigned-off-by: Peter Huewe <peterhuewe@gmx.de>","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/84e3b420420e78babb5a981a91943f59bd156f21"},{"sha":"9d75f08946e8485109458ccf16f714697c207f41","author":{"email":"586dce2b5b41882e50b9a0eefaf3387b8b8c8cc6@linux.vnet.ibm.com","name":"Hon Ching \\(Vicky\\) Lo"},"message":"vTPM: set virtual device before passing to ibmvtpm_reset_crq\n\ntpm_ibmvtpm_probe() calls ibmvtpm_reset_crq(ibmvtpm) without having yet\nset the virtual device in the ibmvtpm structure. So in ibmvtpm_reset_crq,\nthe phype call contains empty unit addresses, ibmvtpm->vdev->unit_address.\n\nSigned-off-by: Hon Ching(Vicky) Lo <honclo@linux.vnet.ibm.com>\nSigned-off-by: Joy Latten <jmlatten@linux.vnet.ibm.com>\nReviewed-by: Ashley Lai <ashley@ahsleylai.com>\nCc: <stable@vger.kernel.org>\nFixes: 132f76294744 (\"drivers/char/tpm: Add new device driver to support IBM vTPM\")\nSigned-off-by: Peter Huewe <peterhuewe@gmx.de>","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/9d75f08946e8485109458ccf16f714697c207f41"},{"sha":"49afd7289bd937401c5f7faa193054bc3c41dad6","author":{"email":"6e0a3da6445cd298bc4a6b3aaa269075849c9510@linux.intel.com","name":"Jarkko Sakkinen"},"message":"tpm, tpm_crb: fix le64_to_cpu conversions in crb_acpi_add()\n\nle64_to_cpu() was applied twice to the physical addresses read from the\ncontrol area. This hasn't shown any visible regressions because CRB\ndriver has been tested only on the little endian platofrms so far.\n\nReported-by: Matt Fleming <matt.fleming@intel.com>\nSigned-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>\nReviewed-By: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>\nCc: <stable@vger.kernel.org>\nFixes: 30fc8d138e91 (\"tpm: TPM 2.0 CRB Interface\")\nSigned-off-by: Peter Huewe <peterhuewe@gmx.de>","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/49afd7289bd937401c5f7faa193054bc3c41dad6"},{"sha":"99c805f4c2912a8cbdb4659de24e1a14bd498ae3","author":{"email":"af0edbfd86cb4475cb78945d4335593dfc15eead@unisys.com","name":"David Kershner"},"message":"staging: unisys: s-Par video channel includes EFI framebuffer\n\nThe efi framebuffer is defined within the s-Par video channel\nconsole. Before we get the device create message for the video\nconsole, s-Par has alreaady informed linux about the efi\nframebuffer and a memory region is already set up for it. Since\nwe do not use the video channel in linux, we are just ignoring\nthe failure of the video channel request_mem_region.\n\nTesting: This patch was tested on top of s-Par and we no longer\nleave the partition in a failed state.\n\nSigned-off-by: David Kershner <david.kershner@unisys.com>\nSigned-off-by: Benjamin Romer <benjamin.romer@unisys.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/99c805f4c2912a8cbdb4659de24e1a14bd498ae3"},{"sha":"39630ee2a37e57cc8dfa3cf5a55f8249d6e883bc","author":{"email":"af0edbfd86cb4475cb78945d4335593dfc15eead@unisys.com","name":"David Kershner"},"message":"staging: unisys: Remove visorchannel stub\n\nVisorchannel directory has been stripped down to almost nothing, and is\nno longer referenced. This finishes getting rid of the directory.\n\nSigned-off-by: David Kershner <david.kershner@unisys.com>\nSigned-off-by: Benjamin Romer <benjamin.romer@unisys.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/39630ee2a37e57cc8dfa3cf5a55f8249d6e883bc"},{"sha":"dbb9d619941ad57dbe3c6667764e1eccd5ee5f1b","author":{"email":"af0edbfd86cb4475cb78945d4335593dfc15eead@unisys.com","name":"David Kershner"},"message":"staging: unisys: define structures outside of iochannel\n\nDuring testing with visornic the offset of num_rcv_bufs\nwas being reported at 188 instead of 186. The vnic structure\nstarts at 180 and the macaddr is only 6 bytes long.\n\nWhen I defined and packed the structures outside of the struct\nand then referenced them in the struct the correct offset\nwas generated.\n\nSigned-off-by: David Kershner <david.kershner@unisys.com>\nSigned-off-by: Benjamin Romer <benjamin.romer@unisys.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/dbb9d619941ad57dbe3c6667764e1eccd5ee5f1b"},{"sha":"68905a14e49c97bf49dacd753e40ddd5b254e2ad","author":{"email":"af0edbfd86cb4475cb78945d4335593dfc15eead@unisys.com","name":"David Kershner"},"message":"staging: unisys: Add s-Par visornic ethernet driver\n\nThis driver creates a network device when s-Par sends a device\ncreate message to create network adapter on the visorbus. When\nthe message is received by visorbus, the visornic_probe function\nis called and the netdev device is created and managed by the\nvisornic driver.\n\nSigned-off-by: David Kershner <david.kershner@unisys.com>\nSigned-off-by: Benjamin Romer <benjamin.romer@unisys.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/68905a14e49c97bf49dacd753e40ddd5b254e2ad"},{"sha":"56df900cb44d18c3ffaf16e09b83aaf37d912cc5","author":{"email":"0e1e349bdba396f044a06b01fef702e072aa66d3@redhat.com","name":"Jes Sorensen"},"message":"staging: unisys: visorchannel_write() fix potential memory corruption\n\nThis fixes the memory corruption case, if nbytes is less than offset\nand sizeof(struct channel_header)\n\nReported-by: Dan Carpenter <dan.carpenter@oracle.com>\nSigned-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>\nSigned-off-by: Benjamin Romer <benjamin.romer@unisys.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/56df900cb44d18c3ffaf16e09b83aaf37d912cc5"},{"sha":"10e87dc42a086c256b25334b6c1c89214feba9a7","author":{"email":"57a481231be484a54bdf722d34ac63f2f3b8feeb@synaptics.com","name":"Andrew Duggan"},"message":"HID: rmi: Disable populating F30 when the touchpad has physical buttons\n\nPhysical buttons do not use F30 to report their state and in some cases the\ndata reported in F30 is incorrect and inconsistent with what is reported by\nthe HID descriptor. When physical buttons are present, ignore F30 and let\nhid-input report buttons based on what is defined in the HID descriptor.\n\nSigned-off-by: Andrew Duggan <aduggan@synaptics.com>\nReviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>\nSigned-off-by: Jiri Kosina <jkosina@suse.cz>","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/10e87dc42a086c256b25334b6c1c89214feba9a7"},{"sha":"92206f554f9cda4b28487d8468a5f93bfbebced8","author":{"email":"ed58f755cc8caaf10c3e8c731a8b86fb8f13d6cb@suse.cz","name":"Jiri Kosina"},"message":"Merge branch 'for-4.2/rmi' into for-next","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/92206f554f9cda4b28487d8468a5f93bfbebced8"},{"sha":"5235552273e6b68abbed3b3047af6344e2e60c2c","author":{"email":"49a5ed162141aa1a2ad45c2f70540ac844521912@ens-lyon.org","name":"Samuel Thibault"},"message":"tty/vt/keyboard: define LED triggers for VT LED states\n\nNow that input core allows controlling keyboards LEDs via standard LED\nsubsystem triggers let's switch VT keyboard code to make use of this\nfeature. We will define the following standard triggers: \"kbd-scrollock\",\n\"kbd-numlock\", \"kbd-capslock\", and \"kbd-kanalock\" which are default\ntriggers for respective LEDs on keyboards.\n\nSigned-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>\nTested-by: Pavel Machek <pavel@ucw.cz>\nAcked-by: Pavel Machek <pavel@ucw.cz>\nSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/5235552273e6b68abbed3b3047af6344e2e60c2c"},{"sha":"eeb64c14275e52740d6410632e62e0ad9b88ca70","author":{"email":"49a5ed162141aa1a2ad45c2f70540ac844521912@ens-lyon.org","name":"Samuel Thibault"},"message":"tty/vt/keyboard: define LED triggers for VT keyboard lock states\n\nIn addition to defining triggers for VT LED states, let's define triggers\nfor VT keyboard lock states, such as \"kbd-shiftlock\", \"kbd-altgrlock\", etc.\n\nThis permits to fix #7063 from userland by using a modifier to implement\nproper CapsLock behavior and have the keyboard caps lock led show that\nmodifier state.\n\nSigned-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>\nTested-by: Pavel Machek <pavel@ucw.cz>\nAcked-by: Pavel Machek <pavel@ucw.cz>\nSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/eeb64c14275e52740d6410632e62e0ad9b88ca70"},{"sha":"3609d819a36c65857816ca1278d80767d6d9b990","author":{"email":"fac76aafe57fc9acb24e05f5dba9b58a43a0a645@linux.vnet.ibm.com","name":"Shreyas B. Prabhu"},"message":"powerpc: Make doorbell check preemption safe\n\nDoorbell can be used to cause ipi on cpus which are sibling threads on\nthe same core. So icp_native_cause_ipi checks if the destination cpu\nis a sibling thread of the current cpu and uses doorbell in such cases.\n\nBut while running with CONFIG_PREEMPT=y, since this section is\npreemtible, we can run into issues if after we check if the destination\ncpu is a sibling cpu, the task gets migrated from a sibling cpu to a\ncpu on another core.\n\nFix this by using get_cpu()/ put_cpu()\n\nSigned-off-by: Shreyas B. Prabhu <shreyas@linux.vnet.ibm.com>\nSigned-off-by: Michael Neuling <mikey@neuling.org>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":false,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/3609d819a36c65857816ca1278d80767d6d9b990"}]}