- 21 10月, 2013 1 次提交
-
-
由 David Herrmann 提交于
The LEGO-wiimote uses a different VID than the Nintendo ID. The device is technically the same so add the ID. Cc: <stable@vger.kernel.org> # 3.11+ Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 19 10月, 2013 8 次提交
-
-
由 Alex Deucher 提交于
It causes hangs on some asics. Disable on DCE6+ as well just to be on the safe side. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
In 3.12 I changed audio to be enabled by default, but you still had to turn it on via xrandr. This was confusing to users so change it to minic the previous behavior: - audio option is set to -1 (auto) by default which is the current 3.12 behavior (audio is enabled but requires xrandr to turn it on). - if audio = 1, the audio is enabled without needing to mess with xrandr (previous behavior) - audio = 0 disables audio It retains the new feature of allowing the user to enable audio on the fly with xrandr, but turns audio on automatically if radeon.audio=1 is set which is what most users expect. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Alex Deucher 提交于
It causes hangs on some asics. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=70439Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Alex Deucher 提交于
Prevent driver load problems if the smc is missing. bug: https://bugzilla.kernel.org/show_bug.cgi?id=63011Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Prevent driver load problems if the smc is missing. bug: https://bugzilla.kernel.org/show_bug.cgi?id=63011Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Tested-by: NMikko Rapeli <mikko.rapeli@iki.fi> Cc: stable@vger.kernel.org
-
由 Christian König 提交于
This only seem to work for H.264 but not for VC-1 streams. Need to investigate further why exactly. This reverts commit 4b40e592. Signed-off-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
Stop leaking IB memory and scratch register space when the test fails. Signed-off-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Some rs780 asics seem to be affected as well. See: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=91f3a6aaf280294b07c05dfe606e6c27b7ba3c72 Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60791Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 18 10月, 2013 5 次提交
-
-
由 Ben Widawsky 提交于
Once the machine gets to a certain point in the suspend process, we expect the GPU to be idle. If it is not, we might corrupt memory. Empirically (with an early version of this patch) we have seen this is not the case. We cannot currently explain why the latent GPU writes occur. In the technical sense, this patch is a workaround in that we have an issue we can't explain, and the patch indirectly solves the issue. However, it's really better than a workaround because we understand why it works, and it really should be a safe thing to do in all cases. The noticeable effect other than the debug messages would be an increase in the suspend time. I have not measure how expensive it actually is. I think it would be good to spend further time to root cause why we're seeing these latent writes, but it shouldn't preclude preventing the fallout. NOTE: It should be safe (and makes some sense IMO) to also keep the VALID bit unset on resume when we clear_range(). I've opted not to do this as properly clearing those bits at some later point would be extra work. v2: Fix bugzilla link Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=65496 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59321Tested-by: NTakashi Iwai <tiwai@suse.de> Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Tested-By: NTodd Previte <tprevite@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ben Widawsky 提交于
We need this to work around a corruption when the boot kernel image loads the hibernated kernel image from swap on Haswell systems - somehow not everything is properly shut off. This is just the prep work, the next patch will implement the actual workaround. Signed-off-by: NBen Widawsky <ben@bwidawsk.net> [danvet: Add a commit message suitable for -fixes and add cc: stable] Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Nikolai Kondrashov 提交于
Revert some changes done in 77463838. Revert all changes done in hidinput_calc_abs_res as it mistakingly used "Unit" item exponent nibbles to affect resolution value. This wasn't breaking resolution calculation of relevant axes of any existing devices, though, as they have only one dimension to their units and thus 1 in the corresponding nible. Revert to reading "Unit Exponent" item value as a signed integer in hid_parser_global to fix reading specification-complying values. This fixes resolution calculation of devices complying to the HID standard, including Huion, KYE, Waltop and UC-Logic graphics tablets which have their report descriptors fixed by the drivers. Explanations follow. There are two "unit exponents" in HID specification and it is important not to mix them. One is the global "Unit Exponent" item and another is nibble values in the global "Unit" item. See 6.2.2.7 Global Items. The "Unit Exponent" value is just a signed integer and is used to scale the integer resolution unit values, so fractions can be expressed. The nibbles of "Unit" value are used to select the unit system (nibble 0), and presence of a particular basic unit type in the unit formula and its *exponent* (or power, nibbles 1-6). And yes, the latter is in two complement and zero means absence of the unit type. Taking the representation example of (integer) joules from the specification: [mass(grams)][length(centimeters)^2][time(seconds)^-2] * 10^-7 the "Unit Exponent" would be -7 (or 0xF9, if stored as a byte) and the "Unit" value would be 0xE121, signifying: Nibble Part Value Meaning ----- ---- ----- ------- 0 System 1 SI Linear 1 Length 2 Centimeters^2 2 Mass 1 Grams 3 Time -2 Seconds^-2 To give the resolution in e.g. hundredth of joules the "Unit Exponent" item value should have been -9. See also the examples of "Unit" values for some common units in the same chapter. However, there is a common misunderstanding about the "Unit Exponent" value encoding, where it is assumed to be stored the same as nibbles in "Unit" item. This is most likely due to the specification being a bit vague and overloading the term "unit exponent". This also was and still is proliferated by the official "HID Descriptor Tool", which makes this mistake and stores "Unit Exponent" as such. This format is also mentioned in books such as "USB Complete" and in Microsoft's hardware design guides. As a result many devices currently on the market use this encoding and so the driver should support them. Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com> Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Chris Wilson 提交于
Apply the protections from commit 1b2f1489 Author: Dave Airlie <airlied@redhat.com> Date: Sat Aug 14 20:20:34 2010 +1000 drm: block userspace under allocating buffer and having drivers overwrite it (v2) to the core ioctl structs as well, for we found one instance where there is a 32-/64-bit size mismatch and were guilty of writing beyond the end of the user's buffer. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Dave Airlie <airlied@redhat.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Cc: dri-devel@lists.freedesktop.org Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Greg Kroah-Hartman 提交于
This reverts commit 90d33f3e as it's not the correct fix for this issue, and it causes a build warning to be added to the kernel tree. Cc: K. Y. Srinivasan <kys@microsoft.com> Cc: <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 17 10月, 2013 13 次提交
-
-
由 Rafael J. Wysocki 提交于
Two functions defined in device_pm.c, acpi_dev_pm_add_dependent() and acpi_dev_pm_remove_dependent(), have no callers and may be dropped, so drop them. Moreover, they are the only functions adding entries to and removing entries from the power_dependent list in struct acpi_device, so drop that list too. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Aaron Lu 提交于
Previously, we wanted SCSI devices corrsponding to ATA devices to be runtime resumed when the power resource for those ATA device was turned on by some other device, so we added the SCSI device to the dependent device list of the ATA device's ACPI node. However, this code has no effect after commit 41863fce (ACPI / power: Drop automaitc resume of power resource dependent devices) and the mechanism it was supposed to implement is regarded as a bad idea now, so drop it. [rjw: Changelog] Signed-off-by: NAaron Lu <aaron.lu@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Yasuaki Ishimatsu 提交于
When inserting a wrong value to /sys/devices/system/memory/memoryX/state file, following messages are shown. And device_hotplug_lock is never released. ================================================ [ BUG: lock held when returning to user space! ] 3.12.0-rc4-debug+ #3 Tainted: G W ------------------------------------------------ bash/6442 is leaving the kernel with locks still held! 1 lock held by bash/6442: #0: (device_hotplug_lock){+.+.+.}, at: [<ffffffff8146cbb5>] lock_device_hotplug_sysfs+0x15/0x50 This issue was introdued by commit fa2be40f (drivers: base: use standard device online/offline for state change). This patch releases device_hotplug_lcok when store_mem_state returns EINVAL. Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Reviewed-by: NToshi Kani <toshi.kani@hp.com> CC: Seth Jennings <sjenning@linux.vnet.ibm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Charles Keepax 提交于
The index field of cpufreq_frequency_table has been renamed to driver_data by commit 50701588 (cpufreq: rename index as driver_data in cpufreq_frequency_table). This patch updates the s3c64xx driver to match. Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Cc: 3.11+ <stable@vger.kernel.org> # 3.11+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
The mechanism causing devices depending on a given power resource (that is, devices that can be in D0 only if that power resource is on) to be resumed automatically when the power resource is turned on (and their "inferred" power state becomes D0 as a result) is inherently racy and in fact unnecessary. It is racy, because if the power resource is turned on and then immediately off, the device resume triggered by the first transition to "on" may still happen, causing the power resource to be turned on again. That again will trigger the "resume of dependent devices" mechanism, but if the devices in question are not in use, they will be suspended in the meantime causing the power resource to be turned off. However, the "resume of dependent devices" will next resume them again and so on. In some cases (USB port PM in particular) that leads to an endless busy loop of flipping the resource on and off continuously. It is needless, because whoever turns a power resource on will most likely turn it off at some point and the devices that go into "D0" as a result of turning it on will then go back into D3cold (generally, the state they were in before). Moreover, turning on all power resources a device needs to go into D0 is not sufficient for a full transition into D0 in general. Namely, _PS0 may need to be executed in addition to that in some cases. This means that the whole rationale of the "resume of dependent devices" mechanism was incorrect to begin with and it's best to remove it entirely. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
The expression in line 398 of intel_pstate.c causes the following warning to be emitted: drivers/cpufreq/intel_pstate.c:398:3: warning: left shift count >= width of type which happens because unsigned long is 32-bit on some architectures. Fix that by using a helper u64 variable and simplify the code slightly. Tested-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 K. Y. Srinivasan 提交于
Rescind of subchannels were not being correctly handled. Fix the bug. Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com> Cc: <stable@vger.kernel.org> [3.11+] Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Matthew Dawson 提交于
The USB3503 driver had an incorrect depedency on REGMAP, instead of REGMAP_I2C. This caused the build to fail since the necessary regmap i2c pieces were not available. Signed-off-by: NMatthew Dawson <matthew@mjdsystems.ca> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Russell King - ARM Linux 提交于
When CMA fails to initialize in v3.12-rc4, the chipidea driver oopses the kernel while trying to remove and put the HCD which doesn't exist: WARNING: CPU: 0 PID: 6 at /home/rmk/git/linux-rmk/arch/arm/mm/dma-mapping.c:511 __dma_alloc+0x200/0x240() coherent pool not initialised! Modules linked in: CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: G W 3.12.0-rc4+ #56 Workqueue: deferwq deferred_probe_work_func Backtrace: [<c001218c>] (dump_backtrace+0x0/0x10c) from [<c0012328>] (show_stack+0x18/0x1c) r6:c05fd9cc r5:000001ff r4:00000000 r3:df86ad00 [<c0012310>] (show_stack+0x0/0x1c) from [<c05f3a4c>] (dump_stack+0x70/0x8c) [<c05f39dc>] (dump_stack+0x0/0x8c) from [<c00230a8>] (warn_slowpath_common+0x6c/0x8c) r4:df883a60 r3:df86ad00 [<c002303c>] (warn_slowpath_common+0x0/0x8c) from [<c002316c>] (warn_slowpath_fmt+0x38/0x40) r8:ffffffff r7:00001000 r6:c083b808 r5:00000000 r4:df2efe80 [<c0023134>] (warn_slowpath_fmt+0x0/0x40) from [<c00196bc>] (__dma_alloc+0x200/0x240) r3:00000000 r2:c05fda00 [<c00194bc>] (__dma_alloc+0x0/0x240) from [<c001982c>] (arm_dma_alloc+0x88/0xa0) [<c00197a4>] (arm_dma_alloc+0x0/0xa0) from [<c03e2904>] (ehci_setup+0x1f4/0x438) [<c03e2710>] (ehci_setup+0x0/0x438) from [<c03cbd60>] (usb_add_hcd+0x18c/0x664) [<c03cbbd4>] (usb_add_hcd+0x0/0x664) from [<c03e89f4>] (host_start+0xf0/0x180) [<c03e8904>] (host_start+0x0/0x180) from [<c03e7c34>] (ci_hdrc_probe+0x360/0x670 ) r6:df2ef410 r5:00000000 r4:df2c3010 r3:c03e8904 [<c03e78d4>] (ci_hdrc_probe+0x0/0x670) from [<c0311044>] (platform_drv_probe+0x20/0x24) [<c0311024>] (platform_drv_probe+0x0/0x24) from [<c030fcac>] (driver_probe_device+0x9c/0x234) ... ---[ end trace c88ccaf3969e8422 ]--- Unable to handle kernel NULL pointer dereference at virtual address 00000028 pgd = c0004000 [00000028] *pgd=00000000 Internal error: Oops: 17 [#1] SMP ARM Modules linked in: CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: G W 3.12.0-rc4+ #56 Workqueue: deferwq deferred_probe_work_func task: df86ad00 ti: df882000 task.ti: df882000 PC is at usb_remove_hcd+0x10/0x150 LR is at host_stop+0x1c/0x3c pc : [<c03cacec>] lr : [<c03e88e4>] psr: 60000013 sp : df883b50 ip : df883b78 fp : df883b74 r10: c11f4c54 r9 : c0836450 r8 : df30c400 r7 : fffffff4 r6 : df2ef410 r5 : 00000000 r4 : df2c3010 r3 : 00000000 r2 : 00000000 r1 : df86b0a0 r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c53c7d Table: 2f29404a DAC: 00000015 Process kworker/u2:0 (pid: 6, stack limit = 0xdf882240) Stack: (0xdf883b50 to 0xdf884000) ... Backtrace: [<c03cacdc>] (usb_remove_hcd+0x0/0x150) from [<c03e88e4>] (host_stop+0x1c/0x3c) r6:df2ef410 r5:00000000 r4:df2c3010 [<c03e88c8>] (host_stop+0x0/0x3c) from [<c03e8aa0>] (ci_hdrc_host_destroy+0x1c/0x20) r5:00000000 r4:df2c3010 [<c03e8a84>] (ci_hdrc_host_destroy+0x0/0x20) from [<c03e7c80>] (ci_hdrc_probe+0x3ac/0x670) [<c03e78d4>] (ci_hdrc_probe+0x0/0x670) from [<c0311044>] (platform_drv_probe+0x20/0x24) [<c0311024>] (platform_drv_probe+0x0/0x24) from [<c030fcac>] (driver_probe_device+0x9c/0x234) [<c030fc10>] (driver_probe_device+0x0/0x234) from [<c030ff28>] (__device_attach+0x44/0x48) ... ---[ end trace c88ccaf3969e8423 ]--- Fix this so at least we can continue booting and get to a shell prompt. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NRussell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Oliver Neukum 提交于
Some USB drive enclosures do not correctly report an overflow condition if they hold a drive with a capacity over 2TB and are confronted with a READ_CAPACITY_10. They answer with their capacity modulo 2TB. The generic layer cannot cope with that. It must be told to use READ_CAPACITY_16 from the beginning. Signed-off-by: NOliver Neukum <oneukum@suse.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Enrico Mioso 提交于
Interface 6 of this device speaks QMI as per tests done by us. Credits go to Antonella for providing the hardware. Signed-off-by: NEnrico Mioso <mrkiko.rs@gmail.com> Signed-off-by: NAntonella Pellizzari <anto.pellizzari83@gmail.com> Tested-by: NDan Williams <dcbw@redhat.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Roel Kluin 提交于
Due to missing braces on an if statement, in presence of a device_node a port was always assigned -1, regardless of any alias entries in the device tree. Conversely, if device_node was NULL, an unitialized port ended up being used. This patch adds the missing braces, fixing the issues. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Acked-by: NTony Prisk <linux@prisktech.co.nz> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Oliver Neukum 提交于
The device descriptors are messed up after remote wakeup Signed-off-by: NOliver Neukum <oneukum@suse.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 16 10月, 2013 7 次提交
-
-
由 Mikulas Patocka 提交于
This patch fixes a particular type of data corruption that has been encountered when loading a snapshot's metadata from disk. When we allocate a new chunk in persistent_prepare, we increment ps->next_free and we make sure that it doesn't point to a metadata area by further incrementing it if necessary. When we load metadata from disk on device activation, ps->next_free is positioned after the last used data chunk. However, if this last used data chunk is followed by a metadata area, ps->next_free is positioned erroneously to the metadata area. A newly-allocated chunk is placed at the same location as the metadata area, resulting in data or metadata corruption. This patch changes the code so that ps->next_free skips the metadata area when metadata are loaded in function read_exceptions. The patch also moves a piece of code from persistent_prepare_exception to a separate function skip_metadata to avoid code duplication. CVE-2013-4299 Signed-off-by: NMikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Cc: Mike Snitzer <snitzer@redhat.com> Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
-
由 Dirk Brandewie 提交于
If the system is suspended while max_perf_pct is less than 100 percent or no_turbo set policy->{min,max} will be set incorrectly with scaled values which turn the scaled values into hard limits. References: https://bugzilla.kernel.org/show_bug.cgi?id=61241Reported-by: NPatrick Bartels <petzicus@googlemail.com> Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com> Cc: 3.9+ <stable@vger.kernel.org> # 3.9+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Krzysztof Mazur 提交于
Commit 1696d9dc (ACPI: Remove the old /proc/acpi/event interface) left /proc/acpi/event in the ACPI_BUTTON help in Kconfig, so remove it from there. [rjw: Changelog] Signed-off-by: NKrzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lan Tianyu 提交于
In acpi_resume_power_resources() resource_lock should be released when acpi_power_get_state() fails and before passing to next power resource on the list. Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Thomas Hellstrom 提交于
DRI clients that tried to grab the TTM lock when the master (X server) was switched away during a VT switch were sent the SIGTERM signal by the kernel. Fix this so that they are only sent that signal when the master has exited. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NJakob Bornecrantz <jakob@vmware.com> Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Thomas Hellstrom 提交于
The evict code may try to swap them out causing a BUG in the destroy function. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NJakob Bornecrantz <jakob@vmware.com> Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Lars-Peter Clausen 提交于
Usually the active scan mask is freed in __iio_update_buffers() when the buffer is disabled. But when the device is still sampling when it is removed we'll end up disabling the buffers in iio_disable_all_buffers(). So we also need to free the active scan mask here, otherwise it will be leaked. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NJonathan Cameron <jic23@kernel.org>
-
- 15 10月, 2013 6 次提交
-
-
由 Lukasz Dorau 提交于
If EM Transmit bit is busy during init ata_msleep() is called. It is wrong - msleep() should be used instead of ata_msleep(), because if EM Transmit bit is busy for one port, it will be busy for all other ports too, so using ata_msleep() causes wasting tries for another ports. The most common scenario looks like that now (six ports try to transmit a LED meaasege): - port #0 tries for the 1st time and succeeds - ports #1-5 try for the 1st time and sleeps - port #1 tries for the 2nd time and succeeds - ports #2-5 try for the 2nd time and sleeps - port #2 tries for the 3rd time and succeeds - ports #3-5 try for the 3rd time and sleeps - port #3 tries for the 4th time and succeeds - ports #4-5 try for the 4th time and sleeps - port #4 tries for the 5th time and succeeds - port #5 tries for the 5th time and sleeps At this moment port #5 wasted all its five tries and failed to initialize. Because there are only 5 (EM_MAX_RETRY) tries available usually only five ports succeed to initialize. The sixth port and next ones usually will fail. If msleep() is used instead of ata_msleep() the first port succeeds to initialize in the first try and next ones usually succeed to initialize in the second try. tj: updated comment Signed-off-by: NLukasz Dorau <lukasz.dorau@intel.com> Signed-off-by: NTejun Heo <tj@kernel.org>
-
由 Marek Szyprowski 提交于
This reverts commit 9d8eab7a. There is still no consensus on the bindings for the reserved memory and various drawbacks of the proposed solution has been shown, so the best now is to revert it completely and start again from scratch later. Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NGrant Likely <grant.likely@linaro.org>
-
由 Jesse Barnes 提交于
Needed to prevent display corruption in high res panels. v2: use correct unit names (Rodrigo) Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Tested-by: NUlrich Drepper <drepper@gmail.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Greg Kroah-Hartman 提交于
This reverts commit 9b0a1de3. Aaro writes: With v3.12-rc4 I can no longer connect to N800 (OMAP2) with USB (peripheral, g_ether). According to git bisect this is caused by: 9b0a1de3 is the first bad commit So revert this patch, as Felipe says: It's unfortunate that tusb6010 is so messed up Reported-by: NAaro Koskinen <aaro.koskinen@iki.fi> Acked-by: NFelipe Balbi <balbi@ti.com> Cc: Bin Liu <b-liu@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Oliver Neukum 提交于
The device is not responsive when resumed, unless it is reset. Signed-off-by: NOliver Neukum <oneukum@suse.de> CC: stable@vger.kernel.org Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Joe Perches 提交于
These aren't necessary after switch blocks. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NRoland Dreier <roland@purestorage.com>
-