- 15 Jul, 2017 10 commits
-
-
Greg Kroah-Hartman authored
-
Mikulas Patocka authored
commit 99c13b8c upstream. The pat_enabled() logic is broken on CPUs which do not support PAT and where the initialization code fails to call pat_init(). Due to that the enabled flag stays true and pat_enabled() returns true wrongfully. As a consequence the mappings, e.g. for Xorg, are set up with the wrong caching mode and the required MTRR setups are omitted. To cure this the following changes are required: 1) Make pat_enabled() return true only if PAT initialization was invoked and successful. 2) Invoke init_cache_modes() unconditionally in setup_arch() and remove the extra callsites in pat_disable() and the pat disabled code path in pat_init(). Also rename __pat_enabled to pat_disabled to reflect the real purpose of this variable. Fixes: 9cd25aac ("x86/mm/pat: Emulate PAT when it is disabled") Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Bernhard Held <berny156@gmx.de> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Brian Gerst <brgerst@gmail.com> Cc: "Luis R. Rodriguez" <mcgrof@suse.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/alpine.LRH.2.02.1707041749300.3456@file01.intranet.prod.int.rdu2.redhat.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Chao Yu authored
commit 1ea1516f upstream. kstrtoull returns 0 on success, however, in reserved_clusters_store we will return -EINVAL if kstrtoull returns 0, it makes us fail to update reserved_clusters value through sysfs. Fixes: 76d33bcaSigned-off-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Miao Xie <miaoxie@huawei.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Jason A. Donenfeld authored
commit fec17cb2 upstream. Otherwise, we enable all sorts of forgeries via timing attack. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Suggested-by:
Stephan Müller <smueller@chronox.de> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: linux-crypto@vger.kernel.org Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Horia Geantă authored
commit 42cfcafb upstream. Changes in the SW cts (ciphertext stealing) code in commit 0605c41c ("crypto: cts - Convert to skcipher") revealed a problem in the CAAM driver: when cts(cbc(aes)) is executed and cts runs in SW, cbc(aes) is offloaded in CAAM; cts encrypts the last block in atomic context and CAAM incorrectly decides to use GFP_KERNEL for memory allocation. Fix this by allowing GFP_KERNEL (sleeping) only when MAY_SLEEP flag is set, i.e. remove MAY_BACKLOG flag. We split the fix in two parts - first is sent to -stable, while the second is not (since there is no known failure case). Link: http://lkml.kernel.org/g/20170602122446.2427-1-david@sigma-star.atReported-by:
David Gstir <david@sigma-star.at> Signed-off-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
-
Ian Abbott authored
commit a9332e9a upstream. There is a clean-up bug in the core comedi module initialization functions, `comedi_init()`. If the `comedi_num_legacy_minors` module parameter is non-zero (and valid), it creates that many "legacy" devices and registers them in SysFS. A failure causes the function to clean up and return an error. Unfortunately, it fails to destroy the "comedi" class that was created earlier. Fix it by adding a call to `class_destroy(comedi_class)` at the appropriate place in the clean-up sequence. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Malcolm Priestley authored
commit dc32190f upstream. The key table is not intialized correctly without this call. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
-
Kirill Tkhai authored
commit a0c4acd2 upstream. If a writer could been woken up, the above branch if (sem->count == 0) break; would have moved us to taking the sem. So, it's not the time to wake a writer now, and only readers are allowed now. Thus, 0 must be passed to __rwsem_do_wake(). Next, __rwsem_do_wake() wakes readers unconditionally. But we mustn't do that if the sem is owned by writer in the moment. Otherwise, writer and reader own the sem the same time, which leads to memory corruption in callers. rwsem-xadd.c does not need that, as: 1) the similar check is made lockless there, 2) in __rwsem_mark_wake::try_reader_grant we test, that sem is not owned by writer. Signed-off-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Niklas Cassel <niklas.cassel@axis.com> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 17fcbd59 "locking/rwsem: Fix down_write_killable() for CONFIG_RWSEM_GENERIC_SPINLOCK=y" Link: http://lkml.kernel.org/r/149762063282.19811.9129615532201147826.stgit@localhost.localdomainSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Eric W. Biederman authored
commit 2fd1d2c4 upstream. Andrei Vagin writes: FYI: This bug has been reproduced on 4.11.7 > BUG: Dentry ffff895a3dd01240{i=4e7c09a,n=lo} still in use (1) [unmount of proc proc] > ------------[ cut here ]------------ > WARNING: CPU: 1 PID: 13588 at fs/dcache.c:1445 umount_check+0x6e/0x80 > CPU: 1 PID: 13588 Comm: kworker/1:1 Not tainted 4.11.7-200.fc25.x86_64 #1 > Hardware name: CompuLab sbc-flt1/fitlet, BIOS SBCFLT_0.08.04 06/27/2015 > Workqueue: events proc_cleanup_work > Call Trace: > dump_stack+0x63/0x86 > __warn+0xcb/0xf0 > warn_slowpath_null+0x1d/0x20 > umount_check+0x6e/0x80 > d_walk+0xc6/0x270 > ? dentry_free+0x80/0x80 > do_one_tree+0x26/0x40 > shrink_dcache_for_umount+0x2d/0x90 > generic_shutdown_super+0x1f/0xf0 > kill_anon_super+0x12/0x20 > proc_kill_sb+0x40/0x50 > deactivate_locked_super+0x43/0x70 > deactivate_super+0x5a/0x60 > cleanup_mnt+0x3f/0x90 > mntput_no_expire+0x13b/0x190 > kern_unmount+0x3e/0x50 > pid_ns_release_proc+0x15/0x20 > proc_cleanup_work+0x15/0x20 > process_one_work+0x197/0x450 > worker_thread+0x4e/0x4a0 > kthread+0x109/0x140 > ? process_one_work+0x450/0x450 > ? kthread_park+0x90/0x90 > ret_from_fork+0x2c/0x40 > ---[ end trace e1c109611e5d0b41 ]--- > VFS: Busy inodes after unmount of proc. Self-destruct in 5 seconds. Have a nice day... > BUG: unable to handle kernel NULL pointer dereference at (null) > IP: _raw_spin_lock+0xc/0x30 > PGD 0 Fix this by taking a reference to the super block in proc_sys_prune_dcache. The superblock reference is the core of the fix however the sysctl_inodes list is converted to a hlist so that hlist_del_init_rcu may be used. This allows proc_sys_prune_dache to remove inodes the sysctl_inodes list, while not causing problems for proc_sys_evict_inode when if it later choses to remove the inode from the sysctl_inodes list. Removing inodes from the sysctl_inodes list allows proc_sys_prune_dcache to have a progress guarantee, while still being able to drop all locks. The fact that head->unregistering is set in start_unregistering ensures that no more inodes will be added to the the sysctl_inodes list. Previously the code did a dance where it delayed calling iput until the next entry in the list was being considered to ensure the inode remained on the sysctl_inodes list until the next entry was walked to. The structure of the loop in this patch does not need that so is much easier to understand and maintain. Reported-by:
Andrei Vagin <avagin@gmail.com> Tested-by:
Andrei Vagin <avagin@openvz.org> Fixes: ace0c791 ("proc/sysctl: Don't grab i_lock under sysctl_lock.") Fixes: d6cffbbe ("proc/sysctl: prune stale dentries during unregistering") Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Cong Wang authored
commit f991af3d upstream. The retry logic for netlink_attachskb() inside sys_mq_notify() is nasty and vulnerable: 1) The sock refcnt is already released when retry is needed 2) The fd is controllable by user-space because we already release the file refcnt so we when retry but the fd has been just closed by user-space during this small window, we end up calling netlink_detachskb() on the error path which releases the sock again, later when the user-space closes this socket a use-after-free could be triggered. Setting 'sock' to NULL here should be sufficient to fix it. Reported-by:
GeneBlue <geneblue.mail@gmail.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Manfred Spraul <manfred@colorfullife.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
- 12 Jul, 2017 30 commits
-
-
Greg Kroah-Hartman authored
-
Yifeng Li authored
commit fe0dfd63 upstream. Thinkpad Helix 2 is a tablet PC, the audio is powered by Core M broadwell-audio and rt286 codec. For all versions of Linux kernel, the stereo output doesn't work properly when earphones are plugged in, the sound was coming out from both channels even if the audio contains only the left or right channel. Furthermore, if a music recorded in stereo is played, the two channels cancle out each other out, as a result, no voice but only distorted background music can be heard, like a sound card with builtin a Karaoke sount effect. Apparently this tablet uses a combo jack with polarity incorrectly set by rt286 driver. This patch adds DMI information of Thinkpad Helix 2 to force_combo_jack_table[] and the issue is resolved. The microphone input doesn't work regardless to the presence of this patch and still needs help from other developers to investigate. This is my first patch to LKML directly, sorry for CC-ing too many people here. Link: https://bugzilla.kernel.org/show_bug.cgi?id=93841Signed-off-by:
Yifeng Li <tomli@tomli.me> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Stephan Mueller authored
commit b61929c6 upstream. Initialise ctr_completion variable before use. Cc: <stable@vger.kernel.org> Signed-off-by:
Harsh Jain <harshjain.prof@gmail.com> Signed-off-by:
-
Juergen Gross authored
commit 1a3fc2c4 upstream. There has been a report about a deadlock in the xenbus driver: [ 247.979498] ====================================================== [ 247.985688] WARNING: possible circular locking dependency detected [ 247.991882] 4.12.0-rc4-00022-gc4b25c0 #575 Not tainted [ 247.997040] ------------------------------------------------------ [ 248.003232] xenbus/91 is trying to acquire lock: [ 248.007875] (&u->msgbuffer_mutex){+.+.+.}, at: [<ffff00000863e904>] xenbus_dev_queue_reply+0x3c/0x230 [ 248.017163] [ 248.017163] but task is already holding lock: [ 248.023096] (xb_write_mutex){+.+...}, at: [<ffff00000863a940>] xenbus_thread+0x5f0/0x798 [ 248.031267] [ 248.031267] which lock already depends on the new lock. [ 248.031267] [ 248.039615] [ 248.039615] the existing dependency chain (in reverse order) is: [ 248.047176] [ 248.047176] -> #1 (xb_write_mutex){+.+...}: [ 248.052943] __lock_acquire+0x1728/0x1778 [ 248.057498] lock_acquire+0xc4/0x288 [ 248.061630] __mutex_lock+0x84/0x868 [ 248.065755] mutex_lock_nested+0x3c/0x50 [ 248.070227] xs_send+0x164/0x1f8 [ 248.074015] xenbus_dev_request_and_reply+0x6c/0x88 [ 248.079427] xenbus_file_write+0x260/0x420 [ 248.084073] __vfs_write+0x48/0x138 [ 248.088113] vfs_write+0xa8/0x1b8 [ 248.091983] SyS_write+0x54/0xb0 [ 248.095768] el0_svc_naked+0x24/0x28 [ 248.099897] [ 248.099897] -> #0 (&u->msgbuffer_mutex){+.+.+.}: [ 248.106088] print_circular_bug+0x80/0x2e0 [ 248.110730] __lock_acquire+0x1768/0x1778 [ 248.115288] lock_acquire+0xc4/0x288 [ 248.119417] __mutex_lock+0x84/0x868 [ 248.123545] mutex_lock_nested+0x3c/0x50 [ 248.128016] xenbus_dev_queue_reply+0x3c/0x230 [ 248.133005] xenbus_thread+0x788/0x798 [ 248.137306] kthread+0x110/0x140 [ 248.141087] ret_from_fork+0x10/0x40 It is rather easy to avoid by dropping xb_write_mutex before calling xenbus_dev_queue_reply(). Fixes: fd8aa909 ("xen: optimize xenbus driver for multiple concurrent xenstore accesses"). Reported-by:
Andre Przywara <andre.przywara@arm.com> Signed-off-by:
Juergen Gross <jgross@suse.com> Tested-by:
-
Paolo Abeni authored
commit 236222d3 upstream. According to the Intel datasheet, the REP MOVSB instruction exposes a pretty heavy setup cost (50 ticks), which hurts short string copy operations. This change tries to avoid this cost by calling the explicit loop available in the unrolled code for strings shorter than 64 bytes. The 64 bytes cutoff value is arbitrary from the code logic point of view - it has been selected based on measurements, as the largest value that still ensures a measurable gain. Micro benchmarks of the __copy_from_user() function with lengths in the [0-63] range show this performance gain (shorter the string, larger the gain): - in the [55%-4%] range on Intel Xeon(R) CPU E5-2690 v4 - in the [72%-9%] range on Intel Core i7-4810MQ Other tested CPUs - namely Intel Atom S1260 and AMD Opteron 8216 - show no difference, because they do not expose the ERMS feature bit. Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Acked-by:
Mel Gorman <mgorman@techsingularity.net>
-
Jarkko Sakkinen authored
commit 13b47cfc upstream. While cleaning up sysfs callback that prints EK we discovered a kernel memory leak. This commit fixes the issue by zeroing the buffer used for TPM command/response. The leak happen when we use either tpm_vtpm_proxy, tpm_ibmvtpm or xen-tpmfront. Fixes: 08837438 ("TPM: sysfs functions consolidation") Reported-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Tested-by:
Stefan Berger <stefanb@linux.vnet.ibm.com> Signed-off-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by:
James Morris <james.l.morris@oracle.com> Signed-off-by:
-
Josh Zimmerman authored
commit d1bd4a79 upstream. If a TPM2 loses power without a TPM2_Shutdown command being issued (a "disorderly reboot"), it may lose some state that has yet to be persisted to NVRam, and will increment the DA counter. After the DA counter gets sufficiently large, the TPM will lock the user out. NOTE: This only changes behavior on TPM2 devices. Since TPM1 uses sysfs, and sysfs relies on implicit locking on chip->ops, it is not safe to allow this code to run in TPM1, or to add sysfs support to TPM2, until that locking is made explicit. Signed-off-by:
Josh Zimmerman <joshz@google.com> Fixes: 74d6b3ce ("tpm: fix suspend/resume paths for TPM 2.0") Reviewed-by:
-
Josh Zimmerman authored
commit f77af151 upstream. The TPM class has some common shutdown code that must be executed for all drivers. This adds some needed functionality for that. Signed-off-by:
-
Andreas Gruenbacher authored
commit 961ae1d8 upstream. Before commit 88ffbf3e "GFS2: Use resizable hash table for glocks", glocks were freed via call_rcu to allow reading the glock hashtable locklessly using rcu. This was then changed to free glocks immediately, which made reading the glock hashtable unsafe. Bring back the original code for freeing glocks via call_rcu. Signed-off-by:
Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
-
Jiahau Chang authored
commit dec08194 upstream. For AMD Promontory xHCI host, although you can disable USB 2.0 ports in BIOS settings, those ports will be enabled anyway after you remove a device on that port and re-plug it in again. It's a known limitation of the chip. As a workaround we can clear the PORT_WAKE_BITS. This will disable wake on connect, disconnect and overcurrent on AMD Promontory USB2 ports [checkpatch cleanup and commit message reword -Mathias] Cc: Tsai Nicholas <nicholas.tsai@amd.com> Signed-off-by:
Jiahau Chang <Lars_Chang@asmedia.com.tw> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Bjørn Mork authored
commit 996fab55 upstream. A new Sierra Wireless EM7305 device ID used in a Toshiba laptop. Reported-by:
Petr Kloc <petr_kloc@yahoo.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
commit 8fb060da upstream. Add two Longcheer device-id entries which specifically enables a Telewell TW-3G HSPA+ branded modem (0x9801). Reported-by:
Teemu Likonen <tlikonen@iki.fi> Reported-by:
Lars Melin <larsm17@gmail.com> Tested-by:
-
Geert Uytterhoeven authored
commit 3091ae77 upstream. Update the sh_pfc_soc_info pointer after calling the SoC-specific initialization function, as it may have been updated to e.g. handle different SoC revisions. This makes sure the correct subdriver name is printed later. Fixes: 0c151062 ("sh-pfc: Add support for SoC-specific initialization") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Sergei Shtylyov authored
commit da7a692f upstream. The R8A7791 PFC driver was apparently based on the preliminary revisions of the user's manual, which omitted the HSCIF1 group E signals in the IPSR4 register description. This would cause HSCIF1's probe to fail with the messages like below: sh-pfc e6060000.pfc: cannot locate data/mark enum_id for mark 1989 sh-sci e62c8000.serial: Error applying setting, reverse things back sh-sci: probe of e62c8000.serial failed with error -22 Add the neceassary PINMUX_IPSR_MSEL() invocations for the HSCK1_E, HCTS1#_E, and HRTS1#_E signals... Fixes: 50884519 ("pinctrl: sh-pfc: r8a7791 PFC support") Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
Uwe Kleine-König authored
commit da6c2add upstream. To set the mux mode of a pin two bits must be set. Up to now this is implemented using the following idiom: writel(mask, reg + CLR); writel(value, reg + SET); . This however results in the mux mode being 0 between the two writes. On my machine there is an IC's reset pin connected to LCD_D20. The bootloader configures this pin as GPIO output-high (i.e. not holding the IC in reset). When Linux reconfigures the pin to GPIO the short time LCD_D20 is muxed as LCD_D20 instead of GPIO_1_20 is enough to confuse the connected IC. The same problem is present for the pin's drive strength setting which is reset to low drive strength before using the right value. So instead of relying on the hardware to modify the register setting using two writes implement the bit toggling using read-modify-write. Fixes: 17723111 ("pinctrl: add pinctrl-mxs support") Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Tony Lindgren authored
commit 664b7c47 upstream. Andre Przywara <andre.przywara@arm.com> noticed that we can get the following warning with -EPROBE_DEFER: "WARNING: CPU: 1 PID: 89 at drivers/base/dd.c:349 driver_probe_device+0x2ac/0x2e8" Let's fix the issue by removing the indices as suggested by Tejun Heo <tj@kernel.org>. All we have to do here is kill the radix tree. I probably ended up with the indices after grepping for removal of all entries using radix_tree_for_each_slot() and the first match found was gmap_radix_tree_free(). Anyways, no need for indices here, and we can just do remove all the entries using radix_tree_for_each_slot() along how the item_kill_tree() test case does. Fixes: c7059c5a ("pinctrl: core: Add generic pinctrl functions for managing groups") Fixes: a76edc89 ("pinctrl: core: Add generic pinctrl functions for managing groups") Reported-by:
Tony Lindgren <tony@atomide.com> Reviewed-by:
-
Chen-Yu Tsai authored
commit 7903d4f5 upstream. We use well known standard names for functions that have name, such as I2C, SPI, SPDIF, etc.. Fix the function name of SPDIF, which was named OWA (One Wire Audio) based on Allwinner datasheets. Fixes: 4730f33f ("pinctrl: sunxi: add allwinner A83T PIO controller support") Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Alexandre TORGUE authored
commit b7c747d4 upstream. In stm32_pconf_parse_conf function, stm32_pmx_gpio_set_direction is called with wrong parameter value. Indeed, using NULL value for range will raise an oops. Fixes: aceb16dc ("pinctrl: Add STM32 MCUs support") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Alexandre TORGUE <alexandre.torgue@st.com> Signed-off-by:
-
Martin Blumenstingl authored
commit 97ba26b8 upstream. The nand_groups table uses different names for the NAND DQS pins than the GROUP() definition in meson8b_cbus_groups (nand_dqs_0 vs nand_dqs0). This prevents using the NAND DQS pins in the devicetree. Fix this by ensuring that the GROUP() definition and the meson8b_cbus_groups use the same name for these pins. Fixes: 0fefcb68 ("pinctrl: Add support for Meson8b") Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
Geert Uytterhoeven authored
commit 4324b608 upstream. Fix typos in hscif2_clk_b_mux[] and hscif4_ctrl_mux[]. Fixes: a56069c4 ("pinctrl: sh-pfc: r8a7795: Add HSCIF pins, groups, and functions") Signed-off-by:
-
Sergei Shtylyov authored
commit 3908632f upstream. The R8A7791 PFC driver was apparently based on the preliminary revisions of the user's manual, which omitted the DVC_MUTE signal altogether in the PFC section. The modern manual has the signal described, so just add the necassary data to the driver... Fixes: 50884519 ("pinctrl: sh-pfc: r8a7791 PFC support") Signed-off-by:
-
Sergei Shtylyov authored
commit 58439280 upstream. PINMUX_IPSR_MSEL() macro invocation for the TX2 signal has apparently wrong 1st argument -- most probably a result of cut&paste programming... Fixes: 50884519 ("pinctrl: sh-pfc: r8a7791 PFC support") Signed-off-by:
-
Sergei Shtylyov authored
commit 5f4c8caf upstream. All R8A7794 manuals I have here (0.50 and 1.10) agree that the PFC driver has ATAG0# and ATAWR0# signals in IPSR12 swapped -- fix this. Fixes: 43c4436e ("pinctrl: sh-pfc: add R8A7794 PFC support") Signed-off-by:
-
Juri Lelli authored
commit f70b281b upstream. The sysfs cpu_capacity entry for each CPU has nothing to do with PROC_FS, nor it's in /proc/sys path. Remove such ifdef. Cc: Russell King <linux@arm.linux.org.uk> Reported-and-suggested-by:
Sudeep Holla <sudeep.holla@arm.com> Fixes: 7e5930aa ('ARM: 8622/3: add sysfs cpu_capacity attribute') Signed-off-by:
Juri Lelli <juri.lelli@arm.com> Acked-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Johan Hovold authored
commit e271b2c9 upstream. Make sure to release any OF device-node reference taken when creating the USB device. Note that we currently do not hold a reference to the root hub device-tree node (i.e. the parent controller node). Fixes: 69bec725 ("USB: core: let USB device know device node") Acked-by:
Peter Chen <peter.chen@nxp.com> Signed-off-by:
-
Benjamin Herrenschmidt authored
commit 7cf916bd upstream. The current definition is wrong. This breaks my upcoming Aspeed virtual hub driver. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Michael Grzeschik authored
commit b3b51417 upstream. The usbip stack dynamically allocates the transfer_buffer and setup_packet of each urb that got generated by the tcp to usb stub code. As these pointers are always used only once we will set them to NULL after use. This is done likewise to the free_urb code in vudc_dev.c. This patch fixes double kfree situations where the usbip remote side added the URB_FREE_BUFFER. Signed-off-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Acked-by:
Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
-
Devin Heitmueller authored
commit 6836796d upstream. The USB core and sysfs will attempt to enumerate certain parameters which are unsupported by the au0828 - causing inconsistent behavior and sometimes causing the chip to reset. Avoid making these calls. This problem manifested as intermittent cases where the au8522 would be reset on analog video startup, in particular when starting up ALSA audio streaming in parallel - the sysfs entries created by snd-usb-audio on streaming startup would result in unsupported control messages being sent during tuning which would put the chip into an unknown state. Signed-off-by:
Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by:
-
Jeremie Rapin authored
commit fd90f73a upstream. Added the USB serial device ID for the CEL ZigBee EM3588 radio stick. Signed-off-by:
Jeremie Rapin <rapinj@gmail.com> Acked-by:
-
Felipe Balbi authored
commit 04fb365c upstream. %p will leak kernel pointers, so let's not expose the information on dmesg and instead use %pK. %pK will only show the actual addresses if explicitly enabled under /proc/sys/kernel/kptr_restrict. Acked-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
