- 20 Jun, 2018 40 commits
-
-
Arnd Bergmann authored
[ Upstream commit a57ab96e ] We already have memcpy_toio(), but not memset_io(), so let's add the obvious version to allow building an allmodconfig kernel without errors like drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_move_memcpy': drivers/gpu/drm/ttm/ttm_bo_util.c:390:3: error: implicit declaration of function 'memset_io' [-Werror=implicit-function-declaration] Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Richard Kuo <rkuo@codeaurora.org> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Nick Dyer authored
[ Upstream commit 068bdb67 ] The automatic update mechanism will trigger an update if the info block CRCs are different between maxtouch configuration file (maxtouch.cfg) and chip. The driver compared the CRCs without retrieving the chip CRC, resulting always in a failure and firmware flashing action triggered. Fix this issue by retrieving the chip info block CRC before the check. Note that this solution has the benefit that by reading the information block and the object table into a contiguous region of memory, we can verify the checksum at probe time. This means we make sure that we are indeed talking to a chip that supports object protocol correctly. Using this patch on a kevin chromebook, the touchscreen and touchpad drivers are able to match the CRC: atmel_mxt_ts 3-004b: Family: 164 Variant: 14 Firmware V2.3.AA Objects: 40 atmel_mxt_ts 5-004a: Family: 164 Variant: 17 Firmware V2.0.AA Objects: 31 atmel_mxt_ts 3-004b: Resetting device atmel_mxt_ts 5-004a: Resetting device atmel_mxt_ts 3-004b: Config CRC 0x573E89: OK atmel_mxt_ts 3-004b: Touchscreen size X4095Y2729 input: Atmel maXTouch Touchscreen as /devices/platform/ff130000.i2c/i2c-3/3-004b/input/input5 atmel_mxt_ts 5-004a: Config CRC 0x0AF6BA: OK atmel_mxt_ts 5-004a: Touchscreen size X1920Y1080 input: Atmel maXTouch Touchpad as /devices/platform/ff140000.i2c/i2c-5/5-004a/input/input6 Signed-off-by:
Nick Dyer <nick.dyer@shmanahar.org> Acked-by:
Benson Leung <bleung@chromium.org> [Ezequiel: minor patch massage] Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Tested-by:
Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Adam Ford authored
[ Upstream commit 95e59fc3 ] The Audio has worked, but the mute pin has a weak pulldown which alows some of the audio signal to pass very quietly. This patch fixes that so the mute pin is actively driven high for mute or low for normal operation. Fixes: ab8dd3ae ("ARM: DTS: Add minimal Support for Logic PD DM3730 SOM-LV") Signed-off-by:
Adam Ford <aford173@gmail.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Adam Ford authored
[ Upstream commit 189822cb ] The VAUX3 rail from the PMIC powers a clock driver which clocks the WL127x. This corrects a bug which did not correctly associate the vin-supply with the proper power rail. This also fixes a typo in the pinmuxing to properly configure the interrupt pin. Fixes: ab8dd3ae ("ARM: DTS: Add minimal Support for Logic PD DM3730 SOM-LV") Signed-off-by:
-
Tero Kristo authored
[ Upstream commit 33e95724 ] smp_processor_id() checks preemption if CONFIG_DEBUG_PREEMPT is enabled, causing a warning dump during boot: [ 5.042377] BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 [ 5.050281] caller is pwrdm_set_next_pwrst+0x48/0x88 [ 5.055330] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.14.24-g57341df0b4 #1 Use the raw_smp_processor_id() for the trace instead, this value does not need to be perfectly correct. The alternative of disabling preempt is too heavy weight operation to be applied in PM hot path for just tracing purposes. Signed-off-by:
Tero Kristo <t-kristo@ti.com> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit f1303070 ] Fixes: 14da3ed8 ("devicetree/bindings: display: Document common panel properties") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Sekhar Nori authored
[ Upstream commit 5c054de2 ] Since commit 09f3756b ("dm9000: Return an ERR_PTR() in all error conditions of dm9000_parse_dt()"), passing either non-NULL platform data or device-tree for dm9000 driver to probe is mandatory. DM335 board was using none, so networking failed to initialize. Fix it by passing non-NULL (but empty) platform data. Fixes: 09f3756b ("dm9000: Return an ERR_PTR() in all error conditions of dm9000_parse_dt()") Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
-
Sekhar Nori authored
[ Upstream commit d45622c0 ] commit c4dc56be ("ARM: davinci: fix the GPIO lookup for omapl138-hawk") fixed the GPIO chip name for look-up of MMC/SD CD and WP pins, but forgot to change the GPIO numbers passed. The GPIO numbers are not offsets from within a 32 GPIO bank. Fix the GPIO numbers as well as remove the misleading comment. Fixes: c4dc56be ("ARM: davinci: fix the GPIO lookup for omapl138-hawk") Reviewed-by:
David Lechner <david@lechnology.com> Signed-off-by:
-
Sekhar Nori authored
[ Upstream commit 67c6b6ff ] The GPIO chip is called davinci_gpio.0 in legacy mode. Fix it, so that mmc can correctly lookup the wp and cp gpios. Also fix the GPIO numbers as they are not offsets within a bank. Note that it is the gpio-davinci driver that sets the gpiochip label to davinci_gpio.0. Fixes: bdf0e836 ("ARM: davinci: da850-evm: use gpio descriptor for mmc pins") Reviewed-by:
-
Sekhar Nori authored
[ Upstream commit 51e9f121 ] The GPIO chip is called davinci_gpio.0 in legacy mode. Fix it, so that mmc can correctly lookup the wp and cp gpios. Also fix the GPIO numbers as they are not offsets within a bank. Note that it is the gpio-davinci driver that sets the gpiochip label to davinci_gpio.0. Fixes: b5e1438c ("ARM: davinci: da830-evm: use gpio descriptor for mmc pins") Reported-by:
-
Håkon Bugge authored
[ Upstream commit db82476f ] Currently, the kernel protects access to the agent ID allocator on a per port basis using a spinlock, so it is impossible for two apps/threads on the same port to get the same TID, but it is entirely possible for two threads on different ports to end up with the same TID. As this can be confusing (regardless of it being legal according to the IB Spec 1.3, C13-18.1.1, in section 13.4.6.4 - TransactionID usage), and as the rdma-core user space API for /dev/umad devices implies unique TIDs even across ports, make the TID an atomic type so that no two allocations, regardless of port number, will be the same. Signed-off-by:
Håkon Bugge <haakon.bugge@oracle.com> Reviewed-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Reviewed-by:
Ira Weiny <ira.weiny@intel.com> Reviewed-by:
Zhu Yanjun <yanjun.zhu@oracle.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Amir Goldstein authored
[ Upstream commit 19b9ad67 ] The comment claims that this helper will try not to loose bits, but for 64bit long it looses the high bits before hashing 64bit long into 32bit int. Use the helper hash_long() to do the right thing for 64bit long. For 32bit long, there is no change. All the callers of end_name_hash() either assign the result to qstr->hash, which is u32 or return the result as an int value (e.g. full_name_hash()). Change the helper return type to int to conform to its users. [ It took me a while to apply this, because my initial reaction to it was - incorrectly - that it could make for slower code. After having looked more at it, I take back all my complaints about the patch, Amir was right and I was mis-reading things or just being stupid. I also don't worry too much about the possible performance impact of this on 64-bit, since most architectures that actually care about performance end up not using this very much (the dcache code is the most performance-critical, but the word-at-a-time case uses its own hashing anyway). So this ends up being mostly used for filesystems that do their own degraded hashing (usually because they want a case-insensitive comparison function). A _tiny_ worry remains, in that not everybody uses DCACHE_WORD_ACCESS, and then this potentially makes things more expensive on 64-bit architectures with slow or lacking multipliers even for the normal case. That said, realistically the only such architecture I can think of is PA-RISC. Nobody really cares about performance on that, it's more of a "look ma, I've got warts^W an odd machine" platform. So the patch is fine, and all my initial worries were just misplaced from not looking at this properly. - Linus ] Signed-off-by:
Amir Goldstein <amir73il@gmail.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Zhu Yanjun authored
[ Upstream commit 9fd4350b ] When skb is sent, it will pass the following functions in soft roce. rxe_send [rdma_rxe] ip_local_out __ip_local_out ip_output ip_finish_output ip_finish_output2 dev_queue_xmit __dev_queue_xmit dev_hard_start_xmit In the above functions, if error occurs in the above functions or iptables rules drop skb after ip_local_out, kfree_skb will be called. So it is not necessary to call kfree_skb in soft roce module again. Or else crash will occur. The steps to reproduce: server client --------- --------- |1.1.1.1|<----rxe-channel--->|1.1.1.2| --------- --------- On server: rping -s -a 1.1.1.1 -v -C 10000 -S 512 On client: rping -c -a 1.1.1.1 -v -C 10000 -S 512 The kernel configs CONFIG_DEBUG_KMEMLEAK and CONFIG_DEBUG_OBJECTS are enabled on both server and client. When rping runs, run the following command in server: iptables -I OUTPUT -p udp --dport 4791 -j DROP Without this patch, crash will occur. CC: Srinivas Eeda <srinivas.eeda@oracle.com> CC: Junxiao Bi <junxiao.bi@oracle.com> Signed-off-by:
Yuval Shaia <yuval.shaia@oracle.com> Signed-off-by:
-
Jianchao Wang authored
[ Upstream commit 2da36d44 ] w/o RXE_START_MASK, the last_psn of IB_OPCODE_RC_SEND_ONLY_INV will not be updated in update_wqe_psn, and the corresponding wqe will not be acked in rxe_completer due to its last_psn is zero. Finally, the other wqe will also not be able to be acked, because the wqe of IB_OPCODE_RC_SEND_ONLY_INV with last_psn 0 is still there. This causes large amount of io timeout when nvmeof is over rxe. Add RXE_START_MASK for IB_OPCODE_RC_SEND_ONLY_INV to fix this. Signed-off-by:
Jianchao Wang <jianchao.w.wang@oracle.com> Reviewed-by:
-
Colin Ian King authored
[ Upstream commit f96416ce ] In the cases where iwpm_hash_bucket is NULL and where function get_mapinfo_hash_bucket returns NULL then the map_info is never added to hash_bucket_head and hence there is a leak of map_info. Fix this by nullifying hash_bucket_head and if that is null we know that that map_info was not added to hash_bucket_head and hence map_info should be free'd. Detected by CoverityScan, CID#1222481 ("Resource Leak") Fixes: 30dc5e63 ("RDMA/core: Add support for iWARP Port Mapper user space service") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Parav Pandit authored
[ Upstream commit 2918c1a9 ] There are few issues with validation of netdevice and listen id lookup for IB (IPoIB) while processing incoming CM request as below. 1. While performing lookup of bind_list in cma_ps_find(), net namespace of the netdevice can get deleted in cma_exit_net(), resulting in use after free access of idr and/or net namespace structures. This lookup occurs from the workqueue context (and not userspace context where net namespace is always valid). CPU0 CPU1 ==== ==== bind_list = cma_ps_find(); move netdevice to new namespace delete net namespace cma_exit_net() idr_destroy(idr); [..] cma_find_listener(bind_list, ..); 2. While netdevice is validated for IP address in given net namespace, netdevice's net namespace and/or ifindex can change in cma_get_net_dev() and cma_match_net_dev(). Above issues are overcome by using rcu lock along with netdevice UP/DOWN state as described below. When a net namespace is getting deleted, netdevice is closed and shutdown before moving it back to init_net namespace. change_net_namespace() synchronizes with any existing use of netdevice before changing the netdev properties such as net or ifindex. Once netdevice IFF_UP flags is cleared, such fields are not guaranteed to be valid. Therefore, rcu lock along with netdevice state check ensures that, while route lookup and cm_id lookup is in progress, netdevice of interest won't migrate to any other net namespace. This ensures that associated net namespace of netdevice won't get deleted while rcu lock is held for netdevice which is in IFF_UP state. Fixes: fa20105e ("IB/cma: Add support for network namespaces") Fixes: 4be74b42 ("IB/cma: Separate port allocation to network namespaces") Fixes: f887f2ac ("IB/cma: Validate routing of incoming requests") Signed-off-by:
Parav Pandit <parav@mellanox.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
-
Matan Barak authored
[ Upstream commit f604db64 ] Previously, if a method contained mandatory attributes in a namespace that wasn't given by the user, these attributes weren't validated. Fixing this by iterating over all specification namespaces. Fixes: fac9658c ("IB/core: Add new ioctl interface") Signed-off-by:
Matan Barak <matanb@mellanox.com> Signed-off-by:
-
Greg Thelen authored
[ Upstream commit f7cb7b85 ] Allow INFINIBAND without INFINIBAND_ADDR_TRANS because fuzzing has been finding fair number of CM bugs. So provide option to disable it. Signed-off-by:
Greg Thelen <gthelen@google.com> Cc: Tarick Bedeir <tarick@google.com> Reviewed-by:
Bart Van Assche <bart.vanassche@wdc.com> Signed-off-by:
-
Greg Thelen authored
[ Upstream commit 5a3bc8a4 ] INFINIBAND_SRP code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by:
-
Greg Thelen authored
[ Upstream commit 346a47b6 ] INFINIBAND_SRPT code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by:
-
Greg Thelen authored
[ Upstream commit d6fc6a22 ] NVME_TARGET_RDMA code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by:
-
Greg Thelen authored
[ Upstream commit 3af7a156 ] NVME_RDMA code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by:
-
Jon Maloy authored
[ Upstream commit 7dbc73e6 ] Commit 36a50a98 ("tipc: fix infinite loop when dumping link monitor summary") intended to fix a problem with user tool looping when max number of bearers are enabled. Unfortunately, the wrong version of the commit was posted, so the problem was not solved at all. This commit adds the missing part. Fixes: 36a50a98 ("tipc: fix infinite loop when dumping link monitor summary") Signed-off-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Baolin Wang authored
[ Upstream commit 2a010461 ] We found the I2C controller count register is unreliable sometimes, that will cause I2C to lose data. Thus we can read the data count from 'i2c_dev->count' instead of the I2C controller count register. Signed-off-by:
Baolin Wang <baolin.wang@linaro.org> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Baolin Wang authored
[ Upstream commit da33aa03 ] Add one flag to indicate if the i2c controller has been in suspend state, which can prevent i2c accesses after i2c controller is suspended following system suspend. Signed-off-by:
-
John Fastabend authored
[ Upstream commit 81542556 ] Here the variable cont is used as the saved_pointer for a call to strtok_r(). It is safe to use the value uninitialized in this context however and the later reference is only ever used if the strtok_r is successful. But, 'gcc-5' at least doesn't have all this knowledge so initialize cont to NULL. Additionally, do the natural NULL check before accessing just for completness. The warning is the following: ./bpf/tools/bpf/bpf_dbg.c: In function ‘cmd_load’: ./bpf/tools/bpf/bpf_dbg.c:1077:13: warning: ‘cont’ may be used uninitialized in this function [-Wmaybe-uninitialized] } else if (matches(subcmd, "pcap") == 0) { Fixes: fd981e3c "filter: bpf_dbg: add minimal bpf debugger" Signed-off-by:
John Fastabend <john.fastabend@gmail.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
jacek.tomaka@poczta.fm authored
[ Upstream commit b837913f ] Make kernel print the correct number of TLB entries on Intel Xeon Phi 7210 (and others) Before: [ 0.320005] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0 After: [ 0.320005] Last level dTLB entries: 4KB 256, 2MB 128, 4MB 128, 1GB 16 The entries do exist in the official Intel SMD but the type column there is incorrect (states "Cache" where it should read "TLB"), but the entries for the values 0x6B, 0x6C and 0x6D are correctly described as 'Data TLB'. Signed-off-by:
Jacek Tomaka <jacek.tomaka@poczta.fm> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/20180423161425.24366-1-jacekt@dugeo.comSigned-off-by:
-
Evan Wang authored
[ Upstream commit daa2e3bd ] There is an issue(Errata Ref#226) that the SATA can not be detected via SATA Port-MultiPlayer(PMP) with following error log: ata1.15: PMP product ID mismatch ata1.15: SATA link up 6.0 Gbps (SStatus 133 SControl 300) ata1.15: Port Multiplier vendor mismatch '0x1b4b'!='0x0' ata1.15: PMP revalidation failed (errno=-19) After debugging, the reason is found that the value Port-x FIS-based Switching Control(PxFBS@0x40) become wrong. According to design, the bits[11:8, 0] of register PxFBS are cleared when Port Command and Status (0x18) bit[0] changes its value from 1 to 0, i.e. falling edge of Port Command and Status bit[0] sends PULSE that resets PxFBS bits[11:8; 0]. So it needs a mvebu SATA WA to save the port PxFBS register before PxCMD ST write and restore it afterwards. This patch implements the WA in a separate function of ahci_mvebu_stop_engine to override ahci_stop_gngine. Signed-off-by:
Evan Wang <xswang@marvell.com> Cc: Ofer Heifetz <oferh@marvell.com> Cc: Tejun Heo <tj@kernel.org> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Evan Wang authored
[ Upstream commit fa89f53b ] Marvell armada37xx, armada7k and armada8k share the same AHCI sata controller IP, and currently there is an issue (Errata Ref#226)that the SATA can not be detected via SATA Port-MultiPlayer(PMP). After debugging, the reason is found that the value of Port-x FIS-based Switching Control (PxFBS@0x40) became wrong. According to design, the bits[11:8, 0] of register PxFBS are cleared when Port Command and Status (0x18) bit[0] changes its value from 1 to 0, i.e. falling edge of Port Command and Status bit[0] sends PULSE that resets PxFBS bits[11:8; 0]. So it needs save the port PxFBS register before PxCMD ST write and restore the port PxFBS register afterwards in ahci_stop_engine(). This commit allows drivers to override ahci_stop_engine behavior for use by the Marvell AHCI driver(and potentially other drivers in the future). Signed-off-by:
-
Mark Rutland authored
[ Upstream commit 5e1ca5e2 ] It's possible for userspace to control n. Sanitize n when using it as an array index. Note that while it appears that n must be bound to the interval [0,3] due to the way it is extracted from addr, we cannot guarantee that compiler transformations (and/or future refactoring) will ensure this is the case, and given this is a slow path it's better to always perform the masking. Found by smatch. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Acked-by:
Christoffer Dall <christoffer.dall@arm.com> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Cc: kvmarm@lists.cs.columbia.edu Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Mark Rutland authored
[ Upstream commit 19791a7c ] It's possible for userspace to control idx. Sanitize idx when using it as an array index. Found by smatch. Signed-off-by:
-
Omar Sandoval authored
[ Upstream commit bf0ddaba ] When the blk-mq inflight implementation was added, /proc/diskstats was converted to use it, but /sys/block/$dev/inflight was not. Fix it by adding another helper to count in-flight requests by data direction. Fixes: f299b7c7 ("blk-mq: provide internal in-flight variant") Signed-off-by:
Omar Sandoval <osandov@fb.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Arvind Yadav authored
[ Upstream commit a4eb490a ] Never directly free @dev after calling device_register(), even if it returned an error. Always use put_device() to give up the reference initialized. Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Ramon Fried authored
[ Upstream commit 93dd4e73 ] Added "rpmsg:rpmsg_chrdev" MODULE_ALIAS to autoload rpmg_chrdev module automatically. Signed-off-by:
Ramon Fried <rfried@codeaurora.org> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Tobias Jordan authored
[ Upstream commit 278d744c ] Add missing of_node_put()s at two places for device nodes returned by of_parse_phandle(). Fixes: 051fb70f ("remoteproc: qcom: Driver for the self-authenticating Hexagon v5") Signed-off-by:
Tobias Jordan <Tobias.Jordan@elektrobit.com> Signed-off-by:
-
Kan Liang authored
[ Upstream commit 4e949e9b ] The SMM freeze feature was introduced since PerfMon V2. But the current code unconditionally enables the feature for all platforms. It can generate #GP exception, if the related FREEZE_WHILE_SMM bit is set for the machine with PerfMon V1. To disable the feature for PerfMon V1, perf needs to - Remove the freeze_on_smi sysfs entry by moving intel_pmu_attrs to intel_pmu, which is only applied to PerfMon V2 and later. - Check the PerfMon version before flipping the SMM bit when starting CPU Fixes: 6089327f ("perf/x86: Add sysfs entry to freeze counters on SMI") Signed-off-by:
Kan Liang <kan.liang@linux.intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: ak@linux.intel.com Cc: eranian@google.com Cc: acme@redhat.com Link: https://lkml.kernel.org/r/1524682637-63219-1-git-send-email-kan.liang@linux.intel.comSigned-off-by:
-
Dag Moxnes authored
[ Upstream commit 91a82529 ] The function rds_ib_setup_qp is calling rds_ib_get_client_data and should correspondingly call rds_ib_dev_put. This call was lost in the non-error path with the introduction of error handling done in commit 3b12f73a ("rds: ib: add error handle") Signed-off-by:
Dag Moxnes <dag.moxnes@oracle.com> Reviewed-by:
Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by:
-
Masami Hiramatsu authored
[ Upstream commit 25aa50e0 ] Add a testcase for multiple actions with different parameters on an event trigger, which has been fixed by commit 192c283e93bd ("tracing: Add action comparisons when testing matching hist triggers"). Link: http://lkml.kernel.org/r/152292055227.15769.6327959816123227152.stgit@devboxReviewed-by:
Tom Zanussi <tom.zanussi@linux.intel.com> Tested-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Arvind Yadav authored
[ Upstream commit 097b8f62 ] Free device resource data, if __wacom_devm_sysfs_create_group is not successful. Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
-
pgzh authored
[ Upstream commit a230cd52 ] The IBM/Lenovo Scrollpoint mice feature a trackpoint-like stick instead of a scrolling wheel capable of 2-D (vertical+horizontal) scrolling. hid-generic does only expose 1-D (vertical) scrolling functionality for these mice. This patch adds support for horizontal scrolling for the IBM/Lenovo Scrollpoint mice to hid-lenovo. [jkosina@suse.cz: remove change versioning from git changelog] Signed-off-by:
Peter Ganzhorn <peter.ganzhorn@gmail.com> Reviewed-by:
Peter De Wachter <pdewacht@gmail.com> Signed-off-by:
-
