- 06 Jun, 2015 29 commits
-
-
Jason A. Donenfeld authored
commit 48ef23a4 upstream. This phone is already supported by the visor driver. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jason A. Donenfeld authored
commit 82ee3aeb upstream. Samsung has just released a portable USB3 SSD, coming in a very small and nice form factor. It's USB ID is 04e8:8001, which unfortunately is already used by the Palm Visor driver for the Samsung I330 phone cradle. Having pl2303 or visor pick up this device ID results in conflicts with the usb-storage driver, which handles the newly released portable USB3 SSD. To work around this conflict, I've dug up a mailing list post [1] from a long time ago, in which a user posts the full USB descriptor information. The most specific value in this appears to be the interface class, which has value 255 (0xff). Since usb-storage requires an interface class of 0x8, I believe it's correct to disambiguate the two devices by matching on 0xff inside visor. [1] http://permalink.gmane.org/gmane.linux.usb.user/4264Signed-off-by:
-
Joe Lawrence authored
commit 948fa135 upstream. If the xHCI host controller has died (ie, device removed) or suffered other serious fatal error (STS_FATAL), then xhci_irq should handle this condition with IRQ_HANDLED instead of -ESHUTDOWN. Signed-off-by:
Joe Lawrence <joe.lawrence@stratus.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Mathias Nyman authored
commit 18cc2f4c upstream. Our event ring consists of only one segment, and we risk filling the event ring in case we get isoc transfers with short intervals such as webcams that fill a TD every microframe (125us) With 64 TRB segment size one usb camera could fill the event ring in 8ms. A setup with several cameras and other devices can fill up the event ring as it is shared between all devices. This has occurred when uvcvideo queues 5 * 32TD URBs which then get cancelled when the video mode changes. The cancelled URBs are returned in the xhci interrupt context and blocks the interrupt handler from handling the new events. A full event ring will block xhci from scheduling traffic and affect all devices conneted to the xhci, will see errors such as Missed Service Intervals for isoc devices, and and Split transaction errors for LS/FS interrupt devices. Increasing the TRB_PER_SEGMENT will also increase the default endpoint ring size, which is welcome as for most isoc transfer we had to dynamically expand the endpoint ring anyway to be able to queue the 5 * 32TDs uvcvideo queues. The default size used to be 64 TRBs per segment Signed-off-by:
-
Mathias Nyman authored
commit d104d015 upstream. Isoc TDs usually consist of one TRB, sometimes two. When all goes well we receive only one success event for a TD, and move the dequeue pointer to the next TD. This fails if the TD consists of two TRBs and we get a transfer error on the first TRB, we will then see two events for that TD. Fix this by making sure the event we get is for the last TRB in that TD before moving the dequeue pointer to the next TD. This will resolve some of the uvc and dvb issues with the "ERROR Transfer event TRB DMA ptr not part of current TD" error message Signed-off-by:
-
Andy Grover authored
commit 5a7125c6 upstream. See https://bugzilla.redhat.com/show_bug.cgi?id=1025672 We need to put() the reference to the scsi host that we got in pscsi_configure_device(). In VIRTUAL_HOST mode it is associated with the dev_virt, not the hba_virt. Signed-off-by:
Andy Grover <agrover@redhat.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Sławomir Demeszko authored
commit 892c89d5 upstream. Fix regression introduced by commit <29ef8a53>. After it writing AT commands to /dev/GCT-ATM0 is unsuccessful (no echo, no response) and dmesg show "gdmtty: invalid payload : 1 16 f011". Before that commit value of dummy_cnt was only a padding size. After using ALIGN() this value is increased by its first argument. So the following usage of this variable needs correction. Signed-off-by:
Sławomir Demeszko <s.demeszko@wireless-instruments.com> Signed-off-by:
-
Zidan Wang authored
commit 17fc2e0a upstream. According to the RM of wm8958, BCLK DIV 348 doesn't exist, correct it to 384. Signed-off-by:
Zidan Wang <zidan.wang@freescale.com> Acked-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Zidan Wang authored
commit 85e36a1f upstream. It should be "RINPUT3" instead of "LINPUT3" route to "Right Input Mixer". Signed-off-by:
-
Axel Lin authored
commit 545774bd upstream. mc13xxx_reg_rmw() won't change any bit if passing 0 to the mask field. Pass AUDIO_SSI_SEL instead of 0 for the mask field to set AUDIO_SSI_SEL bit. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Signed-off-by:
-
Takashi Iwai authored
commit 3530febb upstream. This reverts commit 7290006d. Through the regression report, it was revealed that the tpacpi_led_set() call to thinkpad_acpi helper doesn't only toggle the mute LED but actually mutes the sound. This is contradiction to the expectation, and rather confuses user. According to Henrique, it's not trivial to judge which TP model behaves "LED-only" and which model does whatever more intrusive, as Lenovo's implementations vary model by model. So, from the safety reason, we should revert the patch for now. Reported-by:
Martin Steigerwald <martin@lichtvoll.de> Cc: Pali Rohár <pali.rohar@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit 88776f36 upstream. Fujitsu Lifebook E752 laptop needs a similar quirk done for Lifebook T731. Otherwise the headphone is always muted. Reported-and-tested-by:
Christian Weber <we_chris@hotmail.com> Signed-off-by:
-
David Henningsson authored
commit 6ffc0898 upstream. This patch adds support for Conexant HD Audio codecs CX20721, CX20722, CX20723 and CX20724. BugLink: https://bugs.launchpad.net/bugs/1454656Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Al Viro authored
commit 2159184e upstream. when we find that a child has died while we'd been trying to ascend, we should go into the first live sibling itself, rather than its sibling. Off-by-one in question had been introduced in "deal with deadlock in d_walk()" and the fix needs to be backported to all branches this one has been backported to. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Jan Kara authored
commit f18c34e4 upstream. If the specified maximum length of the string is a multiple of unsigned long, we would load one long behind the specified maximum. If that happens to be in a next page, we can hit a page fault although we were not expected to. Fix the off-by-one bug in the test whether we are at the end of the specified range. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Guenter Roeck authored
commit 1b63bf61 upstream. The following error message is seen when loading the nct6775 driver with DEBUG_LOCK_ALLOC enabled. BUG: key ffff88040b2f0030 not in .data! ------------[ cut here ]------------ WARNING: CPU: 0 PID: 186 at kernel/locking/lockdep.c:2988 lockdep_init_map+0x469/0x630() DEBUG_LOCKS_WARN_ON(1) Caused by a missing call to sysfs_attr_init() when initializing sysfs attributes. Reported-by:
Alexey Orishko <alexey.orishko@gmail.com> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Chris Lesiak authored
commit adba6575 upstream. When configured via device tree, the associated iio device needs to be measuring voltage for the conversion to resistance to be correct. Return -EINVAL if that is not the case. Signed-off-by:
Chris Lesiak <chris.lesiak@licor.com> Signed-off-by:
-
David Vrabel authored
commit 77bb3dfd upstream. A non-percpu VIRQ (e.g., VIRQ_CONSOLE) may be freed on a different VCPU than it is bound to. This can result in a race between handle_percpu_irq() and removing the action in __free_irq() because handle_percpu_irq() does not take desc->lock. The interrupt handler sees a NULL action and oopses. Only use the percpu chip/handler for per-CPU VIRQs (like VIRQ_TIMER). # cat /proc/interrupts | grep virq 40: 87246 0 xen-percpu-virq timer0 44: 0 0 xen-percpu-virq debug0 47: 0 20995 xen-percpu-virq timer1 51: 0 0 xen-percpu-virq debug1 69: 0 0 xen-dyn-virq xen-pcpu 74: 0 0 xen-dyn-virq mce 75: 29 0 xen-dyn-virq hvc_console Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
-
Ilya Dryomov authored
commit b0494532 upstream. This commit does two things. First, if there are any homeless lingering requests, we now request a new osdmap even if the osdmap that is being processed brought no changes, i.e. if a given lingering request turned homeless in one of the previous epochs and remained homeless in the current epoch. Not doing so leaves us with a stale osdmap and as a result we may miss our window for reestablishing the watch and lose notifies. MON=1 OSD=1: # cat linger-needmap.sh #!/bin/bash rbd create --size 1 test DEV=$(rbd map test) ceph osd out 0 rbd map dne/dne # obtain a new osdmap as a side effect (!) sleep 1 ceph osd in 0 rbd resize --size 2 test # rbd info test | grep size -> 2M # blockdev --getsize $DEV -> 1M N.B.: Not obtaining a new osdmap in between "osd out" and "osd in" above is enough to make it miss that resize notify, but that is a bug^Wlimitation of ceph watch/notify v1. Second, homeless lingering requests are now kicked just like those lingering requests whose mapping has changed. This is mainly to recognize that a homeless lingering request makes no sense and to preserve the invariant that a registered lingering request is not sitting on any of r_req_lru_item lists. This spares us a WARN_ON, which commit ba9d114e ("libceph: clear r_req_lru_item in __unregister_linger_request()") tried to fix the _wrong_ way. Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Reviewed-by:
Sage Weil <sage@redhat.com> Signed-off-by:
-
Rusty Russell authored
commit 83a35114 upstream. This bug has been there since day 1; addresses in the top guest physical page weren't considered valid. You could map that page (the check in check_gpte() is correct), but if a guest tried to put a pagetable there we'd check that address manually when walking it, and kill the guest. Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Sasha Levin authored
commit dcbff39d upstream. match_token() expects a NULL terminator at the end of the token list so that it would know where to stop. Not having one causes it to overrun to invalid memory. In practice, passing a mount option that omfs didn't recognize would sometimes panic the system. Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Junling Zheng authored
Based on 08adb7da upstream. We found that after v3.10.73, recvmsg might return -EFAULT while -EINVAL was expected. We tested it through the recvmsg01 testcase come from LTP testsuit. It set msg->msg_namelen to -1 and the recvmsg syscall returned errno 14, which is unexpected (errno 22 is expected): recvmsg01 4 TFAIL : invalid socket length ; returned -1 (expected -1), errno 14 (expected 22) Linux mainline has no this bug for commit 08adb7da fixes it accidentally. However, it is too large and complex to be backported to LTS 3.10. Commit 281c9c36 (net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour) made get_compat_msghdr() return error if msg_sys->msg_namelen was negative, which changed the behaviors of recvmsg and sendmsg syscall in a lib32 system: Before commit 281c9c36, get_compat_msghdr() wouldn't fail and it would return -EINVAL in move_addr_to_user() or somewhere if msg_sys->msg_namelen was invalid and then syscall returned -EINVAL, which is correct. And now, when msg_sys->msg_namelen is negative, get_compat_msghdr() will fail and wants to return -EINVAL, however, the outer syscall will return -EFAULT directly, which is unexpected. This patch gets the return value of get_compat_msghdr() as well as copy_msghdr_from_user(), then returns this expected value if get_compat_msghdr() fails. Fixes: 281c9c36 (net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour) Signed-off-by:
Junling Zheng <zhengjunling@huawei.com> Signed-off-by:
Hanbing Xu <xuhanbing@huawei.com> Cc: Li Zefan <lizefan@huawei.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: David Miller <davem@davemloft.net> Signed-off-by:
-
Paolo Bonzini authored
commit 89876115 upstream. smep_andnot_wp is initialized in kvm_init_shadow_mmu and shadow pages should not be reused for different values of it. Thus, it has to be added to the mask in kvm_mmu_pte_write. Reviewed-by:
Xiao Guangrong <guangrong.xiao@linux.intel.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Chen Gang authored
commit 9493c242 upstream. Remove 2 redundant extern inline functions: qla8044_set_qsnt_ready() and qla8044_need_reset_handler(). At present, within upstream next kernel source code, they are only used within "drivers/scsi/qla2xxx/qla_nx2.c". The related error and warnings (with allmodconfig under tile): CC [M] drivers/scsi/qla2xxx/qla_nx2.o drivers/scsi/qla2xxx/qla_nx2.c:1633:1: error: static declaration of 'qla8044_need_reset_handler' follows non-static declaration qla8044_need_reset_handler(struct scsi_qla_host *vha) ^ In file included from drivers/scsi/qla2xxx/qla_def.h:3706:0, from drivers/scsi/qla2xxx/qla_nx2.c:11: drivers/scsi/qla2xxx/qla_gbl.h:756:20: note: previous declaration of 'qla8044_need_reset_handler' was here extern inline void qla8044_need_reset_handler(struct scsi_qla_host *vha); ^ drivers/scsi/qla2xxx/qla_gbl.h:756:20: warning: inline function 'qla8044_need_reset_handler' declared but never defined make[3]: *** [drivers/scsi/qla2xxx/qla_nx2.o] Error 1 make[2]: *** [drivers/scsi/qla2xxx] Error 2 make[1]: *** [drivers/scsi] Error 2 make: *** [drivers] Error 2 CC [M] drivers/scsi/qla2xxx/qla_tmpl.o In file included from drivers/scsi/qla2xxx/qla_def.h:3706:0, from drivers/scsi/qla2xxx/qla_tmpl.c:7: drivers/scsi/qla2xxx/qla_gbl.h:755:20: warning: inline function 'qla8044_set_qsnt_ready' declared but never defined extern inline void qla8044_set_qsnt_ready(struct scsi_qla_host *vha); ^ Signed-off-by:
Chen Gang <gang.chen.5i5j@gmail.com> Acked-by:
Saurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Kirill A. Shutemov authored
commit 51b97e35 upstream. Sasha Levin reports: "gcc5 changes the default standard to c11, which makes kernel build unhappy Explicitly define the kernel standard to be gnu89 which should keep everything working exactly like it was before gcc5" There are multiple small issues with the new default, but the biggest issue seems to be that the old - and very useful - GNU extension to allow a cast in front of an initializer has gone away. Patch updated by Kirill: "I'm pretty sure all gcc versions you can build kernel with supports -std=gnu89. cc-option is redunrant. We also need to adjust HOSTCFLAGS otherwise allmodconfig fails for me" Note by Andrew Pinski: "Yes it was reported and both problems relating to this extension has been added to gnu99 and gnu11. Though there are other issues with the kernel dealing with extern inline have different semantics between gnu89 and gnu99/11" End result: we may be able to move up to a newer stdc model eventually, but right now the newer models have some annoying deficiencies, so the traditional "gnu89" model ends up being the preferred one. Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
-
Behan Webster authored
commit 62ec95f8 upstream. rtllib_probe_req is defined as "static inline" in rtllib_softmac.c however it is declared differently as "extern inline" in rtllib_softmac.h. Since it isn't used outside of the scope of rtllib_softmac, it makes sense to remove the incorrect declaration. Signed-off-by:
Behan Webster <behanw@converseincode.com> Suggested-by:
Arnd Bergmann <arnd@arndb.de> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
commit 0c9f3a65 upstream. The rtl8712 driver has an 'extern inline' function that contains an 'if', which causes lots of warnings with CONFIG_PROFILE_ALL_BRANCHES overriding the definition of 'if': drivers/staging/rtl8712/ieee80211.h:759:229: warning: '______f' is static but declared in inline function 'ieee80211_get_hdrlen' which is not static [enabled by default] This changes the driver to use 'static inline' instead, which happens to be the correct annotation anyway. Signed-off-by:
-
Behan Webster authored
commit 6d91857d upstream. With compilers which follow the C99 standard (like modern versions of gcc and clang), "extern inline" does the opposite thing from older versions of gcc (emits code for an externally linkable version of the inline function). "static inline" does the intended behavior in all cases instead. Signed-off-by:
-
Greg Kroah-Hartman authored
Patch not upstream as this driver is deleted there. Fix up some "extern inline" functions as they break the build when using a "modern" complier (i.e. gcc5). Signed-off-by:
-
- 17 May, 2015 11 commits
-
-
Greg Kroah-Hartman authored
-
Will Deacon authored
commit 63afbe7a upstream. If the physical address of GICV isn't page-aligned, then we end up creating a stage-2 mapping of the page containing it, which causes us to map neighbouring memory locations directly into the guest. As an example, consider a platform with GICV at physical 0x2c02f000 running a 64k-page host kernel. If qemu maps this into the guest at 0x80010000, then guest physical addresses 0x80010000 - 0x8001efff will map host physical region 0x2c020000 - 0x2c02efff. Accesses to these physical regions may cause UNPREDICTABLE behaviour, for example, on the Juno platform this will cause an SError exception to EL3, which brings down the entire physical CPU resulting in RCU stalls / HYP panics / host crashing / wasted weeks of debugging. SBSA recommends that systems alias the 4k GICV across the bounding 64k region, in which case GICV physical could be described as 0x2c020000 in the above scenario. This patch fixes the problem by failing the vgic probe if the physical base address or the size of GICV aren't page-aligned. Note that this generated a warning in dmesg about freeing enabled IRQs, so I had to move the IRQ enabling later in the probe. Cc: Christoffer Dall <christoffer.dall@linaro.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Gleb Natapov <gleb@kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Joel Schopp <joel.schopp@amd.com> Cc: Don Dutile <ddutile@redhat.com> Acked-by:
Peter Maydell <peter.maydell@linaro.org> Acked-by:
Joel Schopp <joel.schopp@amd.com> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Christoffer Dall <christoffer.dall@linaro.org> Cc: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by:
-
Will Deacon authored
commit ee9e101c upstream. In order to ensure completion of inner-shareable maintenance instructions (cache and TLB) on AArch64, we can use the -ish suffix to the dsb instruction. This patch relaxes our dsb sy instructions to dsb ish where possible. Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Acked-by:
-
Haibin Wang authored
commit 30c21170 upstream. Currently below check in vgic_ioaddr_overlap will always succeed, because the vgic dist base and vgic cpu base are still kept UNDEF after initialization. The code as follows will be return forever. if (IS_VGIC_ADDR_UNDEF(dist) || IS_VGIC_ADDR_UNDEF(cpu)) return 0; So, before invoking the vgic_ioaddr_overlap, it needs to set the corresponding base address firstly. Signed-off-by:
Haibin Wang <wanghaibin.wang@huawei.com> Acked-by:
-
Andre Przywara authored
commit f2ae85b2 upstream. Since KVM internally represents the ICFGR registers by stuffing two of them into one word, the offset for accessing the internal representation and the one for the MMIO based access are different. So keep the original offset around, but adjust the internal array offset by one bit. Reported-by:
Andre Przywara <andre.przywara@arm.com> Signed-off-by:
-
Marc Zyngier authored
commit 8034699a upstream. In order to be able to detect the point where the guest enables its MMU and caches, trap all the VM related system registers. Once we see the guest enabling both the MMU and the caches, we can go back to a saner mode of operation, which is to leave these registers in complete control of the guest. Signed-off-by:
-
Marc Zyngier authored
commit af20814e upstream. HCR.TVM traps (among other things) accesses to AMAIR0 and AMAIR1. In order to minimise the amount of surprise a guest could generate by trying to access these registers with caches off, add them to the list of registers we switch/handle. Signed-off-by:
-
Marc Zyngier authored
commit ac30a11e upstream. So far, KVM/ARM used a fixed HCR configuration per guest, except for the VI/VF/VA bits to control the interrupt in absence of VGIC. With the upcoming need to dynamically reconfigure trapping, it becomes necessary to allow the HCR to be changed on a per-vcpu basis. The fix here is to mimic what KVM/arm64 already does: a per vcpu HCR field, initialized at setup time. Signed-off-by:
-
Marc Zyngier authored
commit 547f7813 upstream. Commit 240e99cb (ARM: KVM: Fix 64-bit coprocessor handling) added an ordering dependency for the 64bit registers. The order described is: CRn, CRm, Op1, Op2, 64bit-first. Unfortunately, the implementation is: CRn, 64bit-first, CRm... Move the 64bit test to be last in order to match the documentation. Signed-off-by:
-
Marc Zyngier authored
commit 46c214dd upstream. Commit 240e99cb (ARM: KVM: Fix 64-bit coprocessor handling) changed the way we match the 64bit coprocessor access from user space, but didn't update the trap handler for the same set of registers. The effect is that a trapped 64bit access is never matched, leading to a fault being injected into the guest. This went unnoticed as we didn't really trap any 64bit register so far. Placing the CRm field of the access into the CRn field of the matching structure fixes the problem. Also update the debug feature to emit the expected string in case of failing match. Signed-off-by:
-
Marc Zyngier authored
commit 15979300 upstream. In order for a guest with caches disabled to observe data written contained in a given page, we need to make sure that page is committed to memory, and not just hanging in the cache (as guest accesses are completely bypassing the cache until it decides to enable it). For this purpose, hook into the coherent_cache_guest_page function and flush the region if the guest SCTLR register doesn't show the MMU and caches as being enabled. Signed-off-by:
-
