- 14 Jan, 2016 40 commits
-
-
Mike Snitzer authored
commit 172c2386 upstream. 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 <vgoyal@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Acked-by:
Joe Thornber <ejt@redhat.com> Fixes: 2c43fd26 ("dm thin: fix missing out-of-data-space to write mode transition if blocks are released") Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Takashi Iwai authored
commit 86f799b8 upstream. Dell Latitude E6440 (1028:05bd) needs the same fixup as applied to other Latitude E7xxx models for the click noise due to the recent power-saving changes. Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=954876Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Sabrina Dubroca authored
commit e639b8d8 upstream. Reset pskb in macvlan_handle_frame in case skb_share_check returned a clone. Fixes: 8a4eb573 ("net: introduce rx_handler results and logic around that") Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Sabrina Dubroca authored
commit a534dc52 upstream. ipvlan_handle_frame is a rx_handler, and when it returns a value other than RX_HANDLER_CONSUMED (here, NET_RX_DROP aka RX_HANDLER_ANOTHER), __netif_receive_skb_core expects that the skb still exists and will process it further, but we just freed it. Fixes: 2ad7bf36 ("ipvlan: Initial check-in of the IPVLAN driver.") Signed-off-by:
-
Sabrina Dubroca authored
commit cf554ada upstream. Pass a **skb to ipvlan_rcv_frame so that if skb_share_check returns a new skb, we actually use it during further processing. It's safe to ignore the new skb in the ipvlan_xmit_* functions, because they call ipvlan_rcv_frame with local == true, so that dev_forward_skb is called and always takes ownership of the skb. Fixes: 2ad7bf36 ("ipvlan: Initial check-in of the IPVLAN driver.") Signed-off-by:
-
Geert Uytterhoeven authored
commit cf897526 upstream. fs/cachefiles/rdwr.c: In function ‘cachefiles_write_page’: fs/cachefiles/rdwr.c:882: warning: ‘ret’ may be used uninitialized in this function If the jump to label "error" is taken, "ret" will indeed be uninitialized, and random stack data may be printed by the debug code. Fixes: 102f4d90 ("FS-Cache: Handle a write to the page immediately beyond the EOF marker") Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Brian Norris authored
commit 9ca641b0 upstream. 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 6b0d9a84 ("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: 72ea4036 ("mtd: nand: added nand_shutdown") Reported-by:
Andrew E. Mileski <andrewm@isoar.ca> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: Andrew E. Mileski <andrewm@isoar.ca> Acked-by:
Scott Branden <sbranden@broadcom.com> Reviewed-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
-
Noa Osherovich authored
commit d49c2197 upstream. The err variable wasn't set with the correct error value in some cases. Fixes: 47605df9 ('mlx4: Modify proxy/tunnel QP mechanism [..]') Signed-off-by:
Noa Osherovich <noaos@mellanox.com> Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
-
Adrian Hunter authored
commit e266a753 upstream. Commit 4598a0a6 ("perf symbols: Improve DSO long names lookup speed with rbtree") Added a tree to lookup dsos by long name. That tree gets corrupted whenever a dso long name is changed because the tree is not updated. One effect of that is buildid-list does not work with the 'with-hits' option because dso lookup fails and results in two structs for the same dso. The first has the buildid but no hits, the second has hits but no buildid. e.g. Before: $ tools/perf/perf record ls arch certs CREDITS Documentation firmware include ipc Kconfig lib Makefile net REPORTING-BUGS scripts sound usr block COPYING crypto drivers fs init Kbuild kernel MAINTAINERS mm README samples security tools virt [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.012 MB perf.data (11 samples) ] $ tools/perf/perf buildid-list 574da826c66538a8d9060d393a8866289bd06005 [kernel.kallsyms] 30c94dc66a1fe95180c3d68d2b89e576d5ae213c /lib/x86_64-linux-gnu/libc-2.19.so $ tools/perf/perf buildid-list -H 574da826c66538a8d9060d393a8866289bd06005 [kernel.kallsyms] 0000000000000000000000000000000000000000 /lib/x86_64-linux-gnu/libc-2.19.so After: $ tools/perf/perf buildid-list -H 574da826c66538a8d9060d393a8866289bd06005 [kernel.kallsyms] 30c94dc66a1fe95180c3d68d2b89e576d5ae213c /lib/x86_64-linux-gnu/libc-2.19.so The fix is to record the root of the tree on the dso so that dso__set_long_name() can update the tree when the long name changes. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Tested-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Don Zickus <dzickus@redhat.com> Cc: Douglas Hatch <doug.hatch@hp.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Scott J Norton <scott.norton@hp.com> Cc: Waiman Long <Waiman.Long@hp.com> Fixes: 4598a0a6 ("perf symbols: Improve DSO long names lookup speed with rbtree") Link: http://lkml.kernel.org/r/1447408112-1920-2-git-send-email-adrian.hunter@intel.comSigned-off-by:
-
Arnd Bergmann authored
commit 49e4a229 upstream. Building dwmac-ipq806x on a 64-bit architecture produces a harmless warning from gcc: stmmac/dwmac-ipq806x.c: In function 'ipq806x_gmac_probe': include/linux/bitops.h:6:19: warning: overflow in implicit constant conversion [-Woverflow] val = QSGMII_PHY_CDR_EN | stmmac/dwmac-ipq806x.c:333:8: note: in expansion of macro 'QSGMII_PHY_CDR_EN' #define QSGMII_PHY_CDR_EN BIT(0) #define BIT(nr) (1UL << (nr)) This is a result of the type conversion rules in C, when we take the logical OR of multiple different types. In particular, we have and unsigned long QSGMII_PHY_CDR_EN == BIT(0) == (1ul << 0) == 0x0000000000000001ul and a signed int 0xC << QSGMII_PHY_TX_DRV_AMP_OFFSET == 0xc0000000 which together gives a signed long value 0xffffffffc0000001l and when this is passed into a function that takes an unsigned int type, gcc warns about the signed overflow and the loss of the upper 32-bits that are all ones. This patch adds 'ul' type modifiers to the literal numbers passed in here, so now the expression remains an 'unsigned long' with the upper bits all zero, and that avoids the signed overflow and the warning. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: b1c17215 ("stmmac: add ipq806x glue layer") Signed-off-by:
-
Luca Porzio authored
commit d3df0465 upstream. Anytime a write operation is performed with Reliable Write flag enabled, the eMMC device is enforced to bypass the cache and do a write to the underling NVM device by Jedec specification; this causes a performance penalty since write operations can't be optimized by the device cache. In our tests, we replayed a typical mobile daily trace pattern and found ~9% overall time reduction in trace replay by using this patch. Also the write ops within 4KB~64KB chunk size range get a 40~60% performance improvement by using the patch (as this range of write chunks are the ones affected by REQ_META). This patch has been discussed in the Mobile & Embedded Linux Storage Forum and it's the results of feedbacks from many people. We also checked with fsdevl and f2fs mailing list developers that this change in the usage of REQ_META is not affecting FS behavior and we got positive feedbacks. Reporting here the feedbacks: http://comments.gmane.org/gmane.linux.file-systems/97219 http://thread.gmane.org/gmane.linux.file-systems.f2fs/3178/focus=3183Signed-off-by:
Bruce Ford <bford@micron.com> Signed-off-by:
Luca Porzio <lporzio@micron.com> Fixes: ce39f9d1 ("mmc: support packed write command for eMMC4.5 devices") Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Helge Deller authored
commit dcbf0d29 upstream. Drop the MADV_xxK_PAGES flags, which were never used and were from a proposed API which was never integrated into the generic Linux kernel code. Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Richard Weinberger authored
commit 9d8a7652 upstream. sigsuspend() is nowhere used except in signal.c itself, so we can mark it static do not pollute the global namespace. But this patch is more than a boring cleanup patch, it fixes a real issue on UserModeLinux. UML has a special console driver to display ttys using xterm, or other terminal emulators, on the host side. Vegard reported that sometimes UML is unable to spawn a xterm and he's facing the following warning: WARNING: CPU: 0 PID: 908 at include/linux/thread_info.h:128 sigsuspend+0xab/0xc0() It turned out that this warning makes absolutely no sense as the UML xterm code calls sigsuspend() on the host side, at least it tries. But as the kernel itself offers a sigsuspend() symbol the linker choose this one instead of the glibc wrapper. Interestingly this code used to work since ever but always blocked signals on the wrong side. Some recent kernel change made the WARN_ON() trigger and uncovered the bug. It is a wonderful example of how much works by chance on computers. :-) Fixes: 68f3f16d ("new helper: sigsuspend()") Signed-off-by:
Richard Weinberger <richard@nod.at> Reported-by:
Vegard Nossum <vegard.nossum@oracle.com> Tested-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
OGAWA Hirofumi authored
commit 928a4771 upstream. For the root directory, . and .. are faked (using dir_emit_dots()) and ctx->pos is reset from 2 to 0. A corrupted root directory could cause fat_get_entry() to fail, but ->iterate() (fat_readdir()) reports progress to the VFS (with ctx->pos rewound to 0), so any following calls to ->iterate() continue to return the same entries again and again. The result is that userspace will never see the end of the directory, causing e.g. 'ls' to hang in a getdents() loop. [hirofumi@mail.parknet.co.jp: cleanup and make sure to correct fake_offset] Reported-by:
Richard Weinberger <richard.weinberger@gmail.com> Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
-
Mathias Nyman authored
commit dad67d5f upstream. Clear device initiated resume variables once device is fully up and running in U0 state. Resume needs to be signaled for 20ms for usb2 devices before they can be moved to U0 state. An interrupt is triggered if a device initiates resume. As we handle the event in interrupt context we can not sleep for 20ms, so we instead set a resume flag, a timestamp, and start the roothub polling. The roothub code will later move the port to U0 when it finds a port in resume state with the resume flag set, and timestamp passed by 20ms. A host initiated resume is however not done in interrupt context, and host initiated resume code will directly signal resume, wait 20ms and then move the port to U0. These two codepaths can race, if we are in the middle of a host initated resume, while sleeping for 20ms, we may handle a port event and find the port in resume state. The port event handling code will assume the resume was device initiated and set the resume flag and timestamp. Root hub code will however not catch the port in resume state again as the host initated resume code has already moved the port to U0. The resume flag and timestamp will remain set for this port preventing port from suspending again (LPM setting port to U3) Fix this for now by always clearing the device initated resume parameters once port is in U0 Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> [ kamal: backport to 4.2: context ] Signed-off-by:
-
Li Jun authored
commit 251b3c8b upstream. Since the ci->role will be set after the host role start is complete, there will be nobody cared irq during start host if usb irq enabled. This error can be reproduced on i.mx6 sololite EVK board by: 1. disable otg id irq(IDIE) and disable all real otg properties of usbotg1 in dts. 2. boot up the board with ID cable and usb device connected. 3. echo gadget > /sys/kernel/debug/ci_hdrc.0/role 4. echo host > /sys/kernel/debug/ci_hdrc.0/role 5. irq 212: nobody cared. Signed-off-by:
Li Jun <jun.li@freescale.com> Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
-
Lorenzo Pieralisi authored
commit de818bd4 upstream. The function graph tracer adds instrumentation that is required to trace both entry and exit of a function. In particular the function graph tracer updates the "return address" of a function in order to insert a trace callback on function exit. Kernel power management functions like cpu_suspend() are called upon power down entry with functions called "finishers" that are in turn called to trigger the power down sequence but they may not return to the kernel through the normal return path. When the core resumes from low-power it returns to the cpu_suspend() function through the cpu_resume path, which leaves the trace stack frame set-up by the function tracer in an incosistent state upon return to the kernel when tracing is enabled. This patch fixes the issue by pausing/resuming the function graph tracer on the thread executing cpu_suspend() (ie the function call that subsequently triggers the "suspend finishers"), so that the function graph tracer state is kept consistent across functions that enter power down states and never return by effectively disabling graph tracer while they are executing. Fixes: 819e50e2 ("arm64: Add ftrace support") Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reported-by:
Catalin Marinas <catalin.marinas@arm.com> Reported-by:
AKASHI Takahiro <takahiro.akashi@linaro.org> Suggested-by:
Steven Rostedt <rostedt@goodmis.org> Acked-by:
-
Ville Syrjälä authored
commit 76dc3769 upstream. We try to convert the old way of of specifying fb tiling (obj->tiling) into the new fb modifiers. We store the result in the passed in mode_cmd structure. But that structure comes directly from the addfb2 ioctl, and gets copied back out to userspace, which means we're clobbering the modifiers that the user provided (all 0 since the DRM_MODE_FB_MODIFIERS flag wasn't even set by the user). Hence if the user reuses the struct for another addfb2, the ioctl will be rejected since it's now asking for some modifiers w/o the flag set. Fix the problem by making a copy of the user provided structure. We can play any games we want with the copy. IGT-Version: 1.12-git (x86_64) (Linux: 4.4.0-rc1-stereo+ x86_64) ... Subtest basic-X-tiled: SUCCESS (0.001s) Test assertion failure function pitch_tests, file kms_addfb_basic.c:167: Failed assertion: drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f) == 0 Last errno: 22, Invalid argument Stack trace: #0 [__igt_fail_assert+0x101] #1 [pitch_tests+0x619] #2 [__real_main426+0x2f] #3 [main+0x23] #4 [__libc_start_main+0xf0] #5 [_start+0x29] #6 [<unknown>+0x29] Subtest framebuffer-vs-set-tiling failed. **** DEBUG **** Test assertion failure function pitch_tests, file kms_addfb_basic.c:167: Failed assertion: drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f) == 0 Last errno: 22, Invalid argument **** END **** Subtest framebuffer-vs-set-tiling: FAIL (0.003s) ... IGT-Version: 1.12-git (x86_64) (Linux: 4.4.0-rc1-stereo+ x86_64) Subtest framebuffer-vs-set-tiling: SUCCESS (0.000s) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 2a80eada ("drm/i915: Add fb format modifier support") Testcase: igt/kms_addfb_basic/clobbered-modifier Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447261890-3960-1-git-send-email-ville.syrjala@linux.intel.comSigned-off-by:
-
Ard Biesheuvel authored
commit 4fee9f36 upstream. When booting a 64k pages kernel that is built with CONFIG_DEBUG_RODATA and resides at an offset that is not a multiple of 512 MB, the rounding that occurs in __map_memblock() and fixup_executable() results in incorrect regions being mapped. The following snippet from /sys/kernel/debug/kernel_page_tables shows how, when the kernel is loaded 2 MB above the base of DRAM at 0x40000000, the first 2 MB of memory (which may be inaccessible from non-secure EL1 or just reserved by the firmware) is inadvertently mapped into the end of the module region. ---[ Modules start ]--- 0xfffffdffffe00000-0xfffffe0000000000 2M RW NX ... UXN MEM/NORMAL ---[ Modules end ]--- ---[ Kernel Mapping ]--- 0xfffffe0000000000-0xfffffe0000090000 576K RW NX ... UXN MEM/NORMAL 0xfffffe0000090000-0xfffffe0000200000 1472K ro x ... UXN MEM/NORMAL 0xfffffe0000200000-0xfffffe0000800000 6M ro x ... UXN MEM/NORMAL 0xfffffe0000800000-0xfffffe0000810000 64K ro x ... UXN MEM/NORMAL 0xfffffe0000810000-0xfffffe0000a00000 1984K RW NX ... UXN MEM/NORMAL 0xfffffe0000a00000-0xfffffe00ffe00000 4084M RW NX ... UXN MEM/NORMAL The same issue is likely to occur on 16k pages kernels whose load address is not a multiple of 32 MB (i.e., SECTION_SIZE). So round to SWAPPER_BLOCK_SIZE instead of SECTION_SIZE. Fixes: da141706 ("arm64: add better page protections to arm64") Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by:
Mark Rutland <mark.rutland@arm.com> Acked-by:
Laura Abbott <labbott@redhat.com> Signed-off-by:
-
Dan Williams authored
commit ef83b6e8 upstream. 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: "Theodore Ts'o" <tytso@mit.edu> Cc: Matthew Wilcox <willy@linux.intel.com> Cc: linux-ext4@vger.kernel.org Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reported-by:
Dave Chinner <david@fromorbit.com> Acked-by:
Jan Kara <jack@suse.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Bjørn Mork authored
commit 59536da3 upstream. 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 <muri+libqmi@immerda.ch> Tested-by:
Martin Hauke <mardnh@gmx.de> Fixes: e7181d00 ("USB: qcserial: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem") Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Jay Cornwall authored
commit a80b3047 upstream. 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 <christian.koenig@amd.com> Signed-off-by:
Jay Cornwall <jay@jcornwall.me> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 24dd2f64 upstream. Avoids spew on resume for systems where sysfs may fail even on init. bug: https://bugzilla.kernel.org/show_bug.cgi?id=106851Signed-off-by:
-
Michel Dänzer authored
commit 96ea47c0 upstream. They reportedly cause random GPU hangs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91268Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Imre Deak authored
commit fd0fe6ac upstream. 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 <imre.deak@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446665132-22491-1-git-send-email-imre.deak@intel.comSigned-off-by:
-
Jani Nikula authored
commit 1b9448b0 upstream. Unsurprisingly macbooks have backlights, just the VBT doesn't seem to know it in this case. Reported-and-tested-by:
Daniel Nicoletti <dantti12@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88325 Fixes: c675949e ("drm/i915: do not setup backlight if not available according to VBT") Reviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
-
Corey Minyard authored
commit 0cfec916 upstream. The timer and thread were not being started for internal messages, so in interrupt mode if something hung the timer would never go off and clean things up. Factor out the internal message sending and start the timer for those messages, too. Signed-off-by:
Corey Minyard <cminyard@mvista.com> Tested-by:
Gouji, Masayuki <gouji.masayuki@jp.fujitsu.com> Signed-off-by:
-
Thomas Betker authored
commit a57f8dac upstream. The scaling factor for VREFN is 3.0/4096 (not 1.0/4096), just as for VREFP. This is not immediately obvious from the specification (Xilinx UG480), but has been confirmed by Xilinx support. Suggested-by:
Hartmut Knaack <knaack.h@gmx.de> Signed-off-by:
Thomas Betker <thomas.betker@rohde-schwarz.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Chris Lesiak authored
commit 0d2f6fd3 upstream. The Silicon Labs Si7013, Si7020, and Si7021 family of I2C humidity and temperature sensors deliver 16 bit data high byte first. See the datasheet available at: https://www.silabs.com/Support%20Documents%2fTechnicalDocs%2fSi7020-A20.pdf But as documented in Documentation/i2c/smbus-protocol, i2c_smbus_read_word_data() expects the low byte first. Change the driver to use i2c_smbus_read_word_swapped to get correct byte order. Signed-off-by:
Chris Lesiak <chris.lesiak@licor.com> Signed-off-by:
-
Tadeusz Struk authored
commit 176155da upstream. Bugfix - don't dereference userspace pointer. Signed-off-by:
Tadeusz Struk <tadeusz.struk@intel.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Adrian Hunter authored
commit d2302933 upstream. mmc_select_hs400() calls __mmc_switch() which checks the switch is successful using CMD13 (SEND_STATUS). The problem is that it does that using the timing settings of the previous mode. That is prone to error, especially when switching from HS to HS400 because the timing parameters for HS mode are tighter than the timing parameters for HS400 mode. In the case when CMD13 polling is used (i.e. not MMC_CAP_WAIT_WHILE_BUSY) with the switch command, it must be assumed that using different modes on the card and host must work. However in the case when CMD13 polling is not used (i.e. MMC_CAP_WAIT_WHILE_BUSY) mmc_select_hs400() can be made more reliable by setting the host to the correct timing before sending CMD13. This patch does that. Signed-off-by:
Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by:
-
Adrian Hunter authored
commit 974007aa upstream. Move the mmc_switch_status() function in preparation for calling it in mmc_select_hs400(). Signed-off-by:
-
Adrian Hunter authored
commit 51b12f77 upstream. mmc_select_hs400() begins with the card and host in HS200 mode. Therefore, any commands sent to the card should use HS200 timing. It is incorrect to set the host to High Speed (HS) timing before sending the switch command. Doing so is unreliable because the timing parameters for HS mode are tighter than the timing parameters for HS200 mode. Thus the HS timings should be set only after the card has switched mode. However, it is not unreasonable first to reduce the frequency to the HS mode frequency, which should make the switch command and subsequent CMD13 commands more reliable. This patch does that. Signed-off-by:
-
Adrian Hunter authored
commit 1815e61b upstream. Currently mmc_select_hs200() uses __mmc_switch() which checks the success of the switch to HS200 mode using CMD13 (SEND_STATUS). The problem is that it does that using the timing settings of legacy mode. That is prone to error, not least because the timing parameters for legacy mode are tighter than the timing parameters for HS200 mode. In the case when CMD13 polling is used (i.e. not MMC_CAP_WAIT_WHILE_BUSY) with the switch command, it must be assumed that using different modes on the card and host must work. However in the case when CMD13 polling is not used (i.e. MMC_CAP_WAIT_WHILE_BUSY) mmc_select_hs200() can be made more reliable by setting the host to the correct timing before sending CMD13. This patch does that. A complication is that the caller, mmc_select_timing(), will ignore a switch error (indicated by -EBADMSG), assume the old mode is valid and continue, so the old timing must be restored in that case. Signed-off-by:
-
Sanchayan Maity authored
commit 8546d2e5 upstream. In case the fsl,adck-max-frequency property is not present in the device tree, a division by zero error results during the probe call on kernel boot (see below). This patch fixes it and also restores device tree compatibility in case kernels are booting with old device trees without this property specified. [ 1.063229] Division by zero in kernel. [ 1.067152] CPU: 0 PID: 1 Comm: swapper Not tainted 4.3.0-rc5-00212-gcc88cef #37 [ 1.074650] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) [ 1.081135] Backtrace: [ 1.083694] [<800134a4>] (dump_backtrace) from [<8001369c>] (show_stack+0x18/0x1c) [ 1.091340] r7:00000008 r6:8e0ae210 r5:00000000 r4:8e299800 [ 1.097146] [<80013684>] (show_stack) from [<80297b1c>] (dump_stack+0x24/0x28) [ 1.104483] [<80297af8>] (dump_stack) from [<80013608>] (__div0+0x1c/0x20) [ 1.111421] [<800135ec>] (__div0) from [<802968b4>] (Ldiv0+0x8/0x10) [ 1.117865] [<80424350>] (vf610_adc_probe) from [<803153b4>] (platform_drv_probe+0x4c/0xac) [ 1.126311] r10:00000000 r9:8076a5ec r8:00000000 r7:fffffdfb r6:807cc67c r5:8e0ae210 [ 1.134319] r4:807f6c54 [ 1.136915] [<80315368>] (platform_drv_probe) from [<803138bc>] (driver_probe_device+0x20c/0x2f8) [ 1.145882] r7:807cc67c r6:00000000 r5:8e0ae210 r4:807f6c54 [ 1.151657] [<803136b0>] (driver_probe_device) from [<80313a3c>] (__driver_attach+0x94/0x98) [ 1.160190] r9:8076a5ec r8:00000098 r7:00000000 r6:8e0ae244 r5:807cc67c r4:8e0ae210 [ 1.168112] [<803139a8>] (__driver_attach) from [<80311cb8>] (bus_for_each_dev+0x70/0xa4) [ 1.176383] r7:00000000 r6:803139a8 r5:807cc67c r4:00000000 [ 1.182159] [<80311c48>] (bus_for_each_dev) from [<80313318>] (driver_attach+0x24/0x28) [ 1.190260] r6:807bb568 r5:8e2a5b00 r4:807cc67c [ 1.194996] [<803132f4>] (driver_attach) from [<80312f50>] (bus_add_driver+0x1a4/0x21c) [ 1.203113] [<80312dac>] (bus_add_driver) from [<803142a8>] (driver_register+0x80/0x100) [ 1.211275] r7:8e2a7dc0 r6:807a8160 r5:80789e14 r4:807cc67c [ 1.217075] [<80314228>] (driver_register) from [<803152f8>] (__platform_driver_register+0x5c/0x64) [ 1.226216] r5:80789e14 r4:807a8160 [ 1.229877] [<8031529c>] (__platform_driver_register) from [<80789e30>] (vf610_adc_driver_init+0x1c/0x20) [ 1.239556] [<80789e14>] (vf610_adc_driver_init) from [<800095f8>] (do_one_initcall+0x94/0x1dc) [ 1.248365] [<80009564>] (do_one_initcall) from [<8076ae34>] (kernel_init_freeable+0x13c/0x1e0) [ 1.257155] r10:80794830 r9:8076a5ec r8:00000098 r7:807d5780 r6:807d5780 r5:00000006 [ 1.265153] r4:807a0ee8 [ 1.267753] [<8076acf8>] (kernel_init_freeable) from [<80590ef0>] (kernel_init+0x18/0xf0) [ 1.276021] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:80590ed8 [ 1.284015] r4:807d5780 [ 1.286615] [<80590ed8>] (kernel_init) from [<8000f878>] (ret_from_fork+0x14/0x3c) [ 1.294278] r5:80590ed8 r4:00000000 Signed-off-by:
Sanchayan Maity <maitysanchayan@gmail.com> Acked-by:
Fugang Duan <B38611@freescale.com> Acked-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Lars-Peter Clausen authored
commit 785171fd upstream. While the datasheet for the AD7785 lists 0xXB as the product ID the actual product ID is 0xX3. Fix the product ID otherwise the driver will reject the device due to non matching IDs. Fixes: e786cc26 ("staging:iio:ad7793: Implement stricter id checking") Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Lars-Peter Clausen authored
commit 5dcbe97b upstream. The ad5629/ad5669 are the I2C variant of the ad5628/ad5668, which has a SPI interface. They are mostly identical with the exception that the shift factor is different. Currently the driver does not take care of this difference which leads to incorrect DAC output values. Fix this by introducing a custom channel spec for the ad5629/ad5669 with the correct shift factor. Fixes: commit 6a17a076 ("iio:dac:ad5064: Add support for the ad5629r and ad5669r") Signed-off-by:
-
Michael Hennerich authored
commit 03fe472e upstream. i2c_master_send() returns the number of bytes transferred on success while the ad5064 driver expects that the write() callback returns 0 on success. Fix that by translating any non negative return value of i2c_master_send() to 0. Fixes: commit 6a17a076 ("iio:dac:ad5064: Add support for the ad5629r and ad5669r") Signed-off-by:
Michael Hennerich <michael.hennerich@analog.com> Signed-off-by:
-
Vladimir Zapolskiy authored
commit 01bb70ae upstream. If common clock framework is configured, the driver generates a warning, which is fixed by this change: root@devkit3250:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw ------------[ cut here ]------------ WARNING: CPU: 0 PID: 724 at drivers/clk/clk.c:727 clk_core_enable+0x2c/0xa4() Modules linked in: sc16is7xx snd_soc_uda1380 CPU: 0 PID: 724 Comm: cat Not tainted 4.3.0-rc2+ #198 Hardware name: LPC32XX SoC (Flattened Device Tree) Backtrace: [<>] (dump_backtrace) from [<>] (show_stack+0x18/0x1c) [<>] (show_stack) from [<>] (dump_stack+0x20/0x28) [<>] (dump_stack) from [<>] (warn_slowpath_common+0x90/0xb8) [<>] (warn_slowpath_common) from [<>] (warn_slowpath_null+0x24/0x2c) [<>] (warn_slowpath_null) from [<>] (clk_core_enable+0x2c/0xa4) [<>] (clk_core_enable) from [<>] (clk_enable+0x24/0x38) [<>] (clk_enable) from [<>] (lpc32xx_read_raw+0x38/0x80) [<>] (lpc32xx_read_raw) from [<>] (iio_read_channel_info+0x70/0x94) [<>] (iio_read_channel_info) from [<>] (dev_attr_show+0x28/0x4c) [<>] (dev_attr_show) from [<>] (sysfs_kf_seq_show+0x8c/0xf0) [<>] (sysfs_kf_seq_show) from [<>] (kernfs_seq_show+0x2c/0x30) [<>] (kernfs_seq_show) from [<>] (seq_read+0x1c8/0x440) [<>] (seq_read) from [<>] (kernfs_fop_read+0x38/0x170) [<>] (kernfs_fop_read) from [<>] (do_readv_writev+0x16c/0x238) [<>] (do_readv_writev) from [<>] (vfs_readv+0x50/0x58) [<>] (vfs_readv) from [<>] (default_file_splice_read+0x1a4/0x308) [<>] (default_file_splice_read) from [<>] (do_splice_to+0x78/0x84) [<>] (do_splice_to) from [<>] (splice_direct_to_actor+0xc8/0x1cc) [<>] (splice_direct_to_actor) from [<>] (do_splice_direct+0xa0/0xb8) [<>] (do_splice_direct) from [<>] (do_sendfile+0x1a8/0x30c) [<>] (do_sendfile) from [<>] (SyS_sendfile64+0x104/0x10c) [<>] (SyS_sendfile64) from [<>] (ret_fast_syscall+0x0/0x38) Signed-off-by:
Vladimir Zapolskiy <vz@mleia.com> Signed-off-by:
-
Bhuvanchandra DV authored
commit 6219f432 upstream. Calculate ADCR_VTEMP25 using VTEMP25 at VREFH_ADC 3V3. Existing calculations consider the typical values provided in datasheet. Those typical values are valid for VREFH_ADC at 3.0V. VTEMP25 is different for different VREFH_ADC voltages. With VREFH_ADC at 3.3V, voltage at 25°C is 0.699V. Hence update the VTEMP25 to 0.699V which gives ADCR@Temp25 as 867. Formula for finding ADCR@Temp25: ADCR@Temp25 = (ADCR@Vdd * V@TEMP25 * 10) / VDDconv ADCR@Vdd for 12-Bit ADC = 4095 VDDconv = VREFH_ADC * 10 VREFH_ADC@3.3V ADCR@Temp25 = (4095 * .699 * 10) / 33 ADCR@Temp25 ~= 867 | VREFH_ADC | V@TEMP25 | VDDconv | ADCR@Temp25 | | 3.0V | 0.696mV | 30 | 950 | | 3.3V | 0.699mV | 33 | 867 | Signed-off-by:
Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> Acked-by:
-
