summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-02-16tools/power/x86: Debug utility for intel_pstate driverDoug Smythies
This utility can be used to debug and tune the performance of the intel_pstate driver. This utility can be used in two ways: - If there is Linux trace file with pstate_sample events enabled, then this utility can parse the trace file and generate performance plots. - If user has not specified a trace file as input via command line parameters, then this utility enables and collects trace data for a user-specified interval and generates performance plots. Signed-off-by: Doug Smythies <dsmythies@telus.net> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-16AnalyzeSuspend: fix drag and zoom bug in javascriptTodd E Brandt
Signed-off-by: Todd Brandt <todd.e.brandt@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-15ibmvnic: Fix endian errors in error reporting outputThomas Falcon
Error reports received from firmware were not being converted from big endian values, leading to bogus error codes reported on little endian systems. Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-15ibmvnic: Fix endian error when requesting device capabilitiesThomas Falcon
When a vNIC client driver requests a faulty device setting, the server returns an acceptable value for the client to request. This 64 bit value was incorrectly being swapped as a 32 bit value, resulting in loss of data. This patch corrects that by using the 64 bit swap function. Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-15net: neigh: Fix netevent NETEVENT_DELAY_PROBE_TIME_UPDATE notificationMarcus Huewe
When setting a neigh related sysctl parameter, we always send a NETEVENT_DELAY_PROBE_TIME_UPDATE netevent. For instance, when executing sysctl net.ipv6.neigh.wlp3s0.retrans_time_ms=2000 a NETEVENT_DELAY_PROBE_TIME_UPDATE netevent is generated. This is caused by commit 2a4501ae18b5 ("neigh: Send a notification when DELAY_PROBE_TIME changes"). According to the commit's description, it was intended to generate such an event when setting the "delay_first_probe_time" sysctl parameter. In order to fix this, only generate this event when actually setting the "delay_first_probe_time" sysctl parameter. This fix should not have any unintended side-effects, because all but one registered netevent callbacks check for other netevent event types (the registered callbacks were obtained by grepping for "register_netevent_notifier"). The only callback that uses the NETEVENT_DELAY_PROBE_TIME_UPDATE event is mlxsw_sp_router_netevent_event() (in drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c): in case of this event, it only accesses the DELAY_PROBE_TIME of the passed neigh_parms. Fixes: 2a4501ae18b5 ("neigh: Send a notification when DELAY_PROBE_TIME changes") Signed-off-by: Marcus Huewe <suse-tux@gmx.de> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-15net: xilinx_emaclite: fix freezes due to unordered I/OAnssi Hannula
The xilinx_emaclite uses __raw_writel and __raw_readl for register accesses. Those functions do not imply any kind of memory barriers and they may be reordered. The driver does not seem to take that into account, though, and the driver does not satisfy the ordering requirements of the hardware. For clear examples, see xemaclite_mdio_write() and xemaclite_mdio_read() which try to set MDIO address before initiating the transaction. I'm seeing system freezes with the driver with GCC 5.4 and current Linux kernels on Zynq-7000 SoC immediately when trying to use the interface. In commit 123c1407af87 ("net: emaclite: Do not use microblaze and ppc IO functions") the driver was switched from non-generic in_be32/out_be32 (memory barriers, big endian) to __raw_readl/__raw_writel (no memory barriers, native endian), so apparently the device follows system endianness and the driver was originally written with the assumption of memory barriers. Rather than try to hunt for each case of missing barrier, just switch the driver to use iowrite32/ioread32/iowrite32be/ioread32be depending on endianness instead. Tested on little-endian Zynq-7000 ARM SoC FPGA. Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Fixes: 123c1407af87 ("net: emaclite: Do not use microblaze and ppc IO functions") Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-15net: xilinx_emaclite: fix receive buffer overflowAnssi Hannula
xilinx_emaclite looks at the received data to try to determine the Ethernet packet length but does not properly clamp it if proto_type == ETH_P_IP or 1500 < proto_type <= 1518, causing a buffer overflow and a panic via skb_panic() as the length exceeds the allocated skb size. Fix those cases. Also add an additional unconditional check with WARN_ON() at the end. Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Fixes: bb81b2ddfa19 ("net: add Xilinx emac lite device driver") Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-15PCI/PME: Restore pcie_pme_driver.removeYinghai Lu
In addition to making PME non-modular, d7def2040077 ("PCI/PME: Make explicitly non-modular") removed the pcie_pme_driver .remove() method, pcie_pme_remove(). pcie_pme_remove() freed the PME IRQ that was requested in pci_pme_probe(). The fact that we don't free the IRQ after d7def2040077 causes the following crash when removing a PCIe port device via /sys: ------------[ cut here ]------------ kernel BUG at drivers/pci/msi.c:370! invalid opcode: 0000 [#1] SMP Modules linked in: CPU: 1 PID: 14509 Comm: sh Tainted: G W 4.8.0-rc1-yh-00012-gd29438d RIP: 0010:[<ffffffff9758bbf5>] free_msi_irqs+0x65/0x190 ... Call Trace: [<ffffffff9758cda4>] pci_disable_msi+0x34/0x40 [<ffffffff97583817>] cleanup_service_irqs+0x27/0x30 [<ffffffff97583e9a>] pcie_port_device_remove+0x2a/0x40 [<ffffffff97584250>] pcie_portdrv_remove+0x40/0x50 [<ffffffff97576d7b>] pci_device_remove+0x4b/0xc0 [<ffffffff9785ebe6>] __device_release_driver+0xb6/0x150 [<ffffffff9785eca5>] device_release_driver+0x25/0x40 [<ffffffff975702e4>] pci_stop_bus_device+0x74/0xa0 [<ffffffff975704ea>] pci_stop_and_remove_bus_device_locked+0x1a/0x30 [<ffffffff97578810>] remove_store+0x50/0x70 [<ffffffff9785a378>] dev_attr_store+0x18/0x30 [<ffffffff97260b64>] sysfs_kf_write+0x44/0x60 [<ffffffff9725feae>] kernfs_fop_write+0x10e/0x190 [<ffffffff971e13f8>] __vfs_write+0x28/0x110 [<ffffffff970b0fa4>] ? percpu_down_read+0x44/0x80 [<ffffffff971e53a7>] ? __sb_start_write+0xa7/0xe0 [<ffffffff971e53a7>] ? __sb_start_write+0xa7/0xe0 [<ffffffff971e1f04>] vfs_write+0xc4/0x180 [<ffffffff971e3089>] SyS_write+0x49/0xa0 [<ffffffff97001a46>] do_syscall_64+0xa6/0x1b0 [<ffffffff9819201e>] entry_SYSCALL64_slow_path+0x25/0x25 ... RIP [<ffffffff9758bbf5>] free_msi_irqs+0x65/0x190 RSP <ffff89ad3085bc48> ---[ end trace f4505e1dac5b95d3 ]--- Segmentation fault Restore pcie_pme_remove(). [bhelgaas: changelog] Fixes: d7def2040077 ("PCI/PME: Make explicitly non-modular") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> CC: stable@vger.kernel.org # v4.9+
2017-02-15perf tools: Add missing parse_events_error() prototypeArnaldo Carvalho de Melo
As pointed out by clang, we were not providing a prototype for a function before using it: util/parse-events.y:699:6: error: conflicting types for 'parse_events_error' void parse_events_error(YYLTYPE *loc, void *data, ^ /tmp/build/perf/util/parse-events-bison.c:2224:7: note: previous implicit declaration is here yyerror (&yylloc, _data, scanner, YY_("syntax error")); ^ /tmp/build/perf/util/parse-events-bison.c:65:25: note: expanded from macro 'yyerror' #define yyerror parse_events_error 1 error generated. One line fix it. Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/r/20170215130605.GC4020@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-02-15perf pmu: Fix check for unset alias->unit arrayArnaldo Carvalho de Melo
The alias->unit field is an array, so to check that it is not set we should see if it is an empty string, i.e. alias->unit[0], instead of checking alias->unit != NULL, as this will _always_ evaluate to 'true'. Pointed out by clang. Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/r/20170214182435.GD4458@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-02-15timekeeping: Use deferred printk() in debug codeSergey Senozhatsky
We cannot do printk() from tk_debug_account_sleep_time(), because tk_debug_account_sleep_time() is called under tk_core seq lock. The reason why printk() is unsafe there is that console_sem may invoke scheduler (up()->wake_up_process()->activate_task()), which, in turn, can return back to timekeeping code, for instance, via get_time()->ktime_get(), deadlocking the system on tk_core seq lock. [ 48.950592] ====================================================== [ 48.950622] [ INFO: possible circular locking dependency detected ] [ 48.950622] 4.10.0-rc7-next-20170213+ #101 Not tainted [ 48.950622] ------------------------------------------------------- [ 48.950622] kworker/0:0/3 is trying to acquire lock: [ 48.950653] (tk_core){----..}, at: [<c01cc624>] retrigger_next_event+0x4c/0x90 [ 48.950683] but task is already holding lock: [ 48.950683] (hrtimer_bases.lock){-.-...}, at: [<c01cc610>] retrigger_next_event+0x38/0x90 [ 48.950714] which lock already depends on the new lock. [ 48.950714] the existing dependency chain (in reverse order) is: [ 48.950714] -> #5 (hrtimer_bases.lock){-.-...}: [ 48.950744] _raw_spin_lock_irqsave+0x50/0x64 [ 48.950775] lock_hrtimer_base+0x28/0x58 [ 48.950775] hrtimer_start_range_ns+0x20/0x5c8 [ 48.950775] __enqueue_rt_entity+0x320/0x360 [ 48.950805] enqueue_rt_entity+0x2c/0x44 [ 48.950805] enqueue_task_rt+0x24/0x94 [ 48.950836] ttwu_do_activate+0x54/0xc0 [ 48.950836] try_to_wake_up+0x248/0x5c8 [ 48.950836] __setup_irq+0x420/0x5f0 [ 48.950836] request_threaded_irq+0xdc/0x184 [ 48.950866] devm_request_threaded_irq+0x58/0xa4 [ 48.950866] omap_i2c_probe+0x530/0x6a0 [ 48.950897] platform_drv_probe+0x50/0xb0 [ 48.950897] driver_probe_device+0x1f8/0x2cc [ 48.950897] __driver_attach+0xc0/0xc4 [ 48.950927] bus_for_each_dev+0x6c/0xa0 [ 48.950927] bus_add_driver+0x100/0x210 [ 48.950927] driver_register+0x78/0xf4 [ 48.950958] do_one_initcall+0x3c/0x16c [ 48.950958] kernel_init_freeable+0x20c/0x2d8 [ 48.950958] kernel_init+0x8/0x110 [ 48.950988] ret_from_fork+0x14/0x24 [ 48.950988] -> #4 (&rt_b->rt_runtime_lock){-.-...}: [ 48.951019] _raw_spin_lock+0x40/0x50 [ 48.951019] rq_offline_rt+0x9c/0x2bc [ 48.951019] set_rq_offline.part.2+0x2c/0x58 [ 48.951049] rq_attach_root+0x134/0x144 [ 48.951049] cpu_attach_domain+0x18c/0x6f4 [ 48.951049] build_sched_domains+0xba4/0xd80 [ 48.951080] sched_init_smp+0x68/0x10c [ 48.951080] kernel_init_freeable+0x160/0x2d8 [ 48.951080] kernel_init+0x8/0x110 [ 48.951080] ret_from_fork+0x14/0x24 [ 48.951110] -> #3 (&rq->lock){-.-.-.}: [ 48.951110] _raw_spin_lock+0x40/0x50 [ 48.951141] task_fork_fair+0x30/0x124 [ 48.951141] sched_fork+0x194/0x2e0 [ 48.951141] copy_process.part.5+0x448/0x1a20 [ 48.951171] _do_fork+0x98/0x7e8 [ 48.951171] kernel_thread+0x2c/0x34 [ 48.951171] rest_init+0x1c/0x18c [ 48.951202] start_kernel+0x35c/0x3d4 [ 48.951202] 0x8000807c [ 48.951202] -> #2 (&p->pi_lock){-.-.-.}: [ 48.951232] _raw_spin_lock_irqsave+0x50/0x64 [ 48.951232] try_to_wake_up+0x30/0x5c8 [ 48.951232] up+0x4c/0x60 [ 48.951263] __up_console_sem+0x2c/0x58 [ 48.951263] console_unlock+0x3b4/0x650 [ 48.951263] vprintk_emit+0x270/0x474 [ 48.951293] vprintk_default+0x20/0x28 [ 48.951293] printk+0x20/0x30 [ 48.951324] kauditd_hold_skb+0x94/0xb8 [ 48.951324] kauditd_thread+0x1a4/0x56c [ 48.951324] kthread+0x104/0x148 [ 48.951354] ret_from_fork+0x14/0x24 [ 48.951354] -> #1 ((console_sem).lock){-.....}: [ 48.951385] _raw_spin_lock_irqsave+0x50/0x64 [ 48.951385] down_trylock+0xc/0x2c [ 48.951385] __down_trylock_console_sem+0x24/0x80 [ 48.951385] console_trylock+0x10/0x8c [ 48.951416] vprintk_emit+0x264/0x474 [ 48.951416] vprintk_default+0x20/0x28 [ 48.951416] printk+0x20/0x30 [ 48.951446] tk_debug_account_sleep_time+0x5c/0x70 [ 48.951446] __timekeeping_inject_sleeptime.constprop.3+0x170/0x1a0 [ 48.951446] timekeeping_resume+0x218/0x23c [ 48.951477] syscore_resume+0x94/0x42c [ 48.951477] suspend_enter+0x554/0x9b4 [ 48.951477] suspend_devices_and_enter+0xd8/0x4b4 [ 48.951507] enter_state+0x934/0xbd4 [ 48.951507] pm_suspend+0x14/0x70 [ 48.951507] state_store+0x68/0xc8 [ 48.951538] kernfs_fop_write+0xf4/0x1f8 [ 48.951538] __vfs_write+0x1c/0x114 [ 48.951538] vfs_write+0xa0/0x168 [ 48.951568] SyS_write+0x3c/0x90 [ 48.951568] __sys_trace_return+0x0/0x10 [ 48.951568] -> #0 (tk_core){----..}: [ 48.951599] lock_acquire+0xe0/0x294 [ 48.951599] ktime_get_update_offsets_now+0x5c/0x1d4 [ 48.951629] retrigger_next_event+0x4c/0x90 [ 48.951629] on_each_cpu+0x40/0x7c [ 48.951629] clock_was_set_work+0x14/0x20 [ 48.951660] process_one_work+0x2b4/0x808 [ 48.951660] worker_thread+0x3c/0x550 [ 48.951660] kthread+0x104/0x148 [ 48.951690] ret_from_fork+0x14/0x24 [ 48.951690] other info that might help us debug this: [ 48.951690] Chain exists of: tk_core --> &rt_b->rt_runtime_lock --> hrtimer_bases.lock [ 48.951721] Possible unsafe locking scenario: [ 48.951721] CPU0 CPU1 [ 48.951721] ---- ---- [ 48.951721] lock(hrtimer_bases.lock); [ 48.951751] lock(&rt_b->rt_runtime_lock); [ 48.951751] lock(hrtimer_bases.lock); [ 48.951751] lock(tk_core); [ 48.951782] *** DEADLOCK *** [ 48.951782] 3 locks held by kworker/0:0/3: [ 48.951782] #0: ("events"){.+.+.+}, at: [<c0156590>] process_one_work+0x1f8/0x808 [ 48.951812] #1: (hrtimer_work){+.+...}, at: [<c0156590>] process_one_work+0x1f8/0x808 [ 48.951843] #2: (hrtimer_bases.lock){-.-...}, at: [<c01cc610>] retrigger_next_event+0x38/0x90 [ 48.951843] stack backtrace: [ 48.951873] CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.10.0-rc7-next-20170213+ [ 48.951904] Workqueue: events clock_was_set_work [ 48.951904] [<c0110208>] (unwind_backtrace) from [<c010c224>] (show_stack+0x10/0x14) [ 48.951934] [<c010c224>] (show_stack) from [<c04ca6c0>] (dump_stack+0xac/0xe0) [ 48.951934] [<c04ca6c0>] (dump_stack) from [<c019b5cc>] (print_circular_bug+0x1d0/0x308) [ 48.951965] [<c019b5cc>] (print_circular_bug) from [<c019d2a8>] (validate_chain+0xf50/0x1324) [ 48.951965] [<c019d2a8>] (validate_chain) from [<c019ec18>] (__lock_acquire+0x468/0x7e8) [ 48.951995] [<c019ec18>] (__lock_acquire) from [<c019f634>] (lock_acquire+0xe0/0x294) [ 48.951995] [<c019f634>] (lock_acquire) from [<c01d0ea0>] (ktime_get_update_offsets_now+0x5c/0x1d4) [ 48.952026] [<c01d0ea0>] (ktime_get_update_offsets_now) from [<c01cc624>] (retrigger_next_event+0x4c/0x90) [ 48.952026] [<c01cc624>] (retrigger_next_event) from [<c01e4e24>] (on_each_cpu+0x40/0x7c) [ 48.952056] [<c01e4e24>] (on_each_cpu) from [<c01cafc4>] (clock_was_set_work+0x14/0x20) [ 48.952056] [<c01cafc4>] (clock_was_set_work) from [<c015664c>] (process_one_work+0x2b4/0x808) [ 48.952087] [<c015664c>] (process_one_work) from [<c0157774>] (worker_thread+0x3c/0x550) [ 48.952087] [<c0157774>] (worker_thread) from [<c015d644>] (kthread+0x104/0x148) [ 48.952087] [<c015d644>] (kthread) from [<c0107830>] (ret_from_fork+0x14/0x24) Replace printk() with printk_deferred(), which does not call into the scheduler. Fixes: 0bf43f15db85 ("timekeeping: Prints the amounts of time spent during suspend") Reported-and-tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Petr Mladek <pmladek@suse.com> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: "Rafael J . Wysocki" <rjw@rjwysocki.net> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: John Stultz <john.stultz@linaro.org> Cc: "[4.9+]" <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20170215044332.30449-1-sergey.senozhatsky@gmail.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-02-15drm/dp/mst: fix kernel oops when turning off secondary monitorPierre-Louis Bossart
100% reproducible issue found on SKL SkullCanyon NUC with two external DP daisy-chained monitors in DP/MST mode. When turning off or changing the input of the second monitor the machine stops with a kernel oops. This issue happened with 4.8.8 as well as drm/drm-intel-nightly. This issue is traced to an inconsistent control flow in drm_dp_update_payload_part1(): the 'port' pointer is set to NULL at the same time as 'req_payload.num_slots' is set to zero, but the pointer is dereferenced even when req_payload.num_slot is zero. The problematic dereference was introduced in commit dfda0df34 ("drm/mst: rework payload table allocation to conform better") and may impact all versions since v3.18 The fix suggested by Chris Wilson removes the kernel oops and was found to work well after 10mn of monkey-testing with the second monitor power and input buttons Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98990 Fixes: dfda0df34264 ("drm/mst: rework payload table allocation to conform better.") Cc: Dave Airlie <airlied@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Nathan D Ciobanu <nathan.d.ciobanu@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: <stable@vger.kernel.org> # v3.18+ Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@linux.intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487076561-2169-1-git-send-email-jani.nikula@intel.com
2017-02-15fuse: fix use after free issue in fuse_dev_do_read()Sahitya Tummala
There is a potential race between fuse_dev_do_write() and request_wait_answer() contexts as shown below: TASK 1: __fuse_request_send(): |--spin_lock(&fiq->waitq.lock); |--queue_request(); |--spin_unlock(&fiq->waitq.lock); |--request_wait_answer(): |--if (test_bit(FR_SENT, &req->flags)) <gets pre-empted after it is validated true> TASK 2: fuse_dev_do_write(): |--clears bit FR_SENT, |--request_end(): |--sets bit FR_FINISHED |--spin_lock(&fiq->waitq.lock); |--list_del_init(&req->intr_entry); |--spin_unlock(&fiq->waitq.lock); |--fuse_put_request(); |--queue_interrupt(); <request gets queued to interrupts list> |--wake_up_locked(&fiq->waitq); |--wait_event_freezable(); <as FR_FINISHED is set, it returns and then the caller frees this request> Now, the next fuse_dev_do_read(), see interrupts list is not empty and then calls fuse_read_interrupt() which tries to access the request which is already free'd and gets the below crash: [11432.401266] Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b6b ... [11432.418518] Kernel BUG at ffffff80083720e0 [11432.456168] PC is at __list_del_entry+0x6c/0xc4 [11432.463573] LR is at fuse_dev_do_read+0x1ac/0x474 ... [11432.679999] [<ffffff80083720e0>] __list_del_entry+0x6c/0xc4 [11432.687794] [<ffffff80082c65e0>] fuse_dev_do_read+0x1ac/0x474 [11432.693180] [<ffffff80082c6b14>] fuse_dev_read+0x6c/0x78 [11432.699082] [<ffffff80081d5638>] __vfs_read+0xc0/0xe8 [11432.704459] [<ffffff80081d5efc>] vfs_read+0x90/0x108 [11432.709406] [<ffffff80081d67f0>] SyS_read+0x58/0x94 As FR_FINISHED bit is set before deleting the intr_entry with input queue lock in request completion path, do the testing of this flag and queueing atomically with the same lock in queue_interrupt(). Signed-off-by: Sahitya Tummala <stummala@codeaurora.org> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Fixes: fd22d62ed0c3 ("fuse: no fc->lock for iqueue parts") Cc: <stable@vger.kernel.org> # 4.2+
2017-02-14bpf: kernel header files need to be copied into the tools directoryStephen Rothwell
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-14tcp: tcp_probe: use spin_lock_bh()Eric Dumazet
tcp_rcv_established() can now run in process context. We need to disable BH while acquiring tcp probe spinlock, or risk a deadlock. Fixes: 5413d1babe8f ("net: do not block BH while processing socket backlog") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Ricardo Nabinger Sanchez <rnsanchez@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-14uapi: fix linux/if_pppol2tp.h userspace compilation errorsDmitry V. Levin
Because of <linux/libc-compat.h> interface limitations, <netinet/in.h> provided by libc cannot be included after <linux/in.h>, therefore any header that includes <netinet/in.h> cannot be included after <linux/in.h>. Change uapi/linux/l2tp.h, the last uapi header that includes <netinet/in.h>, to include <linux/in.h> and <linux/in6.h> instead of <netinet/in.h> and use __SOCK_SIZE__ instead of sizeof(struct sockaddr) the same way as uapi/linux/in.h does, to fix linux/if_pppol2tp.h userspace compilation errors like this: In file included from /usr/include/linux/l2tp.h:12:0, from /usr/include/linux/if_pppol2tp.h:21, /usr/include/netinet/in.h:31:8: error: redefinition of 'struct in_addr' Fixes: 47c3e7783be4 ("net: l2tp: deprecate PPPOL2TP_MSG_* in favour of L2TP_MSG_*") Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-14leds: ledtrig-heartbeat: Make top brightness adjustableJacek Anaszewski
LED class heartbeat trigger allowed only for blinking with max_brightness value. This patch adds more flexibility by exploiting part of LED core software blink infrastructure. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2017-02-14tools/leds: Add led_hw_brightness_mon programJacek Anaszewski
LED subsystem supports POLLPRI on "brightness_hw_changed" sysfs file of LED class devices. This tool demonstrates how to use the feature. Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Pavel Machek <pavel@ucw.cz>
2017-02-14Revert "i2c: designware: detect when dynamic tar update is possible"Jarkko Nikula
This reverts commit 63d0f0a6952a1a02bc4f116b7da7c7887e46efa3. It caused a regression on platforms where I2C controller is synthesized with dynamic TAR update disabled. Detection code is testing is bit DW_IC_CON_10BITADDR_MASTER in register DW_IC_CON read-only but fails to restore original value in case bit is read-write. Instead of fixing this we revert the commit since it was preparation for the commit 0317e6c0f1dc ("i2c: designware: do not disable adapter after transfer") which was also reverted. Reported-by: Shah Nehal-Bakulchandra <Nehal-bakulchandra.Shah@amd.com> Reported-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Acked-By: Lucas De Marchi <lucas.demarchi@intel.com> Cc: <stable@vger.kernel.org> # v4.9+ Fixes: 63d0f0a6952a ("i2c: designware: detect when dynamic tar update is possible") Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2017-02-14[media] siano: make it work again with CONFIG_VMAP_STACKMauro Carvalho Chehab
Reported as a Kaffeine bug: https://bugs.kde.org/show_bug.cgi?id=375811 The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. On Kernel 4.9, the default is to not accept DMA on stack anymore on x86 architecture. On other architectures, this has been a requirement since Kernel 2.2. So, after this patch, this driver should likely work fine on all archs. Tested with USB ID 2040:5510: Hauppauge Windham Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-02-14packet: fix races in fanout_add()Eric Dumazet
Multiple threads can call fanout_add() at the same time. We need to grab fanout_mutex earlier to avoid races that could lead to one thread freeing po->rollover that was set by another thread. Do the same in fanout_release(), for peace of mind, and to help us finding lockdep issues earlier. Fixes: dc99f600698d ("packet: Add fanout support.") Fixes: 0648ab70afe6 ("packet: rollover prepare: per-socket state") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-14ibmvnic: Fix initial MTU settingsThomas Falcon
In the current driver, the MTU is set to the maximum value capable for the backing device. This decision turned out to be a mistake as it led to confusion among users. The expected initial MTU value used for other IBM vNIC capable operating systems is 1500, with the maximum value (9000) reserved for when Jumbo frames are enabled. This patch sets the MTU to the default value for a net device. It also corrects a discrepancy between MTU values received from firmware, which includes the ethernet header length, and net device MTU values. Finally, it removes redundant min/max MTU assignments after device initialization. Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-14net: ethernet: ti: cpsw: fix cpsw assignment in resumeIvan Khoronzhuk
There is a copy-paste error, which hides breaking of resume for CPSW driver: there was replaced netdev_priv() to ndev_to_cpsw(ndev) in suspend, but left it unchanged in resume. Fixes: 606f39939595a4d4540406bfc11f265b2036af6d (ti: cpsw: move platform data and slaves info to cpsw_common) Reported-by: Alexey Starikovskiy <AStarikovskiy@topcon.com> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-14perf tools: Be consistent on the type of map->symbols[] interatorArnaldo Carvalho de Melo
In a few cases we were using 'enum map_type' and that triggered this warning when using clang: util/session.c:1923:16: error: comparison of constant 2 with expression of type 'enum map_type' is always true [-Werror,-Wtautological-constant-out-of-range-compare] for (i = 0; i < MAP__NR_TYPES; ++i) { Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-i6uyo6bsopa2dghnx8qo7rri@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-02-14perf intel pt decoder: clang has no -Wno-override-initArnaldo Carvalho de Melo
So set it only for other compilers, allowing us to overcome yet another build failure due to an inexistent clang -W option: error: unknown warning option '-Wno-override-init'; did you mean '-Wno-override-module'? [-Werror,-Wunknown-warning-option] Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-oaa1ici3j8nygp4pzl2oobh3@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-02-14perf evsel: Do not put a variable sized type not at the end of a structArnaldo Carvalho de Melo
As this is a GNU extension and while harmless in this case, we can do the same thing in a more clearer way by using a existing thread_map and cpu_map constructors: With this we avoid this while compiling with clang: util/evsel.c:1659:17: error: field 'map' with variable sized type 'struct cpu_map' not at the end of a struct or class is a GNU extension [-Werror,-Wgnu-variable-sized-type-not-at-end] struct cpu_map map; ^ util/evsel.c:1667:20: error: field 'map' with variable sized type 'struct thread_map' not at the end of a struct or class is a GNU extension [-Werror,-Wgnu-variable-sized-type-not-at-end] struct thread_map map; ^ Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-207juvrqjiar7uvas2s83v5i@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-02-14perf probe: Avoid accessing uninitialized 'map' variableArnaldo Carvalho de Melo
Genuine problem detected with clang, the warnings are spot on: util/probe-event.c:2079:7: error: variable 'map' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if (addr) { ^~~~ util/probe-event.c:2094:6: note: uninitialized use occurs here if (map && !is_kprobe) { ^~~ util/probe-event.c:2079:3: note: remove the 'if' if its condition is always true if (addr) { ^~~~~~~~~~ util/probe-event.c:2075:8: error: variable 'map' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] if (kernel_get_symbol_address_by_name(tp->symbol, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ util/probe-event.c:2094:6: note: uninitialized use occurs here if (map && !is_kprobe) { ^~~ util/probe-event.c:2075:4: note: remove the 'if' if its condition is always false if (kernel_get_symbol_address_by_name(tp->symbol, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ util/probe-event.c:2064:17: note: initialize the variable 'map' to silence this warning struct map *map; ^ = NULL Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-m3501el55i10hctfbmi2qxzr@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-02-14perf tools: Do not put a variable sized type not at the end of a structArnaldo Carvalho de Melo
As this is a GNU extension and while harmless in this case, we can do the same thing in a more clearer way by using an existing thread_map constructor. With this we avoid this while compiling with clang: util/parse-events.c:2024:21: error: field 'map' with variable sized type 'struct thread_map' not at the end of a struct or class is a GNU extension [-Werror,-Wgnu-variable-sized-type-not-at-end] struct thread_map map; ^ 1 error generated. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-tqocbplnyyhpst6drgm2u4m3@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-02-14perf record: Do not put a variable sized type not at the end of a structArnaldo Carvalho de Melo
As this is a GNU extension and while harmless in this case, we can do the same thing in a more clearer way by using an existing thread_map constructor. With this we avoid this while compiling with clang: builtin-record.c:659:21: error: field 'map' with variable sized type 'struct thread_map' not at the end of a struct or class is a GNU extension [-Werror,-Wgnu-variable-sized-type-not-at-end] struct thread_map map; ^ 1 error generated. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-c9drclo52ezxmwa7qxklin2y@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-02-14perf tests: Synthesize struct instead of using field after variable sized typeArnaldo Carvalho de Melo
End result is the same, its an ABI, so the struct won't change, avoid using a GNU extension, so that we can catch other cases that may be bugs. Caught when building with clang: tests/parse-no-sample-id-all.c:53:20: error: field 'attr' with variable sized type 'struct attr_event' not at the end of a struct or class is a GNU extension [-Werror,-Wgnu-variable-sized-type-not-at-end] struct attr_event attr; ^ 1 error generated. Testing it: # perf test sample_id 24: Parse with no sample_id_all bit set : Ok # Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-e2vs1x771fc208uvxnwcf08b@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-02-14perf bench numa: Make sure dprintf() is not definedArnaldo Carvalho de Melo
When building with clang we get this error: bench/numa.c:46:9: error: 'dprintf' macro redefined [-Werror,-Wmacro-redefined] #define dprintf(x...) do { if (g && g->p.show_details >= 1) printf(x); } while (0) ^ /usr/include/bits/stdio2.h:145:12: note: previous definition is here # define dprintf(fd, ...) \ ^ CC /tmp/build/perf/tests/parse-no-sample-id-all.o 1 error generated. So, make sure it is undefined before using that name. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Davidlohr Bueso <dbueso@suse.de> Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp> Cc: Jakub Jelen <jjelen@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-f654o2svtrutamvxt7igwz74@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-02-14Revert "perf bench futex: Sanitize numeric parameters"Arnaldo Carvalho de Melo
This reverts commit 60758d6668b3e2fa8e5fd143d24d0425203d007e. Now that libsubcmd makes sure that OPT_UINTEGER options will not return negative values, we can revert this patch while addressing the problem it solved: # perf bench futex hash -t -4 # Running 'futex/hash' benchmark: Error: switch `t' expects an unsigned numerical value Usage: perf bench futex hash <options> -t, --threads <n> Specify amount of threads # perf bench futex hash -t-4 # Running 'futex/hash' benchmark: Error: switch `t' expects an unsigned numerical value Usage: perf bench futex hash <options> -t, --threads <n> Specify amount of threads # IMO it is more reasonable to flat out refuse to process a negative number than to silently turn it into an absolute value. This also helps in silencing clang's complaint about asking for an absolute value of an unsigned integer: bench/futex-hash.c:133:10: error: taking the absolute value of unsigned type 'unsigned int' has no effect [-Werror,-Wabsolute-value] nsecs = futexbench_sanitize_numeric(nsecs); ^ bench/futex.h:104:42: note: expanded from macro 'futexbench_sanitize_numeric' #define futexbench_sanitize_numeric(__n) abs((__n)) ^ bench/futex-hash.c:133:10: note: remove the call to 'abs' since unsigned values cannot be negative Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Davidlohr Bueso <dbueso@suse.de> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-2kl68v22or31vw643m2exz8x@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-02-14tools lib subcmd: Make it an error to pass a signed value to OPTION_UINTEGERArnaldo Carvalho de Melo
Options marked OPTION_UINTEGER or OPTION_U64 clearly indicates that an unsigned value is expected, so just error out when a negative value is passed, instead of returning something undesired to the tool. E.g.: # perf bench futex hash -t -4 # Running 'futex/hash' benchmark: Error: switch `t' expects an unsigned numerical value Usage: perf bench futex hash <options> -t, --threads <n> Specify amount of threads # Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Davidlohr Bueso <dbueso@suse.de> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-2mdn8s2raatyhz7tamrsz22r@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-02-14kcm: fix a null pointer dereference in kcm_sendmsg()WANG Cong
In commit 98e3862ca2b1 ("kcm: fix 0-length case for kcm_sendmsg()") I tried to avoid skb allocation for 0-length case, but missed a check for NULL pointer in the non EOR case. Fixes: 98e3862ca2b1 ("kcm: fix 0-length case for kcm_sendmsg()") Reported-by: Dmitry Vyukov <dvyukov@google.com> Cc: Tom Herbert <tom@herbertland.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Acked-by: Tom Herbert <tom@herbertland.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-14spi: bcm-qspi: Remove unnecessary platform_set_drvdata()Wei Yongjun
The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-02-14spi: bcm-qspi: Fix bcm_qspi_bspi_read() performanceKamal Dasu
Let bcm_qspi_bspi_flash_read() return all the requested bytes by breaking up the reads for BSPI block into optimal chunks size that a BSPI block can handle. Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-02-14net: fec: fix multicast filtering hardware setupRui Sousa
Fix hardware setup of multicast address hash: - Never clear the hardware hash (to avoid packet loss) - Construct the hash register values in software and then write once to hardware Signed-off-by: Rui Sousa <rui.sousa@nxp.com> Signed-off-by: Fugang Duan <fugang.duan@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-14Merge branch 'ipv6-v4mapped'David S. Miller
Jonathan T. Leighton says: ==================== IPv4-mapped on wire, :: dst address issue Under some circumstances IPv6 datagrams are sent with IPv4-mapped IPv6 addresses as the source. Given an IPv6 socket bound to an IPv4-mapped IPv6 address, and an IPv6 destination address, both TCP and UDP will will send packets using the IPv4-mapped IPv6 address as the source. Per RFC 6890 (Table 20), IPv4-mapped IPv6 source addresses are not allowed in an IP datagram. The problem can be observed by attempting to connect() either a TCP or UDP socket, or by using sendmsg() with a UDP socket. The patch is intended to correct this issue for all socket types. linux follows the BSD convention that an IPv6 destination address specified as in6addr_any is converted to the loopback address. Currently, neither TCP nor UDP consider the possibility that the source address is an IPv4-mapped IPv6 address, and assume that the appropriate loopback address is ::1. The patch adds a check on whether or not the source address is an IPv4-mapped IPv6 address and then sets the destination address to either ::ffff:127.0.0.1 or ::1, as appropriate. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-14ipv6: Handle IPv4-mapped src to in6addr_any dst.Jonathan T. Leighton
This patch adds a check on the type of the source address for the case where the destination address is in6addr_any. If the source is an IPv4-mapped IPv6 source address, the destination is changed to ::ffff:127.0.0.1, and otherwise the destination is changed to ::1. This is done in three locations to handle UDP calls to either connect() or sendmsg() and TCP calls to connect(). Note that udpv6_sendmsg() delays handling an in6addr_any destination until very late, so the patch only needs to handle the case where the source is an IPv4-mapped IPv6 address. Signed-off-by: Jonathan T. Leighton <jtleight@udel.edu> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-14ipv6: Inhibit IPv4-mapped src address on the wire.Jonathan T. Leighton
This patch adds a check for the problematic case of an IPv4-mapped IPv6 source address and a destination address that is neither an IPv4-mapped IPv6 address nor in6addr_any, and returns an appropriate error. The check in done before returning from looking up the route. Signed-off-by: Jonathan T. Leighton <jtleight@udel.edu> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-14spi: lantiq-ssc: add support for Lantiq SSC SPI controllerHauke Mehrtens
This driver supports the Lantiq SSC SPI controller in master mode. This controller is found on Intel (former Lantiq) SoCs like the Danube, Falcon, xRX200, xRX300. The hardware uses two hardware FIFOs one for received and one for transferred bytes. When the driver writes data into the transmit FIFO the complete word is taken from the FIFO into a shift register. The data from this shift register is then written to the wire. This driver uses the interrupts signaling the status of the FIFOs and not the shift register. It is also possible to use the interrupts for the shift register, but they will send a signal after every word. When using the interrupts for the shift register we get a signal when the last word is written into the shift register and not when it is written to the wire. After all FIFOs are empty the driver busy waits till the hardware is not busy any more and returns the transfer status. Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-02-14net/mlx5e: Disable preemption when doing TC statistics upcallOr Gerlitz
When called by HW offloading drivers, the TC action (e.g net/sched/act_mirred.c) code uses this_cpu logic, e.g _bstats_cpu_update(this_cpu_ptr(a->cpu_bstats), bytes, packets) per the kernel documention, preemption should be disabled, add that. Before the fix, when running with CONFIG_PREEMPT set, we get a BUG: using smp_processor_id() in preemptible [00000000] code: tc/3793 asserion from the TC action (mirred) stats_update callback. Fixes: aad7e08d39bd ('net/mlx5e: Hardware offloaded flower filter statistics support') Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-14HID: intel-ish-hid: constify device_type structureBhumika Goyal
Declare device_type structure as const as it is only stored in the type field of a device structure. This field is of type const, so add const to the declaration of device_type structure. File size before: drivers/hid/intel-ish-hid/ishtp/bus.o text data bss dec hex filename 4260 336 16 4612 1204 hid/intel-ish-hid/ishtp/bus.o File size after: drivers/hid/intel-ish-hid/ishtp/bus.o text data bss dec hex filename 4324 272 16 4612 1204 hid/intel-ish-hid/ishtp/bus.o Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2017-02-14Merge tag 'media/v4.10-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull media fixes from Mauro Carvalho Chehab: "A colorspace regression fix in V4L2 core and a CEC core bug that makes it discard valid messages" * tag 'media/v4.10-4' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: [media] cec: initiator should be the same as the destination for, poll [media] videodev2.h: go back to limited range Y'CbCr for SRGB and, ADOBERGB
2017-02-14HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/rangeJason Gerecke
The prox/range bits included in the Bluetooth reports from the Intuos Pro were being ignored, leading to two issues. Firstly, the pen would never announce a BTN_TOOL_PEN event with value 0, leaving userspace to believe the pen was always active. Secondly, the driver would continue to send events for data while the packet's "prox" bit was clear. This can lead to sudden incorrect pointer jumps if the pen is slowly moved away from the tablet surface. Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Reviewed-by: Ping Cheng <ping.cheng@wacom.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2017-02-14tools: Set the maximum optimization level according to the compiler being usedArnaldo Carvalho de Melo
To avoid this when using clang: warning: optimization level '-O6' is not supported; using '-O3' instead Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-kaghp8ddvzdsg03putemcq96@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-02-14tools: Suppress request for warning options not existent in clangArnaldo Carvalho de Melo
To allow building with clang, avoiding: error: unknown warning option '-Wstrict-aliasing=3'; did you mean '-Wstring-plus-int'? [-Werror,-Wunknown-warning-option] Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-xvthlvmhzfnt7jx73jgmaea1@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-02-14EDAC, amd64: Bump driver versionBorislav Petkov
Last time we did that was when we enabled Bulldozer. Now, we enabled Zen so it is only natural ... :-) Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Yazen Ghannam <Yazen.Ghannam@amd.com>
2017-02-14math64, tile: Fix build failureSudip Mukherjee
The build of tilegx allmodconfig fails with: ../arch/tile/include/asm/div64.h:5:15: error: unknown type name 'u64' static inline u64 mul_u32_u32(u32 a, u32 b) ^~~ ../arch/tile/include/asm/div64.h:5:31: error: unknown type name 'u32' static inline u64 mul_u32_u32(u32 a, u32 b) ^~~ ../arch/tile/include/asm/div64.h:5:38: error: unknown type name 'u32' static inline u64 mul_u32_u32(u32 a, u32 b) ^~~ In file included from ../fs/ubifs/ubifs.h:26:0, from ../fs/ubifs/shrinker.c:42: ../include/linux/math64.h: In function 'mul_u64_u32_shr': ../arch/tile/include/asm/div64.h:9:21: error: implicit declaration of function 'mul_u32_u32' [-Werror=implicit-function-declaration] Include the linux/types.h in tiles div64.h to slve the problem. Fixes: 9e3d6223d209 ("math64, timers: Fix 32bit mul_u64_u32_shr() and friends") Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Acked-by: Chris Metcalf <cmetcalf@mellanox.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Link: http://lkml.kernel.org/r/1485275961-20112-1-git-send-email-sudip.mukherjee@codethink.co.uk Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-02-14mmc: core: fix multi-bit bus width without high-speed modeAnssi Hannula
Commit 577fb13199b1 ("mmc: rework selection of bus speed mode") refactored bus width selection code to mmc_select_bus_width(). However, it also altered the behavior to not call the selection code in non-high-speed modes anymore. This causes 1-bit mode to always be used when the high-speed mode is not enabled, even though 4-bit and 8-bit bus are valid bus widths in the backwards-compatibility (legacy) mode as well (see e.g. 5.3.2 Bus Speed Modes in JEDEC 84-B50). This results in a significant regression in transfer speeds. Fix the code to allow 4-bit and 8-bit widths even without high-speed mode, as before. Tested with a Zynq-7000 PicoZed 7020 board. Fixes: 577fb13199b1 ("mmc: rework selection of bus speed mode") Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
generated by cgit (git 2.34.1) at 2025-09-11 16:52:56 +0000