- 14 Apr, 2016 15 commits
-
-
Linus Torvalds authored
[ Upstream commit 256faedc ] This reverts commit dbb17a21. It turns out that commit can cause problems for systems with multiple GPUs, and causes X to hang on at least a HP Pavilion dv7 with hybrid graphics. This got noticed originally in 4.4.4, where this patch had already gotten back-ported, but 4.5-rc7 was verified to have the same problem. Alexander Deucher says: "It looks like you have a muxed system so I suspect what's happening is that one of the display is being reported as connected for both the IGP and the dGPU and then the desktop environment gets confused or there some sort problem in the detect functions since the mux is not switched to the dGPU. I don't see an easy fix unless Dave has any ideas. I'd say just revert for now" Reported-by:
Jörg-Volker Peetz <jvpeetz@web.de> Acked-by:
Alexander Deucher <Alexander.Deucher@amd.com> Cc: Dave Airlie <airlied@gmail.com> Cc: stable@kernel.org # wherever dbb17a21 got back-ported Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
Rusty Russell authored
[ Upstream commit 8244062e ] For CONFIG_KALLSYMS, we keep two symbol tables and two string tables. There's one full copy, marked SHF_ALLOC and laid out at the end of the module's init section. There's also a cut-down version that only contains core symbols and strings, and lives in the module's core section. After module init (and before we free the module memory), we switch the mod->symtab, mod->num_symtab and mod->strtab to point to the core versions. We do this under the module_mutex. However, kallsyms doesn't take the module_mutex: it uses preempt_disable() and rcu tricks to walk through the modules, because it's used in the oops path. It's also used in /proc/kallsyms. There's nothing atomic about the change of these variables, so we can get the old (larger!) num_symtab and the new symtab pointer; in fact this is what I saw when trying to reproduce. By grouping these variables together, we can use a carefully-dereferenced pointer to ensure we always get one or the other (the free of the module init section is already done in an RCU callback, so that's safe). We allocate the init one at the end of the module init section, and keep the core one inside the struct module itself (it could also have been allocated at the end of the module core, but that's probably overkill). Reported-by:
Weilong Chen <chenweilong@huawei.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111541 Cc: stable@kernel.org Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Qu Wenruo authored
[ Upstream commit 0a95b851 ] Parameter of trace_btrfs_work_queued() can be freed in its workqueue. So no one use use that pointer after queue_work(). Fix the user-after-free bug by move the trace line before queue_work(). Reported-by:
Dave Jones <davej@codemonkey.org.uk> Signed-off-by:
Qu Wenruo <quwenruo@cn.fujitsu.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
Chris Mason <clm@fb.com> Signed-off-by:
-
Jann Horn authored
[ Upstream commit 3dfb7d8c ] It looks like smack and yama weren't aware that the ptrace mode can have flags ORed into it - PTRACE_MODE_NOAUDIT until now, but only for /proc/$pid/stat, and with the PTRACE_MODE_*CREDS patch, all modes have flags ORed into them. Signed-off-by:
Jann Horn <jann@thejh.net> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Morris <james.l.morris@oracle.com> Cc: "Serge E. Hallyn" <serge.hallyn@ubuntu.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Simon Guinot authored
[ Upstream commit 59ceeaaf ] In __request_region, if a conflict with a BUSY and MUXED resource is detected, then the caller goes to sleep and waits for the resource to be released. A pointer on the conflicting resource is kept. At wake-up this pointer is used as a parent to retry to request the region. A first problem is that this pointer might well be invalid (if for example the conflicting resource have already been freed). Another problem is that the next call to __request_region() fails to detect a remaining conflict. The previously conflicting resource is passed as a parameter and __request_region() will look for a conflict among the children of this resource and not at the resource itself. It is likely to succeed anyway, even if there is still a conflict. Instead, the parent of the conflicting resource should be passed to __request_region(). As a fix, this patch doesn't update the parent resource pointer in the case we have to wait for a muxed region right after. Reported-and-tested-by:
Vincent Pelletier <plr.vincent@gmail.com> Signed-off-by:
Simon Guinot <simon.guinot@sequanux.org> Tested-by:
Vincent Donnefort <vdonnefort@gmail.com> Cc: stable@kernel.org Signed-off-by:
-
Laura Abbott authored
[ Upstream commit d2cc2f0b ] A previous patch added a check if the firmware is too big, but it didn't set the return error code with the right value. [mchehab@osg.samsung.com: I ended by applying a v1 of Laura's patch, without the proper return code. This patch contains the difference between v2 and v1 of the Laura's "si2157: Bounds check firmware" patch] Cc: stable@kernel.org Signed-off-by:
Laura Abbott <labbott@fedoraproject.org> Reviewed-by:
Olli Salonen <olli.salonen@iki.fi> Tested-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Laura Abbott authored
[ Upstream commit a828d72d ] When reading the firmware and sending commands, the length must be bounds checked to avoid overrunning the size of the command buffer and smashing the stack if the firmware is not in the expected format. Add the proper check. Cc: stable@kernel.org Signed-off-by:
-
Sebastian Andrzej Siewior authored
[ Upstream commit 546bed63 ] I managed to trigger this: | INFO: trying to register non-static key. | the code is fine but needs lockdep annotation. | turning off the locking correctness validator. | CPU: 1 PID: 781 Comm: systemd-gpt-aut Not tainted 4.4.0-rt2+ #14 | Hardware name: ARM-Versatile Express | [<80307cec>] (dump_stack) | [<80070e98>] (__lock_acquire) | [<8007184c>] (lock_acquire) | [<80287800>] (btrfs_ioctl) | [<8012a8d4>] (do_vfs_ioctl) | [<8012ac14>] (SyS_ioctl) so I think that btrfs_device_data_ordered_init() is not invoked behind a macro somewhere. Fixes: 7cc8e58d ("Btrfs: fix unprotected device's variants on 32bits machine") Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by:
-
Filipe Manana authored
[ Upstream commit 271dba45 ] If we failed to create a hard link we were not always releasing the the transaction handle we got before, resulting in a memory leak and preventing any other tasks from being able to commit the current transaction. Fix this by always releasing our transaction handle. Signed-off-by:
Filipe Manana <fdmanana@suse.com> Reviewed-by:
Liu Bo <bo.li.liu@oracle.com> Signed-off-by:
-
Filipe Manana authored
[ Upstream commit 9269d12b ] We weren't accounting for the insertion of an inline extent item for the symlink inode nor that we need to update the parent inode item (through the call to btrfs_add_nondir()). So fix this by including two more transaction units. Signed-off-by:
-
Filipe Manana authored
[ Upstream commit a879719b ] When a symlink is successfully created it always has an inline extent containing the source path. However if an error happens when creating the symlink, we can leave in the subvolume's tree a symlink inode without any such inline extent item - this happens if after btrfs_symlink() calls btrfs_end_transaction() and before it calls the inode eviction handler (through the final iput() call), the transaction gets committed and a crash happens before the eviction handler gets called, or if a snapshot of the subvolume is made before the eviction handler gets called. Sadly we can't just avoid this by making btrfs_symlink() call btrfs_end_transaction() after it calls the eviction handler, because the later can commit the current transaction before it removes any items from the subvolume tree (if it encounters ENOSPC errors while reserving space for removing all the items). So make send fail more gracefully, with an -EIO error, and print a message to dmesg/syslog informing that there's an empty symlink inode, so that the user can delete the empty symlink or do something else about it. Reported-by:
Stephen R. van den Berg <srb@cuci.nl> Signed-off-by:
-
David Sterba authored
[ Upstream commit ca8a51b3 ] There is one ENOSPC case that's very confusing. There's Available greater than zero but no file operation succeds (besides removing files). This happens when the metadata are exhausted and there's no possibility to allocate another chunk. In this scenario it's normal that there's still some space in the data chunk and the calculation in df reflects that in the Avail value. To at least give some clue about the ENOSPC situation, let statfs report zero value in Avail, even if there's still data space available. Current: /dev/sdb1 4.0G 3.3G 719M 83% /mnt/test New: /dev/sdb1 4.0G 3.3G 0 100% /mnt/test We calculate the remaining metadata space minus global reserve. If this is (supposedly) smaller than zero, there's no space. But this does not hold in practice, the exhausted state happens where's still some positive delta. So we apply some guesswork and compare the delta to a 4M threshold. (Practically observed delta was 2M.) We probably cannot calculate the exact threshold value because this depends on the internal reservations requested by various operations, so some operations that consume a few metadata will succeed even if the Avail is zero. But this is better than the other way around. Signed-off-by:
-
Josef Bacik authored
[ Upstream commit be7bd730 ] We hit this panic on a few of our boxes this week where we have an ordered_extent with an NULL inode. We do an igrab() of the inode in writepages, but weren't doing it in writepage which can be called directly from the VM on dirty pages. If the inode has been unlinked then we could have I_FREEING set which means igrab() would return NULL and we get this panic. Fix this by trying to igrab in btrfs_writepage, and if it returns NULL then just redirty the page and return AOP_WRITEPAGE_ACTIVATE; so the VM knows it wasn't successful. Thanks, Signed-off-by:
Josef Bacik <jbacik@fb.com> Reviewed-by:
-
Anand Jain authored
[ Upstream commit b2acdddf ] Looks like oversight, call brelse() when checksum fails. Further down the code, in the non error path, we do call brelse() and so we don't see brelse() in the goto error paths. Signed-off-by:
Anand Jain <anand.jain@oracle.com> Reviewed-by:
-
Hariprasad S authored
[ Upstream commit 67f1aee6 ] The cxgb3_*_send() functions return NET_XMIT_ values, which are positive integers values. So don't treat positive return values as an error. Signed-off-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
- 12 Apr, 2016 25 commits
-
-
Jason Andryuk authored
[ Upstream commit a6807590 ] The comparisons should be >= since 0x800 and 0x80 require an additional bit to store. For the 3 byte case, the existing shift would drop off 2 more bits than intended. For the 2 byte case, there should be 5 bits bits in byte 1, and 6 bits in byte 2. Signed-off-by:
Jason Andryuk <jandryuk@gmail.com> Reviewed-by:
Laszlo Ersek <lersek@redhat.com> Cc: Peter Jones <pjones@redhat.com> Cc: Matthew Garrett <mjg59@coreos.com> Cc: "Lee, Chun-Yi" <jlee@suse.com> Signed-off-by:
Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by:
-
Matt Fleming authored
[ Upstream commit e246eb56 ] Laszlo explains why this is a good idea, 'This is because the pstore filesystem can be backed by UEFI variables, and (for example) a crash might dump the last kilobytes of the dmesg into a number of pstore entries, each entry backed by a separate UEFI variable in the above GUID namespace, and with a variable name according to the above pattern. Please see "drivers/firmware/efi/efi-pstore.c". While this patch series will not prevent the user from deleting those UEFI variables via the pstore filesystem (i.e., deleting a pstore fs entry will continue to delete the backing UEFI variable), I think it would be nice to preserve the possibility for the sysadmin to delete Linux-created UEFI variables that carry portions of the crash log, *without* having to mount the pstore filesystem.' There's also no chance of causing machines to become bricked by deleting these variables, which is the whole purpose of excluding things from the whitelist. Use the LINUX_EFI_CRASH_GUID guid and a wildcard '*' for the match so that we don't have to update the string in the future if new variable name formats are created for crash dump variables. Reported-by:
Peter Jones <pjones@redhat.com> Tested-by:
-
Peter Jones authored
[ Upstream commit ed8b0de5 ] "rm -rf" is bricking some peoples' laptops because of variables being used to store non-reinitializable firmware driver data that's required to POST the hardware. These are 100% bugs, and they need to be fixed, but in the mean time it shouldn't be easy to *accidentally* brick machines. We have to have delete working, and picking which variables do and don't work for deletion is quite intractable, so instead make everything immutable by default (except for a whitelist), and make tools that aren't quite so broad-spectrum unset the immutable flag. Signed-off-by:
Lee, Chun-Yi <jlee@suse.com> Acked-by:
Matthew Garrett <mjg59@coreos.com> Signed-off-by:
-
Peter Jones authored
[ Upstream commit 8282f5d9 ] All the variables in this list so far are defined to be in the global namespace in the UEFI spec, so this just further ensures we're validating the variables we think we are. Including the guid for entries will become more important in future patches when we decide whether or not to allow deletion of variables based on presence in this list. Signed-off-by:
-
Peter Jones authored
[ Upstream commit 3dcb1f55 ] Actually translate from ucs2 to utf8 before doing the test, and then test against our other utf8 data, instead of fudging it. Signed-off-by:
-
Peter Jones authored
[ Upstream commit e0d64e6a ] Translate EFI's UCS-2 variable names to UTF-8 instead of just assuming all variable names fit in ASCII. Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit f7ef7e3e ] It's not very normal to return 1 on failure and 0 on success. There isn't a reason for it here, the callers don't care so long as it's non-zero on failure. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Matt Fleming <matt.fleming@intel.com> Signed-off-by:
-
Peter Jones authored
[ Upstream commit 73500267 ] This adds ucs2_utf8size(), which tells us how big our ucs2 string is in bytes, and ucs2_as_utf8, which translates from ucs2 to utf8.. Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit be95485a ] The PSCI SMP implementation is built only when both CONFIG_SMP and CONFIG_ARM_PSCI are set, so a configuration that has the latter but not the former can get a link error when it tries to call psci_smp_available(). arch/arm/mach-tegra/built-in.o: In function `tegra114_cpuidle_init': cpuidle-tegra114.c:(.init.text+0x52a): undefined reference to `psci_smp_available' This corrects the #ifdef in the psci.h header file to match the Makefile conditional we have for building that function. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Daniel Vetter authored
[ Upstream commit d3e376f5 ] This is called without dev->struct_mutex held, we need to use the _unlocked variant. Never caught in the wild since you'd need an evil userspace which races a gem_close ioctl call with the in-progress open. Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1448271183-20523-17-git-send-email-daniel.vetter@ffwll.chSigned-off-by:
-
Rusty Russell authored
[ Upstream commit 2e7bac53 ] This trivial wrapper adds clarity and makes the following patch smaller. Cc: stable@kernel.org Signed-off-by:
-
Akinobu Mita authored
[ Upstream commit 431386e7 ] According to the datasheet, the resolusion of temperature sensor is -5.35 counts/C. Temperature ADC is 472 counts at 25C. (https://www.sparkfun.com/datasheets/Sensors/Pressure/MPL115A1.pdf NOTE: This is older revision, but this information is removed from the latest datasheet from nxp somehow) Temp [C] = (Tadc - 472) / -5.35 + 25 = (Tadc - 605.750000) * -0.186915888 So the correct offset is -605.750000. Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Acked-by:
Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Yong Li authored
[ Upstream commit 97a249e9 ] Without this change, the name entity for mcp4725 is missing in /sys/bus/iio/devices/iio\:device*/name With this change, name is reported correctly Signed-off-by:
Yong Li <sdliyong@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by:
-
Lars-Peter Clausen authored
[ Upstream commit d590faf9 ] The SPI tx and rx buffers are both supposed to be scan_bytes amount of bytes large and a common allocation is used to allocate both buffers. This puts the beginning of the tx buffer scan_bytes bytes after the rx buffer. The initialization of the tx buffer pointer is done adding scan_bytes to the beginning of the rx buffer, but since the rx buffer is of type __be16 this will actually add two times as much and the tx buffer ends up pointing after the allocated buffer. Fix this by using scan_count, which is scan_bytes / 2, instead of scan_bytes when initializing the tx buffer pointer. Fixes: aacff892 ("staging:iio:adis: Preallocate transfer message") Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Cc: <Stable@vger.kernel.org> Signed-off-by:
-
Jann Horn authored
[ Upstream commit caaee623 ] By checking the effective credentials instead of the real UID / permitted capabilities, ensure that the calling process actually intended to use its credentials. To ensure that all ptrace checks use the correct caller credentials (e.g. in case out-of-tree code or newly added code omits the PTRACE_MODE_*CREDS flag), use two new flags and require one of them to be set. The problem was that when a privileged task had temporarily dropped its privileges, e.g. by calling setreuid(0, user_uid), with the intent to perform following syscalls with the credentials of a user, it still passed ptrace access checks that the user would not be able to pass. While an attacker should not be able to convince the privileged task to perform a ptrace() syscall, this is a problem because the ptrace access check is reused for things in procfs. In particular, the following somewhat interesting procfs entries only rely on ptrace access checks: /proc/$pid/stat - uses the check for determining whether pointers should be visible, useful for bypassing ASLR /proc/$pid/maps - also useful for bypassing ASLR /proc/$pid/cwd - useful for gaining access to restricted directories that contain files with lax permissions, e.g. in this scenario: lrwxrwxrwx root root /proc/13020/cwd -> /root/foobar drwx------ root root /root drwxr-xr-x root root /root/foobar -rw-r--r-- root root /root/foobar/secret Therefore, on a system where a root-owned mode 6755 binary changes its effective credentials as described and then dumps a user-specified file, this could be used by an attacker to reveal the memory layout of root's processes or reveal the contents of files he is not allowed to access (through /proc/$pid/cwd). [akpm@linux-foundation.org: fix warning] Signed-off-by:
-
Benjamin Tissoires authored
[ Upstream commit 73e7d63e ] as reported by https://bugzilla.kernel.org/show_bug.cgi?id=108481 This bug reports mentions 6d4f5440 ("HID: multitouch: Fetch feature reports on demand for Win8 devices") as the origin of the problem but this commit actually masked 2 firmware bugs that are annihilating each other: The report descriptor declares two features in reports 3 and 5: 0x05, 0x0d, // Usage Page (Digitizers) 318 0x09, 0x0e, // Usage (Device Configuration) 320 0xa1, 0x01, // Collection (Application) 322 0x85, 0x03, // Report ID (3) 324 0x09, 0x22, // Usage (Finger) 326 0xa1, 0x00, // Collection (Physical) 328 0x09, 0x52, // Usage (Inputmode) 330 0x15, 0x00, // Logical Minimum (0) 332 0x25, 0x0a, // Logical Maximum (10) 334 0x75, 0x08, // Report Size (8) 336 0x95, 0x02, // Report Count (2) 338 0xb1, 0x02, // Feature (Data,Var,Abs) 340 0xc0, // End Collection 342 0x09, 0x22, // Usage (Finger) 343 0xa1, 0x00, // Collection (Physical) 345 0x85, 0x05, // Report ID (5) 347 0x09, 0x57, // Usage (Surface Switch) 349 0x09, 0x58, // Usage (Button Switch) 351 0x15, 0x00, // Logical Minimum (0) 353 0x75, 0x01, // Report Size (1) 355 0x95, 0x02, // Report Count (2) 357 0x25, 0x03, // Logical Maximum (3) 359 0xb1, 0x02, // Feature (Data,Var,Abs) 361 0x95, 0x0e, // Report Count (14) 363 0xb1, 0x03, // Feature (Cnst,Var,Abs) 365 0xc0, // End Collection 367 The report ID 3 presents 2 input mode features, while only the first one is handled by the device. Given that we did not checked if one was previously assigned, we were dealing with the ignored featured and we should never have been able to switch this panel into the multitouch mode. However, the firmware presents an other bugs which allowed 6d4f5440 to counteract the faulty report descriptor. When we request the values of the feature 5, the firmware answers "03 03 00". The fields are correct but the report id is wrong. Before 6d4f5440, we retrieved all the features and injected them in the system. So when we called report 5, we injected in the system the report 3 with the values "03 00". Setting the second input mode to 03 in this report changed it to "03 03" and the touchpad switched to the mt mode. We could have set anything in the second field because the actual value (the first 03 in this report) was given by the query of report ID 5. To sum up: 2 bugs in the firmware were hiding that we were accessing the wrong feature. Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Raghavendra K T authored
[ Upstream commit 9c03ee14 ] The following PowerPC commit: c118baf8 ("arch/powerpc/mm/numa.c: do not allocate bootmem memory for non existing nodes") avoids allocating bootmem memory for non existent nodes. But when DEBUG_PER_CPU_MAPS=y is enabled, my powerNV system failed to boot because in sched_init_numa(), cpumask_or() operation was done on unallocated nodes. Fix that by making cpumask_or() operation only on existing nodes. [ Tested with and w/o DEBUG_PER_CPU_MAPS=y on x86 and PowerPC. ] Reported-by:
Jan Stancek <jstancek@redhat.com> Tested-by:
Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com> Cc: <gkurz@linux.vnet.ibm.com> Cc: <grant.likely@linaro.org> Cc: <nikunj@linux.vnet.ibm.com> Cc: <vdavydov@parallels.com> Cc: <linuxppc-dev@lists.ozlabs.org> Cc: <linux-mm@kvack.org> Cc: <peterz@infradead.org> Cc: <benh@kernel.crashing.org> Cc: <paulus@samba.org> Cc: <mpe@ellerman.id.au> Cc: <anton@samba.org> Link: http://lkml.kernel.org/r/1452884483-11676-1-git-send-email-raghavendra.kt@linux.vnet.ibm.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit e7fdd527 ] Many codecs, typically found on Realtek codecs, have the analog loopback path merged to the secondary input of the middle of the output paths. Currently, we don't offer the dynamic switching in such configuration but let each loopback path mute by itself. This should work well in theory, but in reality, we often see that such a dead loopback path causes some background noises even if all the elements get muted. Such a problem has been fixed by adding the quirk accordingly to disable aamix, and it's the right fix, per se. The only problem is that it's not so trivial to achieve it; user needs to pass a hint string via patch module option or sysfs. This patch gives a bit improvement on the situation: it adds "Loopback Mixing" control element for such codecs like other codecs (e.g. IDT or VIA codecs) with the individual loopback paths. User can turn on/off the loopback path simply via a mixer app. For keeping the compatibility, the loopback is still enabled on these codecs. But user can try to turn it off if experiencing a suspicious background or click noise on the fly, then build a static fixup later once after the problem is addressed. Other than the addition of the loopback enable/disablement control, there should be no changes. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Johan Rastén authored
[ Upstream commit 27c41dad ] Changed ctl type for Input Gain Control and Input Gain Pad Control to USB_MIXER_S16 as per section 5.2.5.7.11-12 in the USB Audio Class 2.0 definition. Signed-off-by:
Johan Rastén <johan@oljud.se> Signed-off-by:
-
Benjamin Tissoires authored
[ Upstream commit 4392bf33 ] hid_ignore_special_drivers works fine until hid_scan_report autodetects and reassign devices (for hid-multitouch, hid-microsoft and hid-rmi). Simplify the handling of the parameter: if it is there, use hid-generic, no matter what, and if not, scan the device or rely on the hid_have_special_driver table. This was detected while trying to disable hid-multitouch on a Surface Pro cover which prevented to use the keyboard. Signed-off-by:
-
Benjamin Tissoires authored
[ Upstream commit 9578f41a ] This allows the transport layer (I have in mind hid-logitech-dj and uhid) to set the group before it is added to the hid bus. This way, it can bypass the hid_scan_report() call, and choose in advance which driver will handle the newly created hid device. Signed-off-by:
-
Oliver Neukum authored
[ Upstream commit 264904cc ] Some devices I got show an inability to operate right after power on if they are already connected. They are beyond recovery if the descriptors are requested multiple times. So in case of a timeout we rather bail early and reset again. But it must be done only on the first loop lest we get into a reset/time out spiral that can be overcome with a retry. This patch is a rework of a patch that fell through the cracks. http://www.spinics.net/lists/linux-usb/msg103263.htmlSigned-off-by:
Oliver Neukum <oneukum@suse.com> CC: stable@vger.kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Lior Amsalem authored
[ Upstream commit b3a7f31e ] The Armada 375 has the same SATA IP as Armada 370 and Armada XP, which requires the PHY speed to be set in the LP_PHY_CTL register for SATA hotplug to work. Therefore, this commit updates the compatible string used to describe the SATA IP in Armada 375 from marvell,orion-sata to marvell,armada-370-sata. Fixes: 4de59085 ("ARM: mvebu: add Device Tree description of the Armada 375 SoC") Cc: <stable@vger.kernel.org> Signed-off-by:
Lior Amsalem <alior@marvell.com> Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
Kamal Mostafa authored
[ Upstream commit 50fe6dd1 ] Use the local uapi headers to keep in sync with "recently" added #define's (e.g. VSS_OP_REGISTER1). Fixes: 3eb2094c ("Adding makefile for tools/hv") Cc: <stable@vger.kernel.org> Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Matej Muzila authored
[ Upstream commit ca04455f ] hv_fcopy_daemon is not mentioned in Makefile so it must be built manually. Add hv_fcopy_daemon to Makefile. Signed-off-by:
Matej Muzila <mmuzila@redhat.com> Signed-off-by:
-
