- 13 Nov, 2014 40 commits
-
-
Adel Gadllah authored
commit 29d05c2e upstream. This device needs the quirk as well. Signed-off-by:
Adel Gadllah <adel.gadllah@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Johan Hovold authored
commit bfe3c873 upstream. Enable the always-poll quirk for Elan Touchscreens found on some recent Samsung laptops. Without this quirk the device keeps disconnecting from the bus (and is re-enumerated) unless opened (and kept open, should an input event occur). Note that while the device can be run-time suspended, the autosuspend timeout must be high enough to allow the device to be polled at least once before being suspended. Specifically, using autosuspend_delay_ms=0 will still cause the device to disconnect on input events. Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
commit 0b750b3b upstream. Add quirk to make sure that a device is always polled for input events even if it hasn't been opened. This is needed for devices that disconnects from the bus unless the interrupt endpoint has been polled at least once or when not responding to an input event (e.g. after having shut down X). Signed-off-by:
-
Adel Gadllah authored
commit d7499475 upstream. Yet another device affected by this. Tested-by:
Kevin Fenzi <kevin@scrye.com> Signed-off-by:
-
Adel Gadllah authored
commit 876af5d4 upstream. Currently this quirk is enabled for the model with the device id 0x0089, it is needed for the 0x009b model, which is found on the Fujitsu Lifebook u904 as well. Signed-off-by:
-
Johan Hovold authored
commit c68929f7 upstream. Enable device-qualifier quirk for Elan Touchscreen, which often fails to handle requests for the device_descriptor. Note that the device sometimes do respond properly with a Request Error (three times as USB core retries), but usually fails to respond at all. When this happens any further descriptor requests also fails, for example: [ 1528.688934] usb 2-7: new full-speed USB device number 4 using xhci_hcd [ 1530.945588] usb 2-7: unable to read config index 0 descriptor/start: -71 [ 1530.945592] usb 2-7: can't read configurations, error -71 This has been observed repeating for over a minute before eventual successful enumeration. Reported-by:
Drew Von Spreecken <drewvs@gmail.com> Reported-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Johan Hovold authored
commit 2a159389 upstream. Add new quirk for devices that cannot handle requests for the device_qualifier descriptor. A USB-2.0 compliant device must respond to requests for the device_qualifier descriptor (even if it's with a request error), but at least one device is known to misbehave after such a request. Suggested-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Thomas Gleixner authored
commit d2e6d62c upstream. commit c58d80f5 ("usb: musb: Ensure that cppi41 timer gets armed on premature DMA TX irq") fixed hrtimer scheduling bug. There is one left which does not trigger that often. The following scenario is still possible: lock(&x->lock); hrtimer_start(&x->t); unlock(&x->lock); expires: t->function(); lock(&x->lock); lock(&x->lock); if (!hrtimer_queued(&x->t)) hrtimer_start(&x->t); unlock(&x->lock); if (!list_empty(x->early_tx_list)) ret = HRTIMER_RESTART; -> hrtimer_forward_now(...) } else ret = HRTIMER_NORESTART; unlock(&x->lock); and the timer callback returns HRTIMER_RESTART for an armed timer. This is wrong and we run into the BUG_ON() in __run_hrtimer(). This can happens on SMP or PREEMPT-RT. The patch fixes the problem by only starting the timer if the timer is not yet queued. Reported-by:
Torben Hohn <torbenh@linutronix.de> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> [bigeasy: collected information and created a patch + description based on it] Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Dmitry Eremin-Solenikov authored
commit 2b9375b9 upstream. If PM_RUNTIME is enabled, it is easy to trigger the following backtrace on pxa2xx hosts: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at /home/lumag/linux/arch/arm/mach-pxa/clock.c:35 clk_disable+0xa0/0xa8() Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-00007-g1b3d2ee-dirty #104 [<c000de68>] (unwind_backtrace) from [<c000c078>] (show_stack+0x10/0x14) [<c000c078>] (show_stack) from [<c001d75c>] (warn_slowpath_common+0x6c/0x8c) [<c001d75c>] (warn_slowpath_common) from [<c001d818>] (warn_slowpath_null+0x1c/0x24) [<c001d818>] (warn_slowpath_null) from [<c0015e80>] (clk_disable+0xa0/0xa8) [<c0015e80>] (clk_disable) from [<c02507f8>] (pxa2xx_spi_suspend+0x2c/0x34) [<c02507f8>] (pxa2xx_spi_suspend) from [<c0200360>] (platform_pm_suspend+0x2c/0x54) [<c0200360>] (platform_pm_suspend) from [<c0207fec>] (dpm_run_callback.isra.14+0x2c/0x74) [<c0207fec>] (dpm_run_callback.isra.14) from [<c0209254>] (__device_suspend+0x120/0x2f8) [<c0209254>] (__device_suspend) from [<c0209a94>] (dpm_suspend+0x50/0x208) [<c0209a94>] (dpm_suspend) from [<c00455ac>] (suspend_devices_and_enter+0x8c/0x3a0) [<c00455ac>] (suspend_devices_and_enter) from [<c0045ad4>] (pm_suspend+0x214/0x2a8) [<c0045ad4>] (pm_suspend) from [<c04b5c34>] (test_suspend+0x14c/0x1dc) [<c04b5c34>] (test_suspend) from [<c000880c>] (do_one_initcall+0x8c/0x1fc) [<c000880c>] (do_one_initcall) from [<c04aecfc>] (kernel_init_freeable+0xf4/0x1b4) [<c04aecfc>] (kernel_init_freeable) from [<c0378078>] (kernel_init+0x8/0xec) [<c0378078>] (kernel_init) from [<c0009590>] (ret_from_fork+0x14/0x24) ---[ end trace 46524156d8faa4f6 ]--- This happens because suspend function tries to disable a clock that is already disabled by runtime_suspend callback. Add if (!pm_runtime_suspended()) checks to suspend/resume path. Fixes: 7d94a505 (spi/pxa2xx: add support for runtime PM) Signed-off-by:
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Reported-by:
Andrea Adami <andrea.adami@gmail.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Alexander Stein authored
commit 5cc7b047 upstream. There are only 4 CTAR registers (CTAR0 - CTAR3) so we can only use the lower 2 bits of the chip select to select a CTAR register. SPI_PUSHR_CTAS used the lower 3 bits which would result in wrong bit values if the chip selects 4/5 are used. For those chip selects SPI_CTAR even calculated offsets of non-existing registers. Signed-off-by:
Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by:
-
Ray Jui authored
commit 3ffa6158 upstream. When mapped RX DMA entries are unmapped in an error condition when DMA is firstly configured in the driver, the number of TX DMA entries was passed in, which is incorrect Signed-off-by:
Ray Jui <rjui@broadcom.com> Signed-off-by:
-
Jack Pham authored
commit 1200a82a upstream. On ISOC endpoints the last trb_pool entry used as a LINK TRB is not getting zeroed out correctly due to memset being called incorrectly and in the wrong place. If pool allocated from DMA was not zero-initialized to begin with this will result in the size and ctrl values being random garbage. Call memset correctly after assignment of the trb_link pointer. Fixes: f6bafc6a ("usb: dwc3: convert TRBs into bitshifts") Signed-off-by:
Jack Pham <jackp@codeaurora.org> Signed-off-by:
-
Cyril Brulebois authored
commit 664d6a79 upstream. 0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle References: https://bugs.debian.org/766802Reported-by:
Martin Mokrejs <mmokrejs@fold.natur.cuni.cz> Signed-off-by:
Cyril Brulebois <kibi@debian.org> Acked-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Xose Vazquez Perez authored
commit 6a06e554 upstream. 0x0b05 0x17e8 RT5372 USB 2.0 bgn 2x2 ASUS USB-N14 0x0411 0x0253 RT5572 USB 2.0 abgn 2x2 BUFFALO WLP-U2-300D 0x0df6 0x0078 RT???? Sitecom N300 Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: Helmut Schaa <helmut.schaa@googlemail.com> Cc: John W. Linville <linville@tuxdriver.com> Cc: users@rt2x00.serialmonkey.com Cc: linux-wireless@vger.kernel.org Signed-off-by:
Xose Vazquez Perez <xose.vazquez@gmail.com> Signed-off-by:
-
Canek Peláez Valdés authored
commit ac0372ab upstream. Signed-off-by:
Canek Peláez Valdés <canek@ciencias.unam.mx> Signed-off-by:
-
Dan Williams authored
commit 012eee15 upstream. Port layout: 0: QCDM/DIAG 1: NMEA 2: AT 3: AT/PPP Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Daniele Palmas authored
commit 2d0eb862 upstream. Add VID/PID for Telit LE910 modem. Interfaces description is almost the same than LE920, except that the qmi interface is number 2 (instead than 5). Signed-off-by:
Daniele Palmas <dnlplm@gmail.com> Signed-off-by:
-
Johan Hovold authored
commit 4473d054 upstream. Make sure to only raise DTR on transitions from B0 in set_termios. Also allow set_termios to be called from open with a termios_old of NULL. Note that DTR will not be raised prematurely in this case. Signed-off-by:
-
Johan Hovold authored
commit cf84a691 upstream. Add device-id entry for GW Instek AFG-2225, which has a byte swapped bInterfaceSubClass (0x20). Reported-by:
Karl Palsson <karlp@tweak.net.au> Signed-off-by:
-
Perry Hung authored
commit 7f2719f0 upstream. An official recent Windows driver from FTDI detects counterfeit devices and reprograms the internal EEPROM containing the USB PID to 0, effectively bricking the device. Add support for this VID/PID pair to correctly bind the driver on these devices. See: http://hackaday.com/2014/10/22/watch-that-windows-update-ftdi-drivers-are-killing-fake-chips/Signed-off-by:
Perry Hung <iperry@gmail.com> Acked-by:
-
Frans Klaver authored
commit edd74ffa upstream. Add new IDs for the Xsens Awinda Station and Awinda Dongle. While at it, order the definitions by PID and add a logical separation between devices using Xsens' VID and those using FTDI's VID. Signed-off-by:
Frans Klaver <frans.klaver@xsens.com> Signed-off-by:
-
Nathaniel Ting authored
commit 35cc83ea upstream. Enable Silicon Labs Ember VID chips to enumerate with the cp210x usb serial driver. EM358x devices operating with the Ember Z-Net 5.1.2 stack may now connect to host PCs over a USB serial link. Signed-off-by:
Nathaniel Ting <nathaniel.ting@silabs.com> Signed-off-by:
-
Peter Hurley authored
commit 547039ec upstream. uart_get_baud_rate() will return baud == 0 if the max rate is set to the "magic" 38400 rate and the SPD_* flags are also specified. On the first iteration, if the current baud rate is higher than the max, the baud rate is clamped at the max (which in the degenerate case is 38400). On the second iteration, the now-"magic" 38400 baud rate selects the possibly higher alternate baud rate indicated by the SPD_* flag. Since only two loop iterations are performed, the loop is exited, a kernel WARNING is generated and a baud rate of 0 is returned. Reproducible with: setserial /dev/ttyS0 spd_hi base_baud 38400 Only perform the "magic" 38400 -> SPD_* baud transform on the first loop iteration, which prevents the degenerate case from recognizing the clamped baud rate as the "magic" 38400 value. Reported-by:
Robert Święcki <robert@swiecki.net> Signed-off-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
-
Lars-Peter Clausen authored
commit b598aacc upstream. "raw" is a property of a channel, but should not be part of the name of channel. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Lars-Peter Clausen authored
commit 79fa64eb upstream. We should check if a channel is enabled, not if no channels are enabled. Fixes: 550268ca ("staging:iio: scrap scan_count and ensure all drivers use active_scan_mask") Signed-off-by:
-
Lars-Peter Clausen authored
commit e1055473 upstream. In older versions of the IIO framework it was possible to pass a completely different set of channels to iio_buffer_register() as the one that is assigned to the IIO device. Commit 959d2952 ("staging:iio: make iio_sw_buffer_preenable much more general.") introduced a restriction that requires that the set of channels that is passed to iio_buffer_register() is a subset of the channels assigned to the IIO device as the IIO core will use the list of channels that is assigned to the device to lookup a channel by scan index in iio_compute_scan_bytes(). If it can not find the channel the function will crash. This patch fixes the issue by making sure that the same set of channels is assigned to the IIO device and passed to iio_buffer_register(). Note that we need to remove the IIO_CHAN_INFO_RAW and IIO_CHAN_INFO_SCALE info attributes from the channels since we don't actually want those to be registered. Fixes the following crash: Unable to handle kernel NULL pointer dereference at virtual address 00000016 pgd = d2094000 [00000016] *pgd=16e39831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM Modules linked in: CPU: 1 PID: 1695 Comm: bash Not tainted 3.17.0-06329-g29461ee #9686 task: d7768040 ti: d5bd4000 task.ti: d5bd4000 PC is at iio_compute_scan_bytes+0x38/0xc0 LR is at iio_compute_scan_bytes+0x34/0xc0 pc : [<c0316de8>] lr : [<c0316de4>] psr: 60070013 sp : d5bd5ec0 ip : 00000000 fp : 00000000 r10: d769f934 r9 : 00000000 r8 : 00000001 r7 : 00000000 r6 : c8fc6240 r5 : d769f800 r4 : 00000000 r3 : d769f800 r2 : 00000000 r1 : ffffffff r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 18c5387d Table: 1209404a DAC: 00000015 Process bash (pid: 1695, stack limit = 0xd5bd4240) Stack: (0xd5bd5ec0 to 0xd5bd6000) 5ec0: d769f800 d7435640 c8fc6240 d769f984 00000000 c03175a4 d7435690 d7435640 5ee0: d769f990 00000002 00000000 d769f800 d5bd4000 00000000 000b43a8 c03177f4 5f00: d769f810 0162b8c8 00000002 c8fc7e00 d77f1d08 d77f1da8 c8fc7e00 c01faf1c 5f20: 00000002 c010694c c010690c d5bd5f88 00000002 c8fc6840 c8fc684c c0105e08 5f40: 00000000 00000000 d20d1580 00000002 000af408 d5bd5f88 c000de84 c00b76d4 5f60: d20d1580 000af408 00000002 d20d1580 d20d1580 00000002 000af408 c000de84 5f80: 00000000 c00b7a44 00000000 00000000 00000002 b6ebea78 00000002 000af408 5fa0: 00000004 c000dd00 b6ebea78 00000002 00000001 000af408 00000002 00000000 5fc0: b6ebea78 00000002 000af408 00000004 bee96a4c 000a6094 00000000 000b43a8 5fe0: 00000000 bee969cc b6e2eb77 b6e6525c 40070010 00000001 00000000 00000000 [<c0316de8>] (iio_compute_scan_bytes) from [<c03175a4>] (__iio_update_buffers+0x248/0x438) [<c03175a4>] (__iio_update_buffers) from [<c03177f4>] (iio_buffer_store_enable+0x60/0x7c) [<c03177f4>] (iio_buffer_store_enable) from [<c01faf1c>] (dev_attr_store+0x18/0x24) [<c01faf1c>] (dev_attr_store) from [<c010694c>] (sysfs_kf_write+0x40/0x4c) [<c010694c>] (sysfs_kf_write) from [<c0105e08>] (kernfs_fop_write+0x110/0x154) [<c0105e08>] (kernfs_fop_write) from [<c00b76d4>] (vfs_write+0xbc/0x170) [<c00b76d4>] (vfs_write) from [<c00b7a44>] (SyS_write+0x40/0x78) [<c00b7a44>] (SyS_write) from [<c000dd00>] (ret_fast_syscall+0x0/0x30) Fixes: 959d2952 ("staging:iio: make iio_sw_buffer_preenable much more general.") Signed-off-by:
-
Lars-Peter Clausen authored
commit 6822ee34 upstream. "raw" is the name of a channel property, but should not be part of the channel name itself. Signed-off-by:
-
Lars-Peter Clausen authored
commit 824269c5 upstream. In older versions of the IIO framework it was possible to pass a completely different set of channels to iio_buffer_register() as the one that is assigned to the IIO device. Commit 959d2952 ("staging:iio: make iio_sw_buffer_preenable much more general.") introduced a restriction that requires that the set of channels that is passed to iio_buffer_register() is a subset of the channels assigned to the IIO device as the IIO core will use the list of channels that is assigned to the device to lookup a channel by scan index in iio_compute_scan_bytes(). If it can not find the channel the function will crash. This patch fixes the issue by making sure that the same set of channels is assigned to the IIO device and passed to iio_buffer_register(). Fixes the follow NULL pointer derefernce kernel crash: Unable to handle kernel NULL pointer dereference at virtual address 00000016 pgd = d53d0000 [00000016] *pgd=1534e831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM Modules linked in: CPU: 1 PID: 1626 Comm: bash Not tainted 3.15.0-19969-g2a180eb-dirty #9545 task: d6c124c0 ti: d539a000 task.ti: d539a000 PC is at iio_compute_scan_bytes+0x34/0xa8 LR is at iio_compute_scan_bytes+0x34/0xa8 pc : [<c03052e4>] lr : [<c03052e4>] psr: 60070013 sp : d539beb8 ip : 00000001 fp : 00000000 r10: 00000002 r9 : 00000000 r8 : 00000001 r7 : 00000000 r6 : d6dc8800 r5 : d7571000 r4 : 00000002 r3 : d7571000 r2 : 00000044 r1 : 00000001 r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 18c5387d Table: 153d004a DAC: 00000015 Process bash (pid: 1626, stack limit = 0xd539a240) Stack: (0xd539beb8 to 0xd539c000) bea0: c02fc0e4 d7571000 bec0: d76c1640 d6dc8800 d757117c 00000000 d757112c c0305b04 d76c1690 d76c1640 bee0: d7571188 00000002 00000000 d7571000 d539a000 00000000 000dd1c8 c0305d54 bf00: d7571010 0160b868 00000002 c69d3900 d7573278 d7573308 c69d3900 c01ece90 bf20: 00000002 c0103fac c0103f6c d539bf88 00000002 c69d3b00 c69d3b0c c0103468 bf40: 00000000 00000000 d7694a00 00000002 000af408 d539bf88 c000dd84 c00b2f94 bf60: d7694a00 000af408 00000002 d7694a00 d7694a00 00000002 000af408 c000dd84 bf80: 00000000 c00b32d0 00000000 00000000 00000002 b6f1aa78 00000002 000af408 bfa0: 00000004 c000dc00 b6f1aa78 00000002 00000001 000af408 00000002 00000000 bfc0: b6f1aa78 00000002 000af408 00000004 be806a4c 000a6094 00000000 000dd1c8 bfe0: 00000000 be8069cc b6e8ab77 b6ec125c 40070010 00000001 22940489 154a5007 [<c03052e4>] (iio_compute_scan_bytes) from [<c0305b04>] (__iio_update_buffers+0x248/0x438) [<c0305b04>] (__iio_update_buffers) from [<c0305d54>] (iio_buffer_store_enable+0x60/0x7c) [<c0305d54>] (iio_buffer_store_enable) from [<c01ece90>] (dev_attr_store+0x18/0x24) [<c01ece90>] (dev_attr_store) from [<c0103fac>] (sysfs_kf_write+0x40/0x4c) [<c0103fac>] (sysfs_kf_write) from [<c0103468>] (kernfs_fop_write+0x110/0x154) [<c0103468>] (kernfs_fop_write) from [<c00b2f94>] (vfs_write+0xd0/0x160) [<c00b2f94>] (vfs_write) from [<c00b32d0>] (SyS_write+0x40/0x78) [<c00b32d0>] (SyS_write) from [<c000dc00>] (ret_fast_syscall+0x0/0x30) Code: ea00000e e1a01008 e1a00005 ebfff6fc (e5d0a016) Fixes: 959d2952 ("staging:iio: make iio_sw_buffer_preenable much more general.") Signed-off-by:
-
Robin van der Gracht authored
commit 4250c90b upstream. Use byte_for_channel as iterator to properly initialize the buffer. Signed-off-by:
Robin van der Gracht <robin@protonic.nl> Acked-by:
Denis Ciocca <denis.ciocca@st.com> Signed-off-by:
-
Michal Hocko authored
commit 5695be14 upstream. PM freezer relies on having all tasks frozen by the time devices are getting frozen so that no task will touch them while they are getting frozen. But OOM killer is allowed to kill an already frozen task in order to handle OOM situtation. In order to protect from late wake ups OOM killer is disabled after all tasks are frozen. This, however, still keeps a window open when a killed task didn't manage to die by the time freeze_processes finishes. Reduce the race window by checking all tasks after OOM killer has been disabled. This is still not race free completely unfortunately because oom_killer_disable cannot stop an already ongoing OOM killer so a task might still wake up from the fridge and get killed without freeze_processes noticing. Full synchronization of OOM and freezer is, however, too heavy weight for this highly unlikely case. Introduce and check oom_kills counter which gets incremented early when the allocator enters __alloc_pages_may_oom path and only check all the tasks if the counter changes during the freezing attempt. The counter is updated so early to reduce the race window since allocator checked oom_killer_disabled which is set by PM-freezing code. A false positive will push the PM-freezer into a slow path but that is not a big deal. Changes since v1 - push the re-check loop out of freeze_processes into check_frozen_processes and invert the condition to make the code more readable as per Rafael Fixes: f660daac (oom: thaw threads if oom killed thread is frozen before deferring) Signed-off-by:
Michal Hocko <mhocko@suse.cz> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Cong Wang authored
commit 51fae6da upstream. Since f660daac (oom: thaw threads if oom killed thread is frozen before deferring) OOM killer relies on being able to thaw a frozen task to handle OOM situation but a3201227 (freezer: make freezing() test freeze conditions in effect instead of TIF_FREEZE) has reorganized the code and stopped clearing freeze flag in __thaw_task. This means that the target task only wakes up and goes into the fridge again because the freezing condition hasn't changed for it. This reintroduces the bug fixed by f660daac. Fix the issue by checking for TIF_MEMDIE thread flag in freezing_slow_path and exclude the task from freezing completely. If a task was already frozen it would get woken by __thaw_task from OOM killer and get out of freezer after rechecking freezing(). Changes since v1 - put TIF_MEMDIE check into freezing_slowpath rather than in __refrigerator as per Oleg - return __thaw_task into oom_scan_process_thread because oom_kill_process will not wake task in the fridge because it is sleeping uninterruptible [mhocko@suse.cz: rewrote the changelog] Fixes: a3201227 (freezer: make freezing() test freeze conditions in effect instead of TIF_FREEZE) Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
-
Libin Yang authored
commit d1585c89 upstream. This patch adds codec ID (0x80862883) and module alias for Braswell display codec. Signed-off-by:
Libin Yang <libin.yang@intel.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com> Signed-off-by:
-
Libin Yang authored
commit f31b2ffc upstream. Add HD Audio Device PCI ID for the Intel Braswell platform. It is an HDA Intel PCH controller. AZX_DCAPS_ALIGN_BUFSIZE is not necessary for this controller. Signed-off-by:
-
Derek Browne authored
commit 43e968ce upstream. This patch is to enable SDIO host controller for Intel Quark X1000. Signed-off-by:
Derek Browne <Derek.Browne@intel.com> Signed-off-by:
Alvin (Weike) Chen <alvin.chen@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Bryan O'Donoghue authored
commit aece118e upstream. Intel processors which don't report cache information via cpuid(2) or cpuid(4) need quirk code in the legacy_cache_size callback to report this data. For Intel that callback is is intel_size_cache(). This patch enables calling of cpu_detect_cache_sizes() inside of init_intel() and hence the calling of the legacy_cache callback in intel_size_cache(). Adding this call will ensure that PIII Tualatin currently in intel_size_cache() and Quark SoC X1000 being added to intel_size_cache() in this patch will report their respective cache sizes. This model of calling cpu_detect_cache_sizes() is consistent with AMD/Via/Cirix/Transmeta and Centaur. Also added is a string to idenitfy the Quark as Quark SoC X1000 giving better and more descriptive output via /proc/cpuinfo Adding cpu_detect_cache_sizes to init_intel() will enable calling of intel_size_cache() on Intel processors which currently no code can reach. Therefore this patch will also re-enable reporting of PIII Tualatin cache size information as well as add Quark SoC X1000 support. Comment text and cache flow logic suggested by Thomas Gleixner Signed-off-by:
Bryan O'Donoghue <pure.logic@nexus-software.ie> Cc: davej@redhat.com Cc: hmh@hmh.eng.br Link: http://lkml.kernel.org/r/1412641189-12415-3-git-send-email-pure.logic@nexus-software.ieSigned-off-by:
-
Pali Rohár authored
commit 36b4bed5 upstream. Code which changes policy to powersave changes also max_policy_pct based on max_freq. Code which change max_perf_pct has upper limit base on value max_policy_pct. When policy is changing from powersave back to performance then max_policy_pct is not changed. Which means that changing max_perf_pct is not possible to high values if max_freq was too low in powersave policy. Test case: $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 800000 $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 3300000 $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor performance $ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct 100 $ echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor $ echo 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq $ echo 20 > /sys/devices/system/cpu/intel_pstate/max_perf_pct $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor powersave $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 800000 $ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct 20 $ echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor $ echo 3300000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq $ echo 100 > /sys/devices/system/cpu/intel_pstate/max_perf_pct $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor performance $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 3300000 $ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct 24 And now intel_pstate driver allows to set maximal value for max_perf_pct based on max_policy_pct which is 24 for previous powersave max_freq 800000. This patch will set default value for max_policy_pct when setting policy to performance so it will allow to set also max value for max_perf_pct. Signed-off-by:
Pali Rohár <pali.rohar@gmail.com> Acked-by:
Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by:
-
Dirk Brandewie authored
commit c034b02e upstream. Currently the core does not expose scaling_cur_freq for set_policy() drivers this breaks some userspace monitoring tools. Change the core to expose this file for all drivers and if the set_policy() driver supports the get() callback use it to retrieve the current frequency. Link: https://bugzilla.kernel.org/show_bug.cgi?id=73741Signed-off-by:
-
Jan Kara authored
commit 599a9b77 upstream. When we fail to load block bitmap in __ext4_new_inode() we will dereference NULL pointer in ext4_journal_get_write_access(). So check for error from ext4_read_block_bitmap(). Coverity-id: 989065 Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Darrick J. Wong authored
commit 98c1a759 upstream. If metadata checksumming is turned on for the FS, we need to tell the journal to use checksumming too. Signed-off-by:
Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by:
-
Jan Kara authored
commit 9378c676 upstream. When there are no meta block groups update_backups() will compute the backup block in 32-bit arithmetics thus possibly overflowing the block number and corrupting the filesystem. OTOH filesystems without meta block groups larger than 16 TB should be rare. Fix the problem by doing the counting in 64-bit arithmetics. Coverity-id: 741252 Signed-off-by:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
-
