aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-11-16net: phy: at803x: support interrupt on 8030 and 8035Måns Rullgård1-0/+4
Commit 77a993942 "phy/at8031: enable at8031 to work on interrupt mode" added interrupt support for the 8031 PHY but left out the other two chips supported by this driver. This patch sets the .ack_interrupt and .config_intr functions for the 8030 and 8035 drivers as well. Signed-off-by: Mans Rullgard <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-11-16ip_tunnel: disable preemption when updating per-cpu tstatsJason A. Donenfeld2-2/+4
Drivers like vxlan use the recently introduced udp_tunnel_xmit_skb/udp_tunnel6_xmit_skb APIs. udp_tunnel6_xmit_skb makes use of ip6tunnel_xmit, and ip6tunnel_xmit, after sending the packet, updates the struct stats using the usual u64_stats_update_begin/end calls on this_cpu_ptr(dev->tstats). udp_tunnel_xmit_skb makes use of iptunnel_xmit, which doesn't touch tstats, so drivers like vxlan, immediately after, call iptunnel_xmit_stats, which does the same thing - calls u64_stats_update_begin/end on this_cpu_ptr(dev->tstats). While vxlan is probably fine (I don't know?), calling a similar function from, say, an unbound workqueue, on a fully preemptable kernel causes real issues: [ 188.434537] BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u8:0/6 [ 188.435579] caller is debug_smp_processor_id+0x17/0x20 [ 188.435583] CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.6 #2 [ 188.435607] Call Trace: [ 188.435611] [<ffffffff8234e936>] dump_stack+0x4f/0x7b [ 188.435615] [<ffffffff81915f3d>] check_preemption_disabled+0x19d/0x1c0 [ 188.435619] [<ffffffff81915f77>] debug_smp_processor_id+0x17/0x20 The solution would be to protect the whole this_cpu_ptr(dev->tstats)/u64_stats_update_begin/end blocks with disabling preemption and then reenabling it. Signed-off-by: Jason A. Donenfeld <[email protected]> Acked-by: Hannes Frederic Sowa <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-11-16mtd: nand: fix shutdown/reboot for multi-chip systemsBrian Norris1-1/+1
If multiple NAND chips are registered to the same controller, then when rebooting the system, the first one will grab the controller lock, while the second will wait forever for the first one to release it. i.e., a classic deadlock. This problem was solved for a similar case (suspend/resume) back in commit 6b0d9a841249 ("mtd: nand: fix multi-chip suspend problem"), and the shutdown state really isn't much different for us, so rather than adding a new special case to nand_get_device(), we can just overload the FL_PM_SUSPENDED state. Now, multiple chips can "get" the same controller lock (preventing further I/O), while we still allow other chips to pass through nand_shutdown(). Original report: http://thread.gmane.org/gmane.linux.drivers.mtd/59726 http://lists.infradead.org/pipermail/linux-mtd/2015-July/059992.html Fixes: 72ea403669c7 ("mtd: nand: added nand_shutdown") Reported-by: Andrew E. Mileski <[email protected]> Signed-off-by: Brian Norris <[email protected]> Cc: Scott Branden <[email protected]> Cc: Andrew E. Mileski <[email protected]> Acked-by: Scott Branden <[email protected]> Reviewed-by: Boris Brezillon <[email protected]>
2015-11-16mtd: jz4740_nand: fix build on jz4740 after removing gpio.hBrian Norris1-0/+1
Fallout from commit 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h") We see errors like this: drivers/mtd/nand/jz4740_nand.c: In function 'jz_nand_detect_bank': drivers/mtd/nand/jz4740_nand.c:340:9: error: 'JZ_GPIO_MEM_CS0' undeclared (first use in this function) drivers/mtd/nand/jz4740_nand.c:340:9: note: each undeclared identifier is reported only once for each function it appears in drivers/mtd/nand/jz4740_nand.c:359:2: error: implicit declaration of function 'jz_gpio_set_function' [-Werror=implicit-function-declaration] drivers/mtd/nand/jz4740_nand.c:359:29: error: 'JZ_GPIO_FUNC_MEM_CS0' undeclared (first use in this function) drivers/mtd/nand/jz4740_nand.c:399:29: error: 'JZ_GPIO_FUNC_NONE' undeclared (first use in this function) drivers/mtd/nand/jz4740_nand.c: In function 'jz_nand_probe': drivers/mtd/nand/jz4740_nand.c:528:13: error: 'JZ_GPIO_MEM_CS0' undeclared (first use in this function) drivers/mtd/nand/jz4740_nand.c: In function 'jz_nand_remove': drivers/mtd/nand/jz4740_nand.c:555:14: error: 'JZ_GPIO_MEM_CS0' undeclared (first use in this function) Patched similarly to: https://patchwork.linux-mips.org/patch/11089/ Fixes: 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h") Signed-off-by: Brian Norris <[email protected]>
2015-11-16clocksource: Disallow drivers for ARCH_USES_GETTIMEOFFSETArnd Bergmann1-0/+1
We can now select clocksource drivers like ti-32k and CONFIG_OF on ancient machines that still use gettimeoffset, and the combination results in a link error. arch/arm/kernel/built-in.o: In function `time_init': (.init.text+0xc28): undefined reference to `clocksource_probe' The reason for this is that the Makefile is hidden behind CONFIG_ARCH_USES_GETTIMEOFFSET, but the Kconfig file is not, and it has shown up just now because the ti-32k driver was added and can be selected using COMPILE_TEST on all platforms. This patch hides the Kconfig menu in CONFIG_ARCH_USES_GETTIMEOFFSET as well. Fixes: dfedaf105d60 "clocksource: ti-32k: make it depend on GENERIC_CLOCKSOURCE" Signed-off-by: Arnd Bergmann <[email protected]> Cc: [email protected] Cc: Felipe Balbi <[email protected]> Cc: Tony Lindgren <[email protected]> Cc: Daniel Lezcano <[email protected]> Link: http://lkml.kernel.org/r/7579471.4N90fYPQOK@wuerfel Signed-off-by: Thomas Gleixner <[email protected]>
2015-11-16clocksource/fsl: Avoid harmless 64-bit warningsArnd Bergmann1-2/+2
The ftm_clockevent_init passes the value of "~0UL" into a function that takes a 32-bit argument, which drops the upper 32 bits, as gcc warns about on ARM64: clocksource/fsl_ftm_timer.c: In function 'ftm_clockevent_init': clocksource/fsl_ftm_timer.c:206:13: warning: large integer implicitly truncated to unsigned type [-Woverflow] This was obviously unintended behavior, and is easily avoided by using '~0u' as the integer literal, because that is 32-bit wide on all architectures. Signed-off-by: Arnd Bergmann <[email protected]> Cc: [email protected] Cc: Xiubo Li <[email protected]> Cc: Shawn Guo <[email protected]> Cc: Sascha Hauer <[email protected]> Cc: Stefan Agner <[email protected]> Cc: Daniel Lezcano <[email protected]> Link: http://lkml.kernel.org/r/3990834.xnjhm37Grs@wuerfel Signed-off-by: Thomas Gleixner <[email protected]>
2015-11-16hwmon: (scpi) skip unsupported sensors properlySudeep Holla1-10/+11
Currently it's assumed that firmware exports only the class of sensors supported by the driver. However with newer firmware or SCPI protocol revision, support for newer classes of sensors can be present. The driver fails to probe with the following warning if an unsupported class of sensor is encountered in the firmware. sysfs: cannot create duplicate filename '/devices/platform/scpi/scpi:sensors/hwmon/hwmon0/' ------------[ cut here ]------------ WARNING: at fs/sysfs/dir.c:31 Modules linked in: CPU: 0 PID: 6 Comm: kworker/u12:0 Not tainted 4.3.0-rc7 #137 Hardware name: ARM Juno development board (r0) (DT) Workqueue: deferwq deferred_probe_work_func PC is at sysfs_warn_dup+0x54/0x78 LR is at sysfs_warn_dup+0x54/0x78 This patch fixes the above issue by skipping through the unsupported class of SCPI sensors. Fixes: 68acc77a2d51 ("hwmon: Support thermal zones registration for SCP temperature sensors") Fixes: ea98b29a05e9 ("hwmon: Support sensors exported via ARM SCP interface") Cc: Guenter Roeck <[email protected]> Reviewed-by: Punit Agrawal <[email protected]> Signed-off-by: Sudeep Holla <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2015-11-16hwmon: (scpi) add thermal-of dependencyArnd Bergmann1-0/+1
The newly added scpi thermal support is broken when the scpi driver is built-in but the thermal driver is a loadable module: drivers/built-in.o: In function `scpi_hwmon_probe': (.text+0x444d70): undefined reference to `thermal_zone_of_sensor_unregister' (.text+0x444d94): undefined reference to `thermal_zone_of_sensor_register' drivers/built-in.o: In function `scpi_hwmon_remove': (text+0x444e6c): undefined reference to `thermal_zone_of_sensor_unregister' This uses the same Kconfig trick that we have in a couple of other drivers already to ensure we can only select the driver in valid configurations when either THERMAL_OF is disabled, or when with a dependency on CONFIG_THERMAL that can force SCPI to be a loadable module in the case I was hitting. Signed-off-by: Arnd Bergmann <[email protected]> Fixes: 68acc77a2d51 ("hwmon: Support thermal zones registration for SCP temperature sensors") Signed-off-by: Guenter Roeck <[email protected]>
2015-11-16ext2, ext4: warn when mounting with dax enabledDan Williams2-1/+7
Similar to XFS warn when mounting DAX while it is still considered under development. Also, aspects of the DAX implementation, for example synchronization against multiple faults and faults causing block allocation, depend on the correct implementation in the filesystem. The maturity of a given DAX implementation is filesystem specific. Cc: <[email protected]> Cc: "Theodore Ts'o" <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: [email protected] Cc: Kirill A. Shutemov <[email protected]> Reported-by: Dave Chinner <[email protected]> Acked-by: Jan Kara <[email protected]> Signed-off-by: Dan Williams <[email protected]>
2015-11-16USB: qcserial: Fix support for HP lt4112 LTE/HSPA+ Gobi 4G ModemBjørn Mork1-20/+34
The DEVICE_HWI type was added under the faulty assumption that Huawei devices based on Qualcomm chipsets and firmware use the static USB interface numbering known from Gobi devices. But this model does not apply to Huawei devices like the HP branded lt4112 (Huawei me906e). Huawei firmwares will dynamically assign interface numbers. Functions are renumbered when the firmware is reconfigured. Fix by changing the DEVICE_HWI type to use a simplified version of Huawei's subclass + protocol scheme: Blacklisting known network interface combinations and assuming the rest are serial. Reported-and-tested-by: Muri Nicanor <[email protected]> Tested-by: Martin Hauke <[email protected]> Cc: <[email protected]> Fixes: e7181d005e84 ("USB: qcserial: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem") Signed-off-by: Bjørn Mork <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2015-11-17drivers: sh: Get rid of CONFIG_ARCH_SHMOBILE_MULTIGeert Uytterhoeven1-1/+1
Shmobile is all multiplatform these days, so get rid of the reference to CONFIG_ARCH_SHMOBILE_MULTI. Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Simon Horman <[email protected]>
2015-11-16usb: phy: omap-otg: fix uninitialized pointerAaro Koskinen1-1/+1
otg_dev->extcon was referenced before otg_dev was initialized. Fix. Cc: <[email protected]> # v4.3 Fixes: a2fd2423240f ("usb: phy: omap-otg: Replace deprecated API of extcon") Reviewed-by: Chanwoo Choi <[email protected]> Signed-off-by: Aaro Koskinen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2015-11-16usb: musb: core: fix order of arguments to ulpi write callbackUwe Kleine-König1-5/+5
There is a bit of a mess in the order of arguments to the ulpi write callback. There is int ulpi_write(struct ulpi *ulpi, u8 addr, u8 val) in drivers/usb/common/ulpi.c; struct usb_phy_io_ops { ... int (*write)(struct usb_phy *x, u32 val, u32 reg); } in include/linux/usb/phy.h. The callback registered by the musb driver has to comply to the latter, but up to now had "offset" first which effectively made the function broken for correct users. So flip the order and while at it also switch to the parameter names of struct usb_phy_io_ops's write. Fixes: ffb865b1e460 ("usb: musb: add ulpi access operations") Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2015-11-16usb: dwc3: pci: add support for Intel Broxton SOCHeikki Krogerus1-0/+4
PCI IDs for Broxton based platforms. Signed-off-by: Heikki Krogerus <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2015-11-16drm/amdgpu: update pd while updating vm as wellChunming Zhou1-0/+3
Change-Id: I93a861cd6707f7d91672b9e19757cc50008cd7a2 Signed-off-by: Chunming Zhou <[email protected]> Reviewed-by: Christian König <[email protected]>
2015-11-16drm/amdgpu: fix handling order in scheduler CSChristian König1-5/+5
We need to clear parser.ibs and num_ibs before amd_sched_fence_create, otherwise the IB could be freed twice if fence creates fails. Signed-off-by: Christian König <[email protected]> Reviewed-by: Chunming Zhou <[email protected]>
2015-11-16drm/amdgpu: fix incorrect mutex usage v3Christian König5-48/+37
Before this patch the scheduler fence was created when we push the job into the queue, so we could only get the fence after pushing it. The mutex now was necessary to prevent the thread pushing the jobs to the hardware from running faster than the thread pushing the jobs into the queue. Otherwise the thread pushing jobs into the queue would have accessed possible freed up memory when it tries to get a reference to the fence. So what you get in the end is thread A: mutex_lock(&job->lock); ... Kick of thread B. ... mutex_unlock(&job->lock); And thread B: mutex_lock(&job->lock); .... mutex_unlock(&job->lock); kfree(job); I'm actually not sure if I'm still up to date on this, but this usage pattern used to be not allowed with mutexes. See here as well https://lwn.net/Articles/575460/. v2: remove unrelated changes, fix missing owner v3: rebased, add more commit message Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]>
2015-11-16drm/amdgpu: cleanup scheduler fence get/put danceChristian König2-2/+0
The code was correct, but getting two references when the ownership is linearly moved on is a bit awkward and just overhead. Signed: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]>
2015-11-16drm/amdgpu: add command submission workflow tracepointChunming Zhou5-4/+76
OGL needs these tracepoints to investigate performance issue. Change-Id: I5e58187d061253f7d665dfce8e4e163ba91d3e2b Signed-off-by: Chunming Zhou <[email protected]>
2015-11-16drm/amdgpu: update Fiji's tiling mode tableFlora Cui1-1/+291
Change-Id: I925c15015390113f7e27746ec5751eaa6a92c2a7 Signed-off-by: Flora Cui <[email protected]> Reviewed-by: Alex Deucher <[email protected]>
2015-11-16drm/amdgpu: fix bug that can't enter thermal interrupt for bonaire.Rex Zhu1-4/+4
Set reversed bit to enable/disable thermal interrupt. Signed-off-by: Rex Zhu <[email protected]> Reviewed-by: Jammy Zhou <[email protected]>
2015-11-16drm/amdgpu: fix seq_printf format stringArnd Bergmann1-3/+3
The amdgpu driver has a debugfs interface that shows the amount of VRAM in use, but the newly added code causes a build error on all 32-bit architectures: drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:1076:17: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'long long int' [-Wformat=] This fixes the format string to use "%llu" for printing 64-bit numbers, which works everywhere, as long as we also cast to 'u64'. Unlike atomic64_t, u64 is defined as 'unsigned long long' on all architectures. Signed-off-by: Arnd Bergmann <[email protected]> Fixes: a2ef8a974931 ("drm/amdgpu: add vram usage into debugfs") Signed-off-by: Alex Deucher <[email protected]>
2015-11-16drm/radeon: fix quirk for MSI R7 370 Armor 2XMaxim Sheviakov1-1/+1
There was a typo in the original. bug: https://bugs.freedesktop.org/show_bug.cgi?id=92865 Signed-off-by: Maxim Sheviakov <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-11-16drm/amdgpu: Fix default page access routingJay Cornwall2-0/+2
The VM default page (used when a VM translation fails) is allocated in system memory. The VM is misconfigured to interpret the physical address as referencing a VRAM physical page. Route default page accesses to system memory. Reviewed-by: Christian König <[email protected]> Signed-off-by: Jay Cornwall <[email protected]> Cc: <[email protected]> # v4.2+ Signed-off-by: Alex Deucher <[email protected]>
2015-11-16drm/radeon: unconditionally set sysfs_initializedAlex Deucher1-2/+1
Avoids spew on resume for systems where sysfs may fail even on init. bug: https://bugzilla.kernel.org/show_bug.cgi?id=106851 Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2015-11-16drm/amdgpu: cleanup amdgpu_cs_parser handlingChristian König2-60/+33
No need any more to allocate that structure dynamically, just put it on the stack. This is a start to cleanup some of the scheduler fallouts. Signed-off-by: Christian König <[email protected]> Reviewed-by: Junwei Zhang <[email protected]> Reviewed-by: Alex Deucher <[email protected]>
2015-11-16drm/amdgpu: fix leaking the IBs on errorChristian König1-13/+12
Fixing a memory leak when the scheduler is enabled. Signed-off-by: Christian König <[email protected]> Reviewed-by: Junwei Zhang <[email protected]> Reviewed-by: Alex Deucher <[email protected]>
2015-11-16drm/amd: add kmem cache for sched fenceChunming Zhou3-2/+23
Change-Id: I45bb8ff10ef05dc3b15e31a77fbcf31117705f11 Signed-off-by: Chunming Zhou <[email protected]> Reviewed-by: Christian König <[email protected]>
2015-11-16drm/amdgpu: add kmem cache for amdgpu fenceChunming Zhou1-2/+20
Change-Id: I5ad8dd156ccf27a6f18004aa0a215a0925b6e67b Signed-off-by: Chunming Zhou <[email protected]> Reviewed-by: Christian König <[email protected]>
2015-11-16drm/amdgpu: update fiji_mgcg_cgcg_init tableFlora Cui1-5/+0
Change-Id: If44b8057741c78208f1976f60f31b535c944d0bd Signed-off-by: Flora Cui <[email protected]> Reviewed-by: Jammy Zhou <[email protected]>
2015-11-16drm/amdgpu: use common fence for amdgpu_vm_fenceChristian König3-8/+8
Just cleanup the function parameters. Signed-off-by: Christian König <[email protected]> Reviewed-by: Chunming Zhou <[email protected]> Reviewed-by: Alex Deucher <[email protected]>
2015-11-16drm/amdgpu: use fence_is_later() for vm_flush as well v2Christian König1-12/+9
v2: remove superfluous check Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> (v1) Reviewed-by: Chunming Zhou <[email protected]>
2015-11-16drm/amdgpu: use a timer for fence fallbackChristian König2-46/+35
Less overhead than a work item and also adds proper cleanup handling. Signed-off-by: Christian König <[email protected]> Reviewed-by: Chunming Zhou <[email protected]> Acked-by: Alex Deucher <[email protected]>
2015-11-16drm/amdgpu: remove fence trace pointsChristian König2-44/+0
Mostly unused and replaced by the common trace points. Signed-off-by: Christian König <[email protected]> Reviewed-by: Chunming Zhou <[email protected]> Acked-by: Alex Deucher <[email protected]>
2015-11-16drm/amdgpu: update Fiji's mmPA_SC_RASTER_CONFIG valueFlora Cui1-1/+4
Change-Id: I6d138306a878450e5bf8a77a2f1aacc380a39fe5 Signed-off-by: Flora Cui <[email protected]> Reviewed-by: Alex Deucher <[email protected]>
2015-11-16drm/radeon: Only prompt for enabling PAT when we'd allow write-combiningMichel Dänzer1-2/+3
No use bothering users about this for whom we disable write-combining for other reasons anyway. Reviewed-by: Christian König <[email protected]> Signed-off-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-11-16drm/radeon: Always disable RADEON_GEM_GTT_UC along with RADEON_GEM_GTT_WCMichel Dänzer1-2/+2
Write-combining is a CPU feature. From the GPU POV, these both simply mean no GPU<->CPU cache coherency. Reviewed-by: Christian König <[email protected]> Signed-off-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-11-16drm/radeon: Disable uncacheable CPU mappings of GTT with RV6xxMichel Dänzer1-0/+6
They reportedly cause random GPU hangs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91268 Reviewed-by: Christian König <[email protected]> Cc: [email protected] Signed-off-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-11-16dm thin: restore requested 'error_if_no_space' setting on OODS to WRITE ↵Mike Snitzer1-0/+1
transition A thin-pool that is in out-of-data-space (OODS) mode may transition back to write mode -- without the admin adding more space to the thin-pool -- if/when blocks are released (either by deleting thin devices or discarding provisioned blocks). But as part of the thin-pool's earlier transition to out-of-data-space mode the thin-pool may have set the 'error_if_no_space' flag to true if the no_space_timeout expires without more space having been made available. That implementation detail, of changing the pool's error_if_no_space setting, needs to be reset back to the default that the user specified when the thin-pool's table was loaded. Otherwise we'll drop the user requested behaviour on the floor when this out-of-data-space to write mode transition occurs. Reported-by: Vivek Goyal <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Acked-by: Joe Thornber <[email protected]> Fixes: 2c43fd26e4 ("dm thin: fix missing out-of-data-space to write mode transition if blocks are released") Cc: [email protected]
2015-11-16drm/i915: get runtime PM reference around GEM set_caching IOCTLImre Deak1-1/+7
After Damien's D3 fix I started to get runtime suspend residency for the first time and that revealed a breakage on the set_caching IOCTL path that accesses the HW but doesn't take an RPM ref. Fix this up. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Cc: [email protected] Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2015-11-16drm/i915: Fix GT frequency roundingMika Kuoppala1-3/+5
When we set and later readback a frequency value through sysfs interface, igt/pm_rpm assumes that we get same value back if it matches hw granularity. On bxt we have found out that this is not always the case. Currently frequency - hw ratio - frequency conversions round down, with few exceptions on platforms that have more specific conversions. On bxt the supported range can be for example from 100Mhz to 650Mhz. Midpoint is then calculated by test to be 375 which pm_rps uses to find a closest hw supported frequency. That is 366 (ratio 22), which it then writes back. But as the rounding down kicks in, driver actually sets 350 instead of 366, as 366 is 2/3 below 22 * 50/3. Fix this by rounding to closest instead of rounding down in freq-ratio-freq conversions. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92768 Testcase: igt/pm_rps/basic-api Tested-by: Bob Paauwe <[email protected]> Cc: Bob Paauwe <[email protected]> Signed-off-by: Imre Deak <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2015-11-16USB: ti_usb_3410_5052: Add Honeywell HGI80 IDDavid Woodhouse2-0/+6
The Honeywell HGI80 is a wireless interface to the evohome connected thermostat. It uses a TI 3410 USB-serial port. Signed-off-by: David Woodhouse <[email protected]> Cc: [email protected] Signed-off-by: Johan Hovold <[email protected]>
2015-11-16USB: serial: option: add support for Novatel MiFi USB620LAleksander Morgado1-0/+2
Also known as Verizon U620L. The device is modeswitched from 1410:9020 to 1410:9022 by selecting the 4th USB configuration: $ sudo usb_modeswitch –v 0x1410 –p 0x9020 –u 4 This configuration provides a ECM interface as well as TTYs ('Enterprise Mode' according to the U620 Linux integration guide). Signed-off-by: Aleksander Morgado <[email protected]> Cc: stable <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2015-11-16USB: qcserial: Add support for Quectel EC20 Mini PCIe modulePetr Štetiar1-0/+40
It seems like this device has same vendor and product IDs as G2K devices, but it has different number of interfaces(4 vs 5) and also different interface layout which makes it currently unusable: usbcore: registered new interface driver qcserial usbserial: USB Serial support registered for Qualcomm USB modem usb 2-1.2: unknown number of interfaces: 5 lsusb output: Bus 002 Device 003: ID 05c6:9215 Qualcomm, Inc. Acer Gobi 2000 Wireless Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x05c6 Qualcomm, Inc. idProduct 0x9215 Acer Gobi 2000 Wireless Modem bcdDevice 2.32 iManufacturer 1 Quectel iProduct 2 Quectel LTE Module iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 209 bNumInterfaces 5 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Signed-off-by: Petr Štetiar <[email protected]> Cc: stable <[email protected]> [johan: rename define and add comment ] Signed-off-by: Johan Hovold <[email protected]>
2015-11-16drm/i915: quirk backlight present on Macbook 4, 1Jani Nikula1-0/+3
Unsurprisingly macbooks have backlights, just the VBT doesn't seem to know it in this case. Reported-and-tested-by: Daniel Nicoletti <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88325 Fixes: c675949ec58c ("drm/i915: do not setup backlight if not available according to VBT") Cc: [email protected] # v3.15+ Reviewed-by: Ander Conselvan de Oliveira <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2015-11-16drm/i915: Fix crtc_y assignment in intel_find_initial_plane_obj()Ville Syrjälä1-2/+4
Let's set crtc_y to 0 instead of setting src_y twice. Multiple assignments in one statement is a good way to hide bugs. Please don't do that. Cc: Maarten Lankhorst <[email protected]> Fixes: be5651f2d581 ("drm/i915: Update missing properties in find_initial_plane_obj") Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2015-11-16ipmi watchdog : add panic_wdt_timeout parameterJean-Yves Faye2-3/+12
In order to allow panic actions to be processed, the ipmi watchdog driver sets a new timeout value on panic. The 255s timeout was designed to allow kdump and others actions on panic, as in http://lkml.iu.edu/hypermail/linux/kernel/0711.3/0258.html This is counter-intuitive for a end-user who sets watchdog timeout value to something like 30s and who expects BMC to reset the system within 30s of a panic. This commit allows user to configure the timeout on panic. Signed-off-by: Jean-Yves Faye <[email protected]> Signed-off-by: Corey Minyard <[email protected]>
2015-11-16s390: remove SALIPL loaderHeiko Carstens1-79/+8
There is no known user, therefore remove the code. Acked-by: Rob Van Der Heij <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2015-11-16s390: wire up mlock2 system callHeiko Carstens3-1/+4
Passes mlock2-tests test case in 64 bit and compat mode. Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2015-11-16MIPS: Fix flood of warnings about comparsion being always true.Ralf Baechle1-1/+2
./arch/mips/include/asm/page.h:204:13: warning: comparison of unsigned expression &gt;= 0 is always true [-Wtype-limits] The default value of ARCH_PFN_OFFSET is 0 thus triggering this warning for all platforms using the default value. Signed-off-by: Ralf Baechle <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.