| Age | Commit message (Collapse) | Author |
|---|
|
commit b16634adce951a7371be931487034f7365971ed0 upstream.
Use the new generic usb-serial wait_until_sent implementation to wait
for hardware buffers to drain.
This removes the need to check the hardware buffers in chars_in_buffer
and thus removes the overhead introduced by commit 263e1f9f ("USB:
io_ti: query hardware-buffer status in chars_in_buffer") without
breaking tty_wait_until_sent (used by, for example, tcdrain, tcsendbreak
and close).
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a37025b5c702aaf87191cd75fcc42c54454f16f5 upstream.
Use the new generic usb-serial wait_until_sent implementation to wait
for hardware buffers to drain.
This removes the need to check the hardware buffers in chars_in_buffer
and thus removes the overhead introduced by commit 6f602912 ("usb:
serial: ftdi_sio: Add missing chars_in_buffer function") without
breaking tty_wait_until_sent (used by, for example, tcdrain, tcsendbreak
and close).
Reported-by: Stas Sergeev <stsp@list.ru>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c4133648bbce9e6b425a74cc890c8e4df51acaa9 upstream.
Use usb-serial port rather than tty as argument to get_modem_status.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit dcf0105039660e951dfea348d317043d17988dfc upstream.
Add generic wait_until_sent implementation which polls for empty
hardware buffers using the new port-operation tx_empty.
The generic implementation will be used for all sub-drivers that
implement tx_empty but does not define wait_until_sent.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0693196fe7bbb5e6cafd255dfce91ff6d10bc18f upstream.
Add wait_until_sent operation which can be used to wait for hardware
buffers to drain.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e3de42b68478a8c95dd27520e9adead2af9477a5 upstream.
Currently the driver's assumed behavior for a modeset with an attached
FB is that the corresponding connector will be switched to DPMS ON mode
if it happened to be in DPMS OFF (or another power save mode). This
wasn't enforced though if only the FB changed, everything else (format,
connector etc.) remaining the same. In this case we only set the new FB
base and left the connector in the old power save mode.
Fix this by forcing a full modeset whenever there is an attached FB and
any affected connector is in a power save mode.
V_2: Run the test for encoders in power save mode outside the the
test for fb change: user space may have just disabled the encoders
but left everything else in place. Make sure the connector list is
not empty before running this test.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Egbert Eich <eich@suse.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61642
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59834
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59339
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64178
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65559
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Apply Jani's s/connector_off/is_crtc_connector_off bikeshed.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 2eb3a81eef0510511a3211bb3da560f446a8c8de upstream.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6c5d4c96f979611f0165dc825af9e1cea8dd35b9 upstream.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7e0e41963740525af702bb23edede8ae9afc4ac0 upstream.
radeon currently uses a drm function to get the speed capabilities for
the bus, drm_pcie_get_speed_cap_mask. However, this is a non-standard
method of performing this detection and this patch changes it to use
the max_bus_speed attribute.
From: Lucas Kannebley Tavares <lucaskt@linux.vnet.ibm.com>
Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 88e7b167a079f090405ab4390b629b5effdab41a upstream.
Set dev->dev.type in alloc_pci_dev so that archs that have their own
versions of pci_setup_device get this set properly in order to ensure
things like the boot_vga sysfs parameter get created as expected.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit cbbd379aa43890f36da934f5af619d2fb8ec3d87 upstream.
By having a higher max resolution we can now set up a virtual
framebuffer that spans several monitors. 4096 should be ok since we're
gen 3 or higher and should be enough for most dual head setups.
Bugzilla:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-modesetting/+bug/1169147
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5bf8fae33d14cc5c3c53a926f9079f92c8b082b0 upstream.
we never allocate a TRB pool for physical endpoints
0 and 1 so trying to free it (a invalid TRB pool pointer)
will lead us in a warning while removing dwc3.ko module.
In order to fix the situation, all we have to do is skip
dwc3_free_trb_pool() for physical endpoints 0 and 1 just
as we while deleting endpoints from the endpoints list.
Signed-off-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ea7f665612fcc73da6b7698f468cd5fc03a30d47 upstream.
Commit 9f29ab11ddbf ("ACPI / scan: do not match drivers against objects
having scan handlers") introduced a boot regression on Tony's ia64 HP
rx2600. Tony says:
"It panics with the message:
Kernel panic - not syncing: Unable to find SBA IOMMU: Try a generic or DIG kernel
[...] my problem comes from arch/ia64/hp/common/sba_iommu.c
where the code in sba_init() says:
acpi_bus_register_driver(&acpi_sba_ioc_driver);
if (!ioc_list) {
but because of this change we never managed to call ioc_init()
so ioc_list doesn't get set up, and we die."
Revert it to avoid this breakage and we'll fix the problem it attempted
to address later.
Reported-by: Tony Luck <tony.luck@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7abb690a0e095717420ba78dcab4309abbbec78a upstream.
Chris Wilson noticed that since
commit 1f83fee08d625f8d0130f9fe5ef7b17c2e022f3c [v3.9]
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Nov 15 17:17:22 2012 +0100
drm/i915: clear up wedged transitions
X can again get -EIO when it does not expect it. And even worse score
a SIGBUS when accessing gtt mmaps. The established ABI is that we
_only_ return an -EIO from execbuf - all other ioctls should just
work. And since the reset code moves all bos out of gpu domains and
clears out all the last_seqno/ring tracking there really shouldn't be
any reason for non-execbuf code to ever touch the hw and see an -EIO.
After some extensive discussions we've noticed that these spurios -EIO
are caused by i915_gem_wait_for_error:
http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg20540.html
That is easy to fix by returning 0 instead of -EIO, since grabbing the
dev->struct_mutex does not yet mean that we actually want to touch the
hw. And so there is no reason at all to fail with -EIO.
But that's not the entire since, since often (at least it's easily
googleable) dmesg indicates that the reset fails and we declare the
gpu wedged. Then, quite a bit later X wakes up with the "Timed out
waiting for the gpu reset to complete" DRM_ERROR message in
wait_for_errror and brings down the desktop with an -EIO/SIGBUS.
So clearly we're missing a wakeup somewhere, since the gpu reset just
doesn't take 10 seconds to complete. And indeed we're do handle the
terminally wedged state wrong.
Fix this all up.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 45a211d75137b1ac869a8a758a6667f15827a115 upstream.
Last year, a patch was made for the "HP t5740e Thin Client" (see
http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html).
This device reports an lvds panel, but does not really have one.
The predecessor of this device is the "hp t5740", which also does not have
an lvds panel. This patch will add the same quirk for this device.
Signed-off-by: Ben Mesman <ben@bnc.nl>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 53d3b4d7778daf15900867336c85d3f8dd70600c upstream.
In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used
for DDC. Thus the code will always have to rely on a LVDS panel
mode supplied by VBT.
In most cases this succeeds, so this didn't get detected for quite
a while.
This regression seems to have been introduced in
commit f899fc64cda8569d0529452aafc0da31c042df2e
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Jul 20 15:44:45 2010 -0700
drm/i915: use GMBUS to manage i2c links
Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add note about which commit likely introduced this issue.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b7ea85a4fed37835eec78a7be3039c8dc22b8178 upstream.
When GPU acceleration is disabled, drm_vblank_cleanup() will free the
vblank-related data, such as vblank_refcount, vblank_inmodeset, etc.
But we found that drm_vblank_post_modeset() may be called after the
cleanup, which use vblank_refcount and vblank_inmodeset. And this will
cause a kernel panic.
Fix this by return immediately if dev->num_crtcs is zero. This is the
same thing that drm_vblank_pre_modeset() does.
Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup():
[ 62.628906] [<ffffffff804868d0>] drm_vblank_post_modeset+0x34/0xb4
[ 62.628906] [<ffffffff804c7008>] atombios_crtc_dpms+0xb4/0x174
[ 62.628906] [<ffffffff804c70e0>] atombios_crtc_commit+0x18/0x38
[ 62.628906] [<ffffffff8047f038>] drm_crtc_helper_set_mode+0x304/0x3cc
[ 62.628906] [<ffffffff8047f92c>] drm_crtc_helper_set_config+0x6d8/0x988
[ 62.628906] [<ffffffff8047dd40>] drm_fb_helper_set_par+0x94/0x104
[ 62.628906] [<ffffffff80439d14>] fbcon_init+0x424/0x57c
[ 62.628906] [<ffffffff8046a638>] visual_init+0xb8/0x118
[ 62.628906] [<ffffffff8046b9f8>] take_over_console+0x238/0x384
[ 62.628906] [<ffffffff80436df8>] fbcon_takeover+0x7c/0xdc
[ 62.628906] [<ffffffff8024fa20>] notifier_call_chain+0x44/0x94
[ 62.628906] [<ffffffff8024fcbc>] __blocking_notifier_call_chain+0x48/0x68
[ 62.628906] [<ffffffff8042d990>] register_framebuffer+0x228/0x260
[ 62.628906] [<ffffffff8047e010>] drm_fb_helper_single_fb_probe+0x260/0x314
[ 62.628906] [<ffffffff8047e2c4>] drm_fb_helper_initial_config+0x200/0x234
[ 62.628906] [<ffffffff804e5560>] radeon_fbdev_init+0xd4/0xf4
[ 62.628906] [<ffffffff804e0e08>] radeon_modeset_init+0x9bc/0xa18
[ 62.628906] [<ffffffff804bfc14>] radeon_driver_load_kms+0xdc/0x12c
[ 62.628906] [<ffffffff8048b548>] drm_get_pci_dev+0x148/0x238
[ 62.628906] [<ffffffff80423564>] local_pci_probe+0x5c/0xd0
[ 62.628906] [<ffffffff80241ac4>] work_for_cpu_fn+0x1c/0x30
[ 62.628906] [<ffffffff802427c8>] process_one_work+0x274/0x3bc
[ 62.628906] [<ffffffff80242934>] process_scheduled_works+0x24/0x44
[ 62.628906] [<ffffffff8024515c>] worker_thread+0x31c/0x3f4
[ 62.628906] [<ffffffff802497a8>] kthread+0x88/0x90
[ 62.628906] [<ffffffff80206794>] kernel_thread_helper+0x10/0x18
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Binbin Zhou <zhoubb@lemote.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 91f8f105f2b82b4a38dee2d74760bc39d40ec42c upstream.
This is a bug fix for some versions of g200se cards while doing
mode-setting.
Signed-off-by: Christopher Harvey <charvey@matrox.com>
Tested-by: Julia Lemire <jlemire@matrox.com>
Acked-by: Julia Lemire <jlemire@matrox.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 591bfcfc334a003ba31c0deff03b22e73349939b upstream.
On a system with both MAX1617 and JC42 sensors, JC42 sensors can be misdetected
as LM84. Strengthen detection sufficiently enough to avoid this misdetection.
Also improve detection for ADM1021.
Modeled after chip detection code in sensors-detect command.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1cbcca302a318499f20a512847c5d6a510c08c35 upstream.
It's not supported yet. Fixes display issues when
users force it on.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e49f3959a96dc279860af7e86e6dbcfda50580a5 upstream.
The current radeon driver initialization routines, when using KMS, are written
so that the IRQ installation routine is called before initializing the WB buffer
and the CP rings. With some ASICs, though, the IRQ routine tries to access the
GFX_INDEX ring causing a call to RREG32 with the value of -1 in
radeon_fence_read. This, in turn causes the system to completely hang with some
cards, requiring a hard reset.
A call stack that can cause such a hang looks like this (using rv515 ASIC for the
example here):
* rv515_init (rv515.c)
* radeon_irq_kms_init (radeon_irq_kms.c)
* drm_irq_install (drm_irq.c)
* radeon_driver_irq_preinstall_kms (radeon_irq_kms.c)
* rs600_irq_process (rs600.c)
* radeon_fence_process - due to SW interrupt (radeon_fence.c)
* radeon_fence_read (radeon_fence.c)
* hang due to RREG32(-1)
The patch moves the IRQ installation to the card startup routine, after the ring
has been initialized, but before the IRQ has been set. This fixes the issue, but
requires a check to see if the IRQ is already installed, as is the case in the
system resume codepath.
I have tested the patch on three machines using the rv515, the rv770 and the
evergreen ASIC. They worked without issues.
This seems to be a known issue and has been reported on several bug tracking
sites by various distributions (see links below). Most of reports recommend
booting the system with KMS disabled and then enabling KMS by reloading the
radeon module. For some reason, this was indeed a usable workaround, however,
UMS is now deprecated and disabled by default.
Bug reports:
https://bugzilla.redhat.com/show_bug.cgi?id=845745
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/561789
https://bbs.archlinux.org/viewtopic.php?id=156964
Signed-off-by: Adis Hamzić <adis@hamzadis.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
commit 9ecb41bd8cf002fd8f3e063db4df81647ddd623c upstream.
The pm runtime reference counting of the driver is broken for the case
when there is more than one transfer queued, leading to the device being
runtime suspend while active. Fix it.
Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit af1d486c18bad7820b0ca52b413458914231102c upstream.
HP wmi platform driver fails to initialize GPS and causes poweroff
failure in HP Elitebook 6930p.
Call Trace:
[<ffffffffa088d25a>] hp_wmi_bios_setup+0x25a/0x3a0 [hp_wmi]
[<ffffffff8135978c>] platform_drv_probe+0x3c/0x70
[<ffffffff81356d6a>] ? driver_sysfs_add+0x7a/0xb0
[<ffffffff81357407>] driver_probe_device+0x87/0x3a0
[<ffffffff813577f3>] __driver_attach+0x93/0xa0
[<ffffffff81357760>] ? __device_attach+0x40/0x40
[<ffffffff81355403>] bus_for_each_dev+0x63/0xa0
[<ffffffff81356e8e>] driver_attach+0x1e/0x20
[<ffffffff81356a28>] bus_add_driver+0x1f8/0x2b0
[<ffffffff81357e81>] driver_register+0x71/0x150
[<ffffffff813594e6>] platform_driver_register+0x46/0x50
[<ffffffff813595ab>] platform_driver_probe+0x1b/0xa0
[<ffffffffa088d55e>] hp_wmi_init+0x1be/0x1fb [hp_wmi]
[<ffffffffa088d3a0>] ? hp_wmi_bios_setup+0x3a0/0x3a0 [hp_wmi]
[<ffffffff8100210a>] do_one_initcall+0x10a/0x160
[<ffffffff810bdac6>] load_module+0x1b46/0x2640
[<ffffffff8128da20>] ? ddebug_proc_write+0xf0/0xf0
[<ffffffff810be662>] sys_init_module+0xa2/0xf0
[<ffffffff814d975d>] system_call_fastpath+0x1a/0x1f
Code: 48 ff ff ff 80 7b 24 00 74 d2 41 83 e5 01 45 38 ec 74 c9 48 8d bb a0 03 00 00 e8 ed fb aa e0 5b 41 5c 41 5d 44 89 f0 41 5e 5d c3 <0f> 0b 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66
RIP [<ffffffffa05c57af>] rfkill_set_hw_state+0x9f/0xb0 [rfkill]
RSP <ffff880071523b60>
Check code and find this error is caused by misusing variable bluetooth_rfkill
where gps_rfkill should be.
Reported-and-tested-by: Iru Cai <mytbk920423@gmail.com>
References: https://bugzilla.kernel.org/show_bug.cgi?id=58401
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7cd8407d53ef5fb0280fcbe34f42311472f90feb upstream.
Commit b378549 (ACPI / PM: Do not power manage devices in unknown
initial states) added code to force devices without _PSC, but having
_PS0 defined in the ACPI namespace, into ACPI power state D0 by
executing _PS0 for them. That turned out to break Toshiba P870-303,
however, so revert that code.
References: https://bugzilla.kernel.org/show_bug.cgi?id=58201
Reported-and-tested-by: Jerome Cantenot <jerome.cantenot@gmail.com>
Tracked-down-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9f29ab11ddbfc12db54df5a66dab22b39ad94e8e upstream.
With the introduction of ACPI scan handlers, an ACPI device object
with an ACPI scan handler attached to it must not be bound to an ACPI
driver any more. Therefore it doesn't make sense to match those
ACPI device objects against a newly registered ACPI driver in
acpi_bus_match(), so make that function return 0 if the device
object passed to it has an ACPI scan handler attached.
This also addresses a regression related to a broken ACPI table in
the BIOS, where it has defined a _ROM method under the PCI root
bridge object. This causes the video module to treat that object
as a display controller device (since only display devices are
supposed to have a _ROM method defined according to the ACPI spec).
As a result, the ACPI video driver binds to the PCI root bridge
object and overwrites the previously assigned driver_data field of
it, causing subsequent calls to acpi_get_pci_dev() to fail.
[rjw: Subject and changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=58091
Reported-by: Jason Cassell <bluesloth600@gmail.com>
Reported-and-bisected-by: Dmitry S. Demin <dmitryy.demin@gmail.com>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 780a6ec640a3fed671fc2c40e4dd30c03eca3ac3 upstream.
This patch addresses kernel bug 56661. BIOS reports an incorrect
backlight value, causing the driver to switch off the backlight
completely during startup. This patch ignores the incorrect value from
BIOS.
References: https://bugzilla.kernel.org/show_bug.cgi?id=56661
Signed-off-by: Ash Willis <ashwillis@programmer.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit fedbe9bc6fd3e14b1ffbb3dac407777ac4a3650c upstream.
On HP m4 lapops, BIOS reports minimum backlight on boot and
causes backlight to dim completely. This ignores the initial backlight
values and set to max brightness.
References: https://bugs.launchpad.net/bugs/1184501
Signed-off-by: Alex Hung <alex.hung@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8673b83bf2f013379453b4779047bf3c6ae387e4 upstream.
Commit 4b31e774 (Always set P-state on initialization) fixed bug
#4634 and caused the driver to always set the target P-State at
least once since the initial P-State may not be the desired one.
Commit 5a1c0228 (cpufreq: Avoid calling cpufreq driver's target()
routine if target_freq == policy->cur) caused a regression in
this behavior.
This fixes the regression by setting policy->cur based on the CPU's
target frequency rather than the CPU's current reported frequency
(which may be different). This means that the P-State will be set
initially if the CPU's target frequency is different from the
governor's target frequency.
This fixes an issue where setting the default governor to
performance wouldn't correctly enable turbo mode on all cores.
Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com>
Reviewed-by: Len Brown <len.brown@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a26f009a070e840fadacb91013b2391ba7ab6cc2 upstream.
The register access to enable hardware flow control depends on the
device port number and not the port minor number.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 849513a7809175420d353625b6f651d961e99d49 upstream.
The control and bulk-message timeouts are specified in milliseconds and
should not depend on HZ.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 72ea18a558ed7a63a50bb121ba60d73b5b38ae30 upstream.
The read_mos_reg function is called with stack-allocated buffers, which
must not be used for control messages.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 15ee89c3347fbf58a4361011eda5ac2731e45126 upstream.
Fix regression introduced by commit 0eafe4de1a ("USB: serial: mos7840:
add support for MCS7810 devices") which used stack-allocated buffers for
control messages.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit fdc03438f53a00294ed9939eb3a1f6db6f3d8963 upstream.
This patch reverts commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d
(USB: EHCI: fix bug in scheduling periodic split transfers). The
commit was valid -- it fixed a real bug -- but the periodic scheduler
in ehci-hcd is in such bad shape (especially the part that handles
split transactions) that fixing one bug is very likely to cause
another to surface. That's what happened in this case; the result was
choppy and noisy playback on certain 24-bit audio devices.
The only real fix will be to rewrite this entire section of code. My
next project...
This fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110.
Thanks to Tim Richardson for extra testing and feedback, and to Joseph
Salisbury and Tyson Tan for tracking down the original source of the
problem.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Joseph Salisbury <joseph.salisbury@canonical.com>
CC: Tim Richardson <tim@tim-richardson.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5f8e2c07d75967ee49a5da1d21ddf5f50d48cda0 upstream.
The first and second interrupt-in urbs are swapped for some Treo/Kyocera
devices, but the urb context was never updated with the new port.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9eecf22d2b375b9064a20421c6c307b760b03d46 upstream.
When configuring the port (e.g. set_termios) the port minor number
rather than the port number was used in the request (and they only
coincide for minor number 0).
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6529591e3eef65f0f528a81ac169f6e294b947a7 upstream.
The patch adds a new HIDCOM device and does not affect other devices
driven by the cypress_M8 module. Changes are:
- add VendorID ProductID to device tables
- skip unstable speed check because FRWD uses 115200bps
- skip reset at probe which is an issue workaround for this
particular device.
Signed-off-by: Robert Butora <robert.butora.fi@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d8a1d0d54d5fdac0347b75e9afd554b3dfaa465f upstream.
Remove bogus port-number check in open and close, which prevented this
driver from being used with a minor number different from zero.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5cbfa3acdcbf19e1d29cf3479ad8200d2e644e44 upstream.
The control-message timeout is specified in milliseconds and should not
depend on HZ.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 420021a395ce38b7ab2cceb52dee4038be7d8fa3 upstream.
Fix regression introduced by commit 214916f2e ("USB: visor: reimplement
using generic framework") which broke initialisation of Treo/Kyocera
devices that re-mapped bulk-in endpoints.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 634371911730a462626071065b64cd6e1fe213e0 upstream.
The control-message timeout is specified in milliseconds and should not
depend on HZ.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a07088098a650267b2eda689538133a324b9523f upstream.
The outcont_endpoints array was indexed using the port minor number
(which can be greater than the array size) rather than the device port
number.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6c13ff68a7ce01da7a51b44241a7aad8eaaedde7 upstream.
The bulk-message timeout is specified in milliseconds and should not
depend on HZ.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ed74df12dc3e07a37d99aab60211496e871488a0 upstream.
Since highmem PIO URB handling was introduced in:
8e8a551 usb: musb: host: Handle highmem in PIO mode
when a URB is being handled it may happen that the static use_sg flag
was set by a previous URB with buffer in highmem. This leads to error
in handling the present URB.
Fix this by making the use_sg flag URB specific.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Virupax Sadashivpetimath <virupax.sadashivpetimath@stericsson.com>
Signed-off-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c3897aa5386faba77e5bbdf94902a1658d3a5b11 upstream.
Some xHCI hosts contain a "redriver" from TI that silently drops port
status connect changes if the port slips into Compliance Mode. If the
port slips into compliance mode while the host is in D0, there will not
be a port status change event. If the port slips into compliance mode
while the host is in D3, the host will not send a PME. This includes
when the system is suspended (S3) or hibernated (S4).
If this happens when the system is in S3/S4, there is nothing software
can do. Other port status change events that would normally cause the
host to wake the system from S3/S4 may also be lost. This includes
remote wakeup, disconnects and connects on other ports, and overrcurrent
events. A decision was made to _NOT_ disable system suspend/hibernate
on these systems, since users are unlikely to enable wakeup from S3/S4
for the xHCI host.
Software can deal with this issue when the system is in S0. A work
around was put in to poll the port status registers for Compliance Mode.
The xHCI driver will continue to poll the registers while the host is
runtime suspended. Unfortunately, that means we can't allow the PCI
device to go into D3cold, because power will be removed from the host,
and the config space will read as all Fs.
Disable D3cold in the xHCI PCI runtime suspend function.
This patch should be backported to kernels as old as 3.2, that
contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host:
xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 88696ae432ce7321540ac53d9caab3de9118b094 upstream.
If for whatever reason we fall into fail path in xhci_mem_init()
before bw table gets initialized we may access the uninitialized lists
in xhci_mem_cleanup().
Check for bw table before traversing lists in cleanup routine.
This patch should be backported to kernels as old as 3.2, that contain
the commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe "xhci: Store
information about roothubs and TTs."
Reported-by: Sergey Dyasly <dserrg@gmail.com>
Tested-by: Sergey Dyasly <dserrg@gmail.com>
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 331de00a64e5027365145bdf51da27b9ce15dfd5 upstream.
It is possible that we fail on xhci_mem_init, just before doing
the INIT_LIST_HEAD, and calling xhci_mem_cleanup.
Problem is that, the list_for_each_entry_safe macro, assumes
list heads are initialized (not NULL), and dereferences their 'next'
pointer, causing a kernel panic if this is not yet initialized.
Let's protect from that by moving inits to the beginning.
This patch should be backported to kernels as old as 3.2, that
contain the commit 9574323c39d1f8359a04843075d89c9f32d8b7e6 "xHCI: test
USB2 software LPM".
Signed-off-by: Sergio Aguirre <sergio.a.aguirre.rodriguez@intel.com>
Acked-by: David Cohen <david.a.cohen@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 77df9e0b799b03e1d5d9c68062709af5f637e834 upstream.
Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP
Hardware) was a workaround for systems using the SN65LVPE502CP,
controller, but it introduced a bug in resume from hibernate.
The fix created a timer, comp_mode_recovery_timer, which is deleted from
a timer list when xhci_suspend() is called. However, the hibernate image,
including the timer list containing the comp_mode_recovery_timer, had
already been saved before the timer was deleted.
Upon resume from hibernate, the list containing the comp_mode_recovery_timer
is restored from the image saved to disk, and xhci_resume(), assuming that
the timer had been deleted by xhci_suspend(), makes a call to
compliance_mode_recoery_timer_init(), which creates a new instance of the
comp_mode_recovery_timer and attempts to place it into the same list in which
it is already active, thus corrupting the list during the list_add() call.
At this point, a call trace is emitted indicating the list corruption.
Soon afterward, the system locks up, the watchdog times out, and the
ensuing NMI crashes the system.
The problem did not occur when resuming from suspend. In suspend, the
image in RAM remains exactly as it was when xhci_suspend() deleted the
comp_mode_recovery_timer, so there is no problem when xhci_resume()
creates a new instance of this timer and places it in the still empty
list.
This patch avoids the problem by deleting the timer in xhci_resume()
when resuming from hibernate. Now xhci_resume() can safely make the
call to create a new instance of this timer, whether returning from
suspend or hibernate.
Thanks to Alan Stern for his help with understanding the problem.
[Sarah reworked this patch to cover the case where the xHCI restore
register operation fails, and (temp & STS_SRE) is true (and we re-init
the host, including re-init for the compliance mode), but hibernate is
false. The original patch would have caused list corruption in this
case.]
This patch should be backported to kernels as old as 3.2, that
contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host:
xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
Signed-off-by: Tony Camuso <tcamuso@redhat.com>
Tested-by: Tony Camuso <tcamuso@redhat.com>
Acked-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f28c42c576b293b3a1daaed8ca2775ebc2fe5398 upstream.
If the glue layer is removed first (core layer later),
it deletes the phy device first, then the core device.
But at core's removal, it still uses PHY's resources, it may
cause kernel's oops. It is much like the problem
Paul Zimmerman reported at:
http://marc.info/?l=linux-usb&m=136547502011472&w=2.
Besides, it is reasonable the PHY is deleted at last as
the controller is the PHY's user.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 73228a0538a70ebc4547bd09dee8971360dc1d87 upstream.
Per some ZTE Linux drivers I found for the AC2716, the following patch
moves most ZTE CDMA devices from option to zte_ev. The blacklist stuff
that option does is not required with zte_ev, because it doesn't
implement any of the send_setup hooks which the blacklist suppressed.
I did not move the 2718 over because I could not find any ZTE Linux
drivers for that device, nor even any Windows drivers.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b8a24e6281d37243c06b9497dcbfaa98c1e2ad35 upstream.
The mode used by Windows for the Huawei E1820 will use the
same ff/ff/ff class codes for both serial and network
functions.
Reported-by: Graham Inggs <graham.inggs@uct.ac.za>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
