- 20 Sep, 2010 34 commits
-
-
Kailang Yang authored
commit 531d8791 upstream. ALC269vb has an alternative HP pin 0x21 in addition. Fix the parser to recognize it. Signed-off-by:
Kailang Yang <kailang@realtek.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Cc: David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Toby Gray authored
commit 577045c0 upstream. Certain USB devices, such as the Nokia X6 mobile phone, don't expose any endpoint descriptors on some of their interfaces. If the ACM driver is forced to probe all interfaces on a device the a NULL pointer dereference will occur when the ACM driver attempts to use the endpoint of the alternative settings. One way to get the ACM driver to probe all the interfaces is by using the /sys/bus/usb/drivers/cdc_acm/new_id interface. This patch checks that the endpoint pointer for the current alternate settings is non-NULL before using it. Signed-off-by:
Toby Gray <toby.gray@realvnc.com> Cc: Oliver Neukum <oliver@neukum.name> Signed-off-by:
-
Philippe Corbes authored
commit 5b239f0a upstream. cdc-acm.c : Manage pseudo-modem without AT commands capabilities Enable to drive electronic simple gadgets based on microcontrolers. The Interface descriptor is like this: bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 0 None Signed-off-by:
Philippe Corbes <philippe.corbes@gmail.com> Signed-off-by:
-
Toby Gray authored
commit 4035e456 upstream. S60 phones from Nokia and Samsung expose two ACM channels. The first is a modem with a standard AT-command interface, which is picked up correctly by CDC-ACM. The second ACM port is marked as having a vendor-specific protocol. This means that the ACM driver will not claim the second channel by default. This adds support for the second ACM channel for the following devices: Nokia E63 Nokia E75 Nokia 6760 Slide Nokia E52 Nokia E55 Nokia E72 Nokia X6 Nokia N97 Mini Nokia 5800 Xpressmusic Nokia E90 Samsung GTi8510 (INNOV8) Signed-off-by:
-
Przemo Firszt authored
commit 83a4eae9 upstream. Nokia S60 phones expose two ACM channels. The first is a modem, the second is 'vendor-specific' but is treated as a serial device at the S60 end, so we want to expose it on Linux too. Signed-off-by:
Przemo Firszt <przemo@firszt.eu> Signed-off-by:
-
Russ Nelson authored
commit c3baa19b upstream. The Maretron USB100 needs this quirk in order to work properly. Signed-off-by:
Russ Nelson <nelson@crynwr.com> Signed-off-by:
-
Adrian Taylor authored
commit c1479a92 upstream. Nokia S60 phones expose two ACM channels. The first is a modem and is picked up by the standard AT-command interface information in the CDC-ACM driver. The second is marked as having a vendor-specific protocol. Normally, we don't expose those as ttys. (On some other devices, they may be claimed by the rndis_host driver and used as a network interface). But on S60 this second ACM channel is the way that third-party S60 application developers are expected to communicate over USB. It acts as a serial device at the S60 end, and so it should on Linux too. The list of devices is largely derived from: http://wiki.forum.nokia.com/index.php/S60_Platform_and_device_identification_codes http://wiki.forum.nokia.com/index.php/Nokia_USB_Product_IDs and includes only the S60 3rd Edition+ devices documented there. There are many devices for which the USB device ID is not documented, including: Nokia 6290 Nokia E63 Nokia 5630 XpressMusic Nokia 5730 XpressMusic Nokia 6710 Navigator Nokia 6720 classic Nokia 6730 Classic Nokia 6760 slide Nokia 6790 slide Nokia 6790 Surge Nokia E52 Nokia E55 Nokia E71x (AT&T) Nokia E72 Nokia E75 Nokia E75 US+LTA variant Nokia N79 Nokia N86 8MP Nokia 5230 (RM-588) Nokia 5230 (RM-594) Nokia 5530 XpressMusic Nokia 5530 XpressMusic (china) Nokia 5800 XM Nokia N97 (RM-506) Nokia N97 mini Nokia X6 It would be good to add those subsequently. Signed-off-by:
Adrian Taylor <aat@realvnc.com> Acked-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Dave Ludlow authored
commit 870408c8 upstream. Add the USB IDs needed to support the B&B USOPTL4-4P, USO9ML2-2P, and USO9ML2-4P. This patch expands and corrects a typo in the patch sent on 08-31-2010. Signed-off-by:
Dave Ludlow <dave.ludlow@bay.ws> Signed-off-by:
-
Johan Hovold authored
commit 9e221a35 upstream. Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Dave Ludlow authored
commit caf3a636 upstream. Add the USB ID needed to support B&B Electronic's 2-port, optically-isolated, powered, USB to RS485 converter. Signed-off-by:
-
Blaise Gassend authored
commit 27f1281d upstream. Signed-off-by:
Blaise Gassend <blaise.gasend_linux@m4x.org> Signed-off-by:
-
Luke Lowrey authored
commit 65737388 upstream. Added the 0xDAF8 to 0xDAFF PID range for ChamSys limited USB interface/wing products Signed-off-by:
Luke Lowrey <luke@chamsys.co.uk> Signed-off-by:
-
Jason Detring authored
commit 0bf7a81c upstream. This is the cable between an H3000 navigation unit and a multi-function display. http://www.bandg.com/en/Products/H3000/Spares-and-Accessories/Cables/H3000-CPU-USB-Cable-Pack/Signed-off-by:
Jason Detring <jason.detring@navico.com> Signed-off-by:
-
Craig Shelley authored
commit 541e05ec upstream. New device ID added for Balluff RFID reader. Signed-off-by:
Craig Shelley <craig@microtron.org.uk> Signed-off-by:
-
Maxim Osipov authored
commit 037d3656 upstream. Please find attached patch for https://bugzilla.kernel.org/show_bug.cgi?id=16023 problem. Signed-off-by:
Maxim Osipov <maxim.osipov@gmail.com> Signed-off-by:
-
Dan Carpenter authored
commit 08a3b3b1 upstream. The iounmap(ehci->ohci_hcctrl_reg); should be the first thing we do because the ioremap() was the last thing we did. Also if we hit any of the goto statements in the original code then it would have led to a NULL dereference of "ehci". This bug was introduced in: 796bcae7 "USB: powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3]" I modified the few lines in front a little so that my code didn't obscure the return success code path. Signed-off-by:
Dan Carpenter <error27@gmail.com> Reviewed-by:
Grant Likely <grant.likely@secretlab.ca> Signed-off-by:
-
Sunil Mushran authored
commit f5ce5a08 upstream. For local mounts, ocfs2_read_locked_inode() calls ocfs2_read_blocks_sync() to read the inode off the disk. The latter first checks to see if that block is cached in the journal, and, if so, returns that block. That is ok. But ocfs2_read_locked_inode() goes wrong when it tries to validate the checksum of such blocks. Blocks that are cached in the journal may not have had their checksum computed as yet. We should not validate the checksums of such blocks. Fixes ossbz#1282 http://oss.oracle.com/bugzilla/show_bug.cgi?id=1282Signed-off-by:
Sunil Mushran <sunil.mushran@oracle.com> Singed-off-by:
Tao Ma <tao.ma@oracle.com> Signed-off-by:
-
Luis R. Rodriguez authored
commit 90487974 upstream. The 5 GHz CTL indexes were not being read for all hardware devices due to the masking out through the CTL_MODE_M mask being one bit too short. Without this the calibrated regulatory maximum values were not being picked up when devices operate on 5 GHz in HT40 mode. The final output power used for Atheros devices is the minimum between the calibrated CTL values and what CRDA provides. Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Miklos Szeredi authored
commit 595afaf9 upstream. David Bartly reported that fuse can hang in fuse_get_req_nofail() when the connection to the filesystem server is no longer active. If bg_queue is not empty then flush_bg_queue() called from request_end() can put more requests on to the pending queue. If this happens while ending requests on the processing queue then those background requests will be queued to the pending list and never ended. Another problem is that fuse_dev_release() didn't wake up processes sleeping on blocked_waitq. Solve this by: a) flushing the background queue before calling end_requests() on the pending and processing queues b) setting blocked = 0 and waking up processes waiting on blocked_waitq() Thanks to David for an excellent bug report. Reported-by:
David Bartley <andareed@gmail.com> Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Signed-off-by:
-
Hank Janssen authored
commit 77c5ceaf upstream. Fixed lockup problem with bounce_buffer scatter list which caused crashes in heavy loads. And minor code indentation cleanup in effected area. Removed whitespace and noted minor indentation changes in description as pointed out by Joe Perches. (Thanks for reviewing Joe) Signed-off-by:
Hank Janssen <hjanssen@microsoft.com> Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
-
Hank Janssen authored
commit 15dd1c9f upstream. Increased storvsc ringbuffer and max_io_requests. This now more closely mimics the numbers on Hyper-V. And will allow more IO requests to take place for the SCSI driver. Max_IO is set to double from what it was before, Hyper-V allows it and we have had appliance builder requests to see if it was a problem to increase the number. Ringbuffer size for storvsc is now increased because I have seen A few buffer problems on extremely busy systems. They were Set pretty low before. And since max_io_requests is increased I Really needed to increase the buffer as well. Signed-off-by:
-
Haiyang Zhang authored
commit e5fa721d upstream. Fixed the value of the 64bit-hole inside ring buffer, this caused a problem on Hyper-V when running checked Windows builds. Checked builds of Windows are used internally and given to external system integrators at times. They are builds that for example that all elements in a structure follow the definition of that Structure. The bug this fixed was for a field that we did not fill in at all (Because we do Not use it on the Linux side), and the checked build of windows gives errors on it internally to the Windows logs. This fixes that error. Signed-off-by:
-
Hank Janssen authored
commit 0c47a70a upstream. Fixed bounce offset kmap problem by using correct index. The symptom of the problem is that in some NAS appliances this problem represents Itself by a unresponsive VM under a load with many clients writing small files. Signed-off-by:
-
Haiyang Zhang authored
commit b681b588 upstream. Fix missing functions for net_device_ops. It's a bug when porting the drivers from 2.6.27 to 2.6.32. In 2.6.27, the default functions for Ethernet, like eth_change_mtu(), were assigned by ether_setup(). But in 2.6.32, these function pointers moved to net_device_ops structure and no longer be assigned in ether_setup(). So we need to set these functions in our driver code. It will ensure the MTU won't be set beyond 1500. Otherwise, this can cause an error on the server side, because the HyperV linux driver doesn't support jumbo frame yet. Signed-off-by:
-
Mike Galbraith authored
This commit does not appear to have been meant for 32-stable, and causes ltp's cpusets testcases to fail, revert it. Original commit text: sched: Fix a race between ttwu() and migrate_task() Based on commit e2912009 upstream, but done differently as this issue is not present in .33 or .34 kernels due to rework in this area. If a task is in the TASK_WAITING state, then try_to_wake_up() is working on it, and it will place it on the correct cpu. This commit ensures that neither migrate_task() nor __migrate_task() calls set_task_cpu(p) while p is in the TASK_WAKING state. Otherwise, there could be two concurrent calls to set_task_cpu(p), resulting in the task's cfs_rq being inconsistent with its cpu. Signed-off-by:
Mike Galbraith <efault@gmx.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by:
-
Amit Arora authored
[Fixed in a different manner upstream, due to rewrites in this area] Problem : In a stress test where some heavy tests were running along with regular CPU offlining and onlining, a hang was observed. The system seems to be hung at a point where migration_call() tries to kill the migration_thread of the dying CPU, which just got moved to the current CPU. This migration thread does not get a chance to run (and die) since rt_throttled is set to 1 on current, and it doesn't get cleared as the hrtimer which is supposed to reset the rt bandwidth (sched_rt_period_timer) is tied to the CPU which we just marked dead! Solution : This patch pushes the killing of migration thread to "CPU_POST_DEAD" event. By then all the timers (including sched_rt_period_timer) should have got migrated (along with other callbacks). Signed-off-by:
Amit Arora <amitarora@in.ibm.com> Signed-off-by:
Gautham R Shenoy <ego@in.ibm.com> Signed-off-by:
-
Ben Hutchings authored
commit 30da5524 upstream. commit 2ca1af9aa3285c6a5f103ed31ad09f7399fc65d7 "PCI: MSI: Remove unsafe and unnecessary hardware access" changed read_msi_msg_desc() to return the last MSI message written instead of reading it from the device, since it may be called while the device is in a reduced power state. However, the pSeries platform code really does need to read messages from the device, since they are initially written by firmware. Therefore: - Restore the previous behaviour of read_msi_msg_desc() - Add new functions get_cached_msi_msg{,_desc}() which return the last MSI message written - Use the new functions where appropriate Acked-by:
Michael Ellerman <michael@ellerman.id.au> Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Ben Hutchings authored
commit fcd097f3 upstream. During suspend on an SMP system, {read,write}_msi_msg_desc() may be called to mask and unmask interrupts on a device that is already in a reduced power state. At this point memory-mapped registers including MSI-X tables are not accessible, and config space may not be fully functional either. While a device is in a reduced power state its interrupts are effectively masked and its MSI(-X) state will be restored when it is brought back to D0. Therefore these functions can simply read and write msi_desc::msg for devices not in D0. Further, read_msi_msg_desc() should only ever be used to update a previously written message, so it can always read msi_desc::msg and never needs to touch the hardware. Tested-by:
"Michael Chan" <mchan@broadcom.com> Signed-off-by:
-
Suresh Siddha authored
commit cd7240c0 upstream. TSC's get reset after suspend/resume (even on cpu's with invariant TSC which runs at a constant rate across ACPI P-, C- and T-states). And in some systems BIOS seem to reinit TSC to arbitrary large value (still sync'd across cpu's) during resume. This leads to a scenario of scheduler rq->clock (sched_clock_cpu()) less than rq->age_stamp (introduced in 2.6.32). This leads to a big value returned by scale_rt_power() and the resulting big group power set by the update_group_power() is causing improper load balancing between busy and idle cpu's after suspend/resume. This resulted in multi-threaded workloads (like kernel-compilation) go slower after suspend/resume cycle on core i5 laptops. Fix this by recomputing cyc2ns_offset's during resume, so that sched_clock() continues from the point where it was left off during suspend. Reported-by:
Florian Pritz <flo@xssn.at> Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> LKML-Reference: <1282262618.2675.24.camel@sbsiddha-MOBL3.sc.intel.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Mark Lord authored
commit 44b73380 upstream. Fix DSM/TRIM commands in sata_mv (v2). These need to be issued using old-school "BM DMA", rather than via the EDMA host queue. Since the chips don't have proper BM DMA status, we need to be more careful with setting the ATA_DMA_INTR bit, since DSM/TRIM often has a long delay between "DMA complete" and "command complete". GEN_I chips don't have BM DMA, so no TRIM for them. Signed-off-by:
Mark Lord <mlord@pobox.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
David Henningsson authored
commit 150b432f upstream. The non-standard name "iMic" makes PulseAudio ignore the microphone. BugLink: https://launchpad.net/bugs/605101Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Jeremy Fitzhardinge authored
commit aaca4964 upstream. IPIs and VIRQs are inherently per-cpu event types, so treat them as such: - use a specific percpu irq_chip implementation, and - handle them with handle_percpu_irq This makes the path for delivering these interrupts more efficient (no masking/unmasking, no locks), and it avoid problems with attempts to migrate them. Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by:
-
Jeremy Fitzhardinge authored
commit dffe2e1e upstream. Xen events are logically edge triggered, as Xen only calls the event upcall when an event is newly set, but not continuously as it remains set. As a result, use handle_edge_irq rather than handle_level_irq. This has the important side-effect of fixing a long-standing bug of events getting lost if: - an event's interrupt handler is running - the event is migrated to a different vcpu - the event is re-triggered The most noticable symptom of these lost events is occasional lockups of blkfront. Many thanks to Tom Kopec and Daniel Stodden in tracking this down. Signed-off-by:
-
Andreas Herrmann authored
commit a05e93f3 upstream. Commit 8bf0223ed515be24de0c671eedaff49e78bebc9c (hwmon, k8temp: Fix temperature reporting for ASB1 processor revisions) fixed temperature reporting for ASB1 CPUs. But those CPU models (model 0x6b, 0x6f, 0x7f) were packaged both as AM2 (desktop) and ASB1 (mobile). Thus the commit leads to wrong temperature reporting for AM2 CPU parts. The solution is to determine the package type for models 0x6b, 0x6f, 0x7f. This is done using BrandId from CPUID Fn8000_0001_EBX[15:0]. See "Constructing the processor Name String" in "Revision Guide for AMD NPT Family 0Fh Processors" (Rev. 3.46). Cc: Rudolf Marek <r.marek@assembler.cz> Reported-by:
Vladislav Guberinic <neosisani@gmail.com> Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
- 26 Aug, 2010 6 commits
-
-
Greg Kroah-Hartman authored
-
Kerstin Jonsson authored
commit 8c3ba8d0 upstream. When the SMP kernel decides to crash_kexec() the local APICs may have pending interrupts in their vector tables. The setup routine for the local APIC has a deficient mechanism for clearing these interrupts, it only handles interrupts that has already been dispatched to the local core for servicing (the ISR register) safely, it doesn't consider lower prioritized queued interrupts stored in the IRR register. If you have more than one pending interrupt within the same 32 bit word in the LAPIC vector table registers you may find yourself entering the IO APIC setup with pending interrupts left in the LAPIC. This is a situation for wich the IO APIC setup is not prepared. Depending of what/which interrupt vector/vectors are stuck in the APIC tables your system may show various degrees of malfunctioning. That was the reason why the check_timer() failed in our system, the timer interrupts was blocked by pending interrupts from the old kernel when routed trough the IO APIC. Additional comment from Jiri Bohac: ============== If this should go into stable release, I'd add some kind of limit on the number of iterations, just to be safe from hard to debug lock-ups: +if (loops++ > MAX_LOOPS) { + printk("LAPIC pending clean-up") + break; +} while (queued); with MAX_LOOPS something like 1E9 this would leave plenty of time for the pending IRQs to be cleared and would and still cause at most a second of delay if the loop were to lock-up for whatever reason. [trenn@suse.de: V2: Use tsc if avail to bail out after 1 sec due to possible virtual apic_read calls which may take rather long (suggested by: Avi Kivity <avi@redhat.com>) If no tsc is available bail out quickly after cpu_khz, if we broke out too early and still have irqs pending (which should never happen?) we still get a WARN_ON... V3: - Fixed indentation -> checkpatch clean - max_loops must be signed V4: - Fix typo, mixed up tsc and ntsc in first rdtscll() call V5: Adjust WARN_ON() condition to also catch error in cpu_has_tsc case] Cc: <jbohac@novell.com> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Kerstin Jonsson <kerstin.jonsson@ericsson.com> Cc: Avi Kivity <avi@redhat.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Tested-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
Thomas Renninger <trenn@suse.de> LKML-Reference: <201005241913.o4OJDGWM010865@imap1.linux-foundation.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Cc: Thomas Renninger <trenn@suse.de> Signed-off-by:
-
Galen Seitz authored
commit ea233f80 upstream. Add ftdi product ID for Lenz LI-USB, a model train interface. This was NOT tested against 2.6.35, but a similar patch was tested with the CentOS 2.6.18-194.11.1.el5 kernel. It wasn't clear to me what ordering is being used in ftdi_sio.c, so I inserted the ID after another model train entry(SPROG_II). Signed-off-by:
Galen Seitz <galens@seitzassoc.com> Signed-off-by:
-
Martin Michlmayr authored
commit 666cc076 upstream. Add the ID for the Ionics PlugComputer (<http://ionicsplug.com/>). Signed-off-by:
Martin Michlmayr <tbm@cyrius.com> Signed-off-by:
-
John Youn authored
commit a1669b2c upstream. The code to increment the TRB pointer has a slight ambiguity that could lead to a bug on different compilers. The ANSI C specification does not specify the precedence of the assignment operator over the postfix operator. gcc 4.4 produced the correct code (increment the pointer and assign the value), but a MIPS compiler that one of John's clients used assigned the old (unincremented) value. Remove the unnecessary assignment to make all compilers produce the correct assembly. Signed-off-by:
John Youn <johnyoun@synopsys.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Greg Kroah-Hartman authored
commit 0827a9ff upstream. If we can't read the firmware for a device from the disk, and yet the device already has a valid firmware image in it, we don't want to replace the firmware with something invalid. So check the version number to be less than the current one to verify this is the correct thing to do. Reported-by:
Chris Beauchamp <chris@chillibean.tv> Tested-by:
-
