summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2010-11-22Linux 2.6.36.1v2.6.36.1Greg Kroah-Hartman
2010-11-22sgi-xp: incoming XPC channel messages can come in after the channel's ↵Robin Holt
partition structures have been torn down commit 09358972bff5ce99de496bbba97c85d417b3c054 upstream. Under some workloads, some channel messages have been observed being delayed on the sending side past the point where the receiving side has been able to tear down its partition structures. This condition is already detected in xpc_handle_activate_IRQ_uv(), but that information is not given to xpc_handle_activate_mq_msg_uv(). As a result, xpc_handle_activate_mq_msg_uv() assumes the structures still exist and references them, causing a NULL-pointer deref. Signed-off-by: Robin Holt <holt@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22ARM: cns3xxx: Fixup the missing second parameter to addruart macro to allow ↵Mac Lin
them to build. It can't be merged into Linus' tree because this file has already been changed in incompatible ways. Fixup the missing second parameter to addruart macro to allow them to build, according to to commit 0e17226f7cd289504724466f4298abc9bdfca3fe. Enabling DEBUG in head.S would cause: rch/arm/boot/compressed/head.S: Assembler messages: arch/arm/boot/compressed/head.S:1037: Error: too many positional arguments arch/arm/boot/compressed/head.S:1055: Error: too many positional arguments Signed-off-by: Mac Lin <mkl0301@gmail.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22kgdb,arm: fix register dumpRabin Vincent
commit 834b2964b7ab047610da038e42d61dc8dac6339a upstream. DBG_MAX_REG_NUM incorrectly had the number of indices in the GDB regs array rather than the number of registers, leading to an oops when the "rd" command is used in KDB. Signed-off-by: Rabin Vincent <rabin@rab.in> Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22secmark: do not return early if there was no errorEric Paris
commit 15714f7b58011cf3948cab2988abea560240c74f upstream. Commit 4a5a5c73 attempted to pass decent error messages back to userspace for netfilter errors. In xt_SECMARK.c however the patch screwed up and returned on 0 (aka no error) early and didn't finish setting up secmark. This results in a kernel BUG if you use SECMARK. Signed-off-by: Eric Paris <eparis@redhat.com> Acked-by: Paul Moore <paul.moore@hp.com> Signed-off-by: James Morris <jmorris@namei.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22Fixed Regression in NFS Direct I/O pathSteve Dickson
commit 568a810d7edd58bd505222dd1c7e48895532290b upstream. A typo, introduced by commit f11ac8db, in the nfs_direct_write() routine causes writes with O_DIRECT set to fail with a ENOMEM error. Found-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22Fix regressions in scsi_internal_device_blockMike Christie
commit 986fe6c7f50974e871b8ab5a800f5310ea25b361 upstream. Deleting a SCSI device on a blocked fc_remote_port (before fast_io_fail_tmo fires) results in a hanging thread: STACK: 0 schedule+1108 [0x5cac48] 1 schedule_timeout+528 [0x5cb7fc] 2 wait_for_common+266 [0x5ca6be] 3 blk_execute_rq+160 [0x354054] 4 scsi_execute+324 [0x3b7ef4] 5 scsi_execute_req+162 [0x3b80ca] 6 sd_sync_cache+138 [0x3cf662] 7 sd_shutdown+138 [0x3cf91a] 8 sd_remove+112 [0x3cfe4c] 9 __device_release_driver+124 [0x3a08b8] 10 device_release_driver+60 [0x3a0a5c] 11 bus_remove_device+266 [0x39fa76] 12 device_del+340 [0x39d818] 13 __scsi_remove_device+204 [0x3bcc48] 14 scsi_remove_device+66 [0x3bcc8e] 15 sysfs_schedule_callback_work+50 [0x260d66] 16 worker_thread+622 [0x162326] 17 kthread+160 [0x1680b0] 18 kernel_thread_starter+6 [0x10aaea] During the delete, the SCSI device is in moved to SDEV_CANCEL. When the FC transport class later calls scsi_target_unblock, this has no effect, since scsi_internal_device_unblock ignores SCSI devics in this state. It looks like all these are regressions caused by: 5c10e63c943b4c67561ddc6bf61e01d4141f881f [SCSI] limit state transitions in scsi_internal_device_unblock Fix by rejecting offline and cancel in the state transition. Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> [jejb: Original patch by Christof Schmitt, modified by Mike Christie] Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22Fix race when removing SCSI devicesChristof Schmitt
commit 546ae796bfac6399e30da4b5af2cf7a6d0f8a4ec upstream. Removing SCSI devices through echo 1 > /sys/bus/scsi/devices/ ... /delete while the FC transport class removes the SCSI target can lead to an oops: Unable to handle kernel pointer dereference at virtual kernel address 00000000b6815000 Oops: 0011 [#1] PREEMPT SMP DEBUG_PAGEALLOC Modules linked in: sunrpc qeth_l3 binfmt_misc dm_multipath scsi_dh dm_mod ipv6 qeth ccwgroup [last unloaded: scsi_wait_scan] CPU: 1 Not tainted 2.6.35.5-45.x.20100924-s390xdefault #1 Process fc_wq_0 (pid: 861, task: 00000000b7331240, ksp: 00000000b735bac0) Krnl PSW : 0704200180000000 00000000003ff6e4 (__scsi_remove_device+0x24/0xd0) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3 Krnl GPRS: 0000000000000001 0000000000000000 00000000b6815000 00000000bc24a8c0 00000000003ff7c8 000000000056dbb8 0000000000000002 0000000000835d80 ffffffff00000000 0000000000001000 00000000b6815000 00000000bc24a7f0 00000000b68151a0 00000000b6815000 00000000b735bc20 00000000b735bbf8 Krnl Code: 00000000003ff6d6: a7840001 brc 8,3ff6d8 00000000003ff6da: a7fbffd8 aghi %r15,-40 00000000003ff6de: e3e0f0980024 stg %r14,152(%r15) >00000000003ff6e4: e31021200004 lg %r1,288(%r2) 00000000003ff6ea: a71f0000 cghi %r1,0 00000000003ff6ee: a7a40011 brc 10,3ff710 00000000003ff6f2: a7390003 lghi %r3,3 00000000003ff6f6: c0e5ffffc8b1 brasl %r14,3f8858 Call Trace: ([<0000000000001000>] 0x1000) [<00000000003ff7d2>] scsi_remove_device+0x42/0x54 [<00000000003ff8ba>] __scsi_remove_target+0xca/0xfc [<00000000003ff99a>] __remove_child+0x3a/0x48 [<00000000003e3246>] device_for_each_child+0x72/0xbc [<00000000003ff93a>] scsi_remove_target+0x4e/0x74 [<0000000000406586>] fc_rport_final_delete+0xb2/0x23c [<000000000015d080>] worker_thread+0x200/0x344 [<000000000016330c>] kthread+0xa0/0xa8 [<0000000000106c1a>] kernel_thread_starter+0x6/0xc [<0000000000106c14>] kernel_thread_starter+0x0/0xc INFO: lockdep is turned off. Last Breaking-Event-Address: [<00000000003ff7cc>] scsi_remove_device+0x3c/0x54 The function __scsi_remove_target iterates through the SCSI devices on the host, but it drops the host_lock before calling scsi_remove_device. When the SCSI device is deleted from another thread, the pointer to the SCSI device in scsi_remove_device can become invalid. Fix this by getting a reference to the SCSI device before dropping the host_lock to keep the SCSI device alive for the call to scsi_remove_device. Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22gdth: integer overflow in ioctlDan Carpenter
commit f63ae56e4e97fb12053590e41a4fa59e7daa74a4 upstream. gdth_ioctl_alloc() takes the size variable as an int. copy_from_user() takes the size variable as an unsigned long. gen.data_len and gen.sense_len are unsigned longs. On x86_64 longs are 64 bit and ints are 32 bit. We could pass in a very large number and the allocation would truncate the size to 32 bits and allocate a small buffer. Then when we do the copy_from_user(), it would result in a memory corruption. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22pmcraid: remove duplicate struct memberAnil Ravindranath
commit df30e5059681ed0671c9cc6ff702fe9ca7f20042 upstream. sense_buffer is both a direct member of struct pmcraid_cmd as well as an indirect one via an anonymous union and struct. Fix this clash by eliminating the direct member in favour of the anonymous struct/union one. The name duplication apparently isn't noticed by gcc versions earlier than 4.4 Reported-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Anil Ravindranath <anil_ravindranath@pmc-sierra.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22qla4xxx: fix build on PPCJiri Slaby
commit a6751ccb9ba85180c84135cc921eea11d83d5689 upstream. We use read/write[bslq] but do not include linux/io.h. This causes build failures on PPC. Include that file. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Vikas Chaudhary <vikas.chaudhary@qlogic.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22libsas: fix NCQ mixing with non-NCQDavid Milburn
commit f0ad30d3d2dc924decc0e10b1ff6dc32525a5d99 upstream. Some cards (like mvsas) have issue troubles if non-NCQ commands are mixed with NCQ ones. Fix this by using the libata default NCQ check routine which waits until all NCQ commands are complete before issuing a non-NCQ one. The impact to cards (like aic94xx) which don't need this logic should be minimal Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22sd name space exhaustion causes system hangMichael Reed
commit 1a03ae0f556a931aa3747b70e44b78308f5b0590 upstream. Following a site power outage which re-enabled all the ports on my FC switches, my system subsequently booted with far too many luns! I had let it run hoping it would make multi-user. It didn't. :( It hung solid after exhausting the last sd device, sdzzz, and attempting to create sdaaaa and beyond. I was unable to get a dump. Discovered using a 2.6.32.13 based system. correct this by detecting when the last index is utilized and failing the sd probe of the device. Patch applies to scsi-misc-2.6. Signed-off-by: Michael Reed <mdr@sgi.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22asus-laptop: fix gps rfkillCorentin Chary
commit 23f45c3a76e715217f40ac397c15815c774cad7f upstream. The GPS rfkill crappy code. The ops_data argument wasn't set, and was totally misused. The fix have been tested on an Asus R2H. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22USB: accept some invalid ep0-maxpacket valuesAlan Stern
commit 56626a72a47bf3e50875d960d6b5f17b9bee0ab2 upstream. A few devices (such as the RCA VR5220 voice recorder) are so non-compliant with the USB spec that they have invalid maxpacket sizes for endpoint 0. Nevertheless, as long as we can safely use them, we may as well do so. This patch (as1432) softens our acceptance criterion by allowing high-speed devices to have ep0-maxpacket sizes other than 64. A warning is printed in the system log when this happens, and the existing error message is clarified. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: James <bjlockie@lockie.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22usb: r8a66597-hcd: Change mistake of the outsw functionNobuhiro Iwamatsu
commit ac9dfe9cdda4eb42ecaa9f13b0fee518e0b6518e upstream. Some functions changed by 1c98347e613bf17ea2f18c9766ce0ab77f65a96d. However, There was a change mistake of the function (outsw). Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> CC: Paul Mundt <lethal@linux-sh.org> Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22USB: opticon: Fix long-standing bugs in opticon driverAlon Ziv
commit 97cd8dc4ca9a1a5efb2cc38758e01492e3b013e2 upstream. The bulk-read callback had two bugs: a) The bulk-in packet's leading two zeros were returned (and the two last bytes truncated) b) The wrong URB was transmitted for the second (and later) read requests, causing further reads to return the entire packet (including leading zeros) Signed-off-by: Alon Ziv <alon-git@nolaviz.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22USB: visor: fix initialisation of UX50/TH55 devicesJohan Hovold
commit cfb8da8f69b81d367b766888e83ec0483a31bf01 upstream. Fix regression introduced by commit 214916f2ec6701e1c9972f26c60b3dc37d3153c6 (USB: visor: reimplement using generic framework) which broke initialisation of UX50/TH55 devices that used re-mapped bulk-out endpoint addresses. Reported-by: Robert Gadsdon <rgadsdon@bayarea.net> Tested-by: Robert Gadsdon <rgadsdon@bayarea.net> Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22USB: disable endpoints after unbinding interfaces, not beforeAlan Stern
commit 80f0cf3947889014d3a3dc0ad60fb87cfda4b12a upstream. This patch (as1430) fixes a bug in usbcore. When a device configuration change occurs or a device is removed, the endpoints for the old config should be completely disabled. However it turns out they aren't; this is because usb_unbind_interface() calls usb_enable_interface() or usb_set_interface() to put interfaces back in altsetting 0, which re-enables the interfaces' endpoints. As a result, when a device goes through a config change or is unconfigured, the ep_in[] and ep_out[] arrays may be left holding old pointers to usb_host_endpoint structures. If the device is deauthorized these structures get freed, and the stale pointers cause errors when the the device is eventually unplugged. The solution is to disable the endpoints after unbinding the interfaces instead of before. This isn't as large a change as it sounds, since usb_unbind_interface() disables all the interface's endpoints anyway before calling the driver's disconnect routine, unless the driver claims to support "soft" unbind. This fixes Bugzilla #19192. Thanks to "Tom" Lei Ming for diagnosing the underlying cause of the problem. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Carsten Sommer <carsten_sommer@ymail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22USB: atmel_usba_udc: force vbus_pin at -EINVAL when gpio_request failledJean-Christophe PLAGNIOL-VILLARD
commit 969affff54702785330de553b790372e261e93f9 upstream. to ensure gpio_is_valid return false Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22USB: cp210x: Add WAGO 750-923 Service Cable device IDAnders Larsen
commit 93ad03d60b5b18897030038234aa2ebae8234748 upstream. The WAGO 750-923 USB Service Cable is used for configuration and firmware updates of several industrial automation products from WAGO Kontakttechnik GmbH. Bus 004 Device 002: ID 1be3:07a6 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1be3 idProduct 0x07a6 bcdDevice 1.00 iManufacturer 1 Silicon Labs iProduct 2 WAGO USB Service Cable iSerial 3 1277796751 . . . Signed-off-by: Anders Larsen <al@alarsen.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22USB: cp210x: Add Renesas RX-Stick device IDDJ Delorie
commit 2f1136d1d08a63dcdbcd462621373f30d8dfe590 upstream. RX610 development board by Renesas Bus 001 Device 024: ID 045b:0053 Hitachi, Ltd Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x045b Hitachi, Ltd idProduct 0x0053 bcdDevice 1.00 iManufacturer 1 Silicon Labs iProduct 2 RX-Stick iSerial 3 0001 . . . http://am.renesas.com/rx610stick Signed-off-by: DJ Delorie <dj@delorie.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22USB: option: Add more ZTE modem USB id'sMauro Carvalho Chehab
commit ecfa153ef616b901e86d9a051b329fcda7a6ce7b upstream. There are lots of ZTE USB id's currently not covered by usb/serial. Adds them, to allow those devices to work properly on Linux. While here, put the USB ID's for 0x2002/0x2003 at the sorted order. This patch is based on zte.c file found on MF645. PS.: The ZTE driver is commenting the USB ID for 0x0053. It also adds, commented, an USB ID for 0x0026. Not sure why, but I think that 0053 is used by their devices in storage mode only. So, I opted to keep the comment on this patch. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22USB: Change acm_iad_descriptor bFunctionProtocol to USB_CDC_ACM_PROTO_AT_V25TERPraveena Nadahally
commit 5c8db070b4480c43394680d9dfd2ddb06b97d2ae upstream. The protocol code is set 00 in IAD and it's set to 01 in ACM control interface descriptor in f_acm.c file. Due to this, windows is unable to install the modem(ACM) driver based on class-subclass-protocol matching. This patch corrects the protocol code in ACM IAD to the same as in acm_control_interface_desc protocol code. Acked-by: Linus Walleij <linus.walleij@stericsson.com> Signed-off-by: Praveena Nadahally <praveen.nadahally@stericsson.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22usb: musb: blackfin: call gpio_free() on error path in musb_platform_init()Sergei Shtylyov
commit 00be545e49d83485d49a598d3b7e090088934be8 upstream. Blackfin's musb_platform_init() needs to call gpio_free() for error cleanup iff otg_get_transceiver() call returns NULL. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Acked-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22usb: musb: blackfin: call usb_nop_xceiv_unregister() in musb_platform_exit()Sergei Shtylyov
commit 3daad24d6c72affdd40e8b6a75c87d3c175880b6 upstream. Blackfin's musb_platform_exit() forgets to call usb_nop_xceiv_unregister(). While fixing this, also remove the unneeded blank line there. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Acked-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22USB: MUSB: fix kernel WARNING/oops when unloading module in OTG modeSergei Shtylyov
commit f405387435a85a440d1ce16f3ca36e042281643a upstream. Since commit 461972d8a4c94bc44f11a13046041c78a7cf18dd (musb_core: don't call musb_platform_exit() twice), unloading the driver module results in a WARNING "kobject: '(null)' (c73de788): is not initialized, yet kobject_put() is being called." (or even kernel oops) on e.g. DaVincis, though only in the OTG mode. There exists dubious and unbalanced put_device() call in musb_free() which takes place only in the OTG mode. As this commit caused musb_platform_exit() to be called (and so unregister the NOP transceiver) before this put_device() call, this function references already freed memory. On the other hand, all the glue layers miss the otg_put_transceiver() call, complementary to the otg_get_transceiver() call that they do. So, I think the solution is to get rid of the strange put_device() call, and instead call otg_put_transceiver() in the glue layers... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22USB: ftdi_sio: add device ids for ScienceScopeGreg Kroah-Hartman
commit 0f266abd70cd83571eca019f764b5f1992da7361 upstream. This adds the requested device ids to the ftdi_sio driver. Reported-by: Ewan Bingham <ewan@auc.co.uk> Cc: Kuba Ober <kuba@mareimbrium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22USB: ftdi_sio: new VID/PIDs for various Papouch devicesDaniel Suchy
commit 59c6ccd9f9aecfa59c99ceba6d4d34b180547a05 upstream. This patch for FTDI USB serial driver ads new VID/PIDs used on various devices manufactured by Papouch (http://www.papouch.com). These devices have their own VID/PID, although they're using standard FTDI chip. In ftdi_sio.c, I also made small cleanup to have declarations for all Papouch devices together. Signed-off-by: Daniel Suchy <danny@danysek.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22USB: add PID for FTDI based OpenDCC hardwareRainer Keller
commit 99c1e4f89d1033444ce4d0c064bd2826e81c3775 upstream. The OpenDCC project is developing a new hardware. This patch adds its PID to the list of known FTDI devices. The PID can be found at http://www.opendcc.de/elektronik/usb/opendcc_usb.html Signed-off-by: Rainer Keller <mail@rainerkeller.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22USB: ftdi_sio: revert "USB: ftdi_sio: fix DTR/RTS line modes"Johan Hovold
commit 677aeafe19e88c282af74564048243ccabb1c590 upstream. This reverts commit 6a1a82df91fa0eb1cc76069a9efe5714d087eccd. RTS and DTR should not be modified based on CRTSCTS when calling set_termios. Modem control lines are raised at port open by the tty layer and should stay raised regardless of whether hardware flow control is enabled or not. This is in conformance with the way serial ports work today and many applications depend on this behaviour to be able to talk to hardware implementing hardware flow control (without the applications actually using it). Hardware which expects different behaviour on these lines can always use TIOCMSET/TIOCMBI[SC] after port open to change them. Reported-by: Daniel Mack <daniel@caiaq.de> Reported-by: Dave Mielke <dave@mielke.cc> Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22USB: ftdi_sio: Add PID for accesio productsRich Mattes
commit 3126d8236ca6f68eb8292c6af22c2e59afbeef24 upstream. Adds support for Accesio USB to Serial adapters, which are built around FTDI FT232 UARTs. Tested with the Accesio USB-COM-4SM. Signed-off-by: Rich Mattes <richmattes@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22USB: gadget: g_multi: fixed vendor and product IDMichal Nazarewicz
commit 1c6529e92b7682573837e9c9eb7b5ba7a8216a88 upstream. This patch fixes the vendor and product ID the gadget uses by replacing the temporary IDs that were used during development (which should never get into mainline) with proper IDs. Signed-off-by: Michal Nazarewicz <m.nazarewicz@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22USB: gadget: g_ffs: fixed vendor and product IDMichal Nazarewicz
commit ba0534be935d7b24e5fdd6f82c443ee75abc9149 upstream. This patch fixes the vendor and product ID the gadget uses by replacing the temporary IDs that were used during development (which should never get into mainline) with proper IDs. Signed-off-by: Michal Nazarewicz <m.nazarewicz@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22usb gadget: composite: prevent OOPS for non-standard control requestRoger Quadros
commit 5c836e4d583701a5eecb288b5f131da39115f5ec upstream. The composite gadget will OOPS if the host sends a control request targetted to an interface of an un-configured composite device. This patch prevents this. The OOPS was observed during WHQL USB CV tests. With this patch, the device STALLs as per requirement. Failing test case: From host do the following. I used libusb-1.0 1) Set configuration to zero. libusb_control_transfer(device_handle, 0, /* standard OUT */ 0x9, /* setConfiguration */ 0, 0, NULL, 0, 0); 2) Query current configuratioan. libusb_control_transfer(device_handle, 0x80, /* standard IN*/ 0x8, /* getConfiguration */ 0, 0, data, 1, 0); 3) Send the non-standard ctrl transfer targetted to interface libusb_control_transfer(device_handle, 0x81, /* standard IN to interface*/ 0x6, /* getDescriptor */ 0x2300, 0, data, 0x12, 0); Signed-off-by: Roger Quadros <roger.quadros@nokia.com> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Michal Nazarewicz <m.nazarewicz@samsung.com> Cc: Robert Lukassen <robert.lukassen@tomtom.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22drivers/net/wireless/p54/eeprom.c: Return -ENOMEM on memory allocation failureJulia Lawall
commit 0d91f22b75347d9503b17a42b6c74d3f7750acd6 upstream. In this code, 0 is returned on memory allocation failure, even though other failures return -ENOMEM or other similar values. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression ret; expression x,e1,e2,e3; @@ ret = 0 ... when != ret = e1 *x = \(kmalloc\|kcalloc\|kzalloc\)(...) ... when != ret = e2 if (x == NULL) { ... when != ret = e3 return ret; } // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Acked-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22p54usb: add five more USBIDsChristian Lamparter
commit 1a92795dac419128eb511dce30a6aad672064b88 upstream. Source: http://www.wikidevi.com/wiki/Intersil/p54/usb/windows Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22p54usb: fix off-by-one on !CONFIG_PMChristian Lamparter
commit 11791a6f7534906b4a01ffb54ba0b02ca39398ef upstream. The ISL3887 chip needs a USB reset, whenever the usb-frontend module "p54usb" is reloaded. This patch fixes an off-by-one bug, if the user is running a kernel without the CONFIG_PM option set and for some reason (e.g.: compat-wireless) wants to switch between different p54usb modules. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22pipe: fix failure to return error code on ->confirm()Nicolas Kaiser
commit e5953cbdff26f7cbae7eff30cd9b18c4e19b7594 upstream. The arguments were transposed, we want to assign the error code to 'ret', which is being returned. Signed-off-by: Nicolas Kaiser <nikai@nikai.net> Signed-off-by: Jens Axboe <jaxboe@fusionio.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22USB: mct_u232: fix broken closeJohan Hovold
commit 92ca0dc5ee022e4c0e488177e1d8865a0778c6c2 upstream. Fix regression introduced by commit f26788da3b342099d2b02d99ba1cb7f154d6ef7b (USB: serial: refactor generic close) which broke driver close(). This driver uses non-standard semantics for the read urb which makes the generic close function fail to kill it (the read urb is actually an interrupt urb and therefore bulk_in size is zero). Reported-by: Eric Shattow "Eprecocious" <lucent@gmail.com> Tested-by: Eric Shattow "Eprecocious" <lucent@gmail.com> Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22KVM: SVM: Restore correct registers after sel_cr0 intercept emulationJoerg Roedel
commit cda0008299a06f0d7218c6037c3c02d7a865e954 upstream. This patch implements restoring of the correct rip, rsp, and rax after the svm emulation in KVM injected a selective_cr0 write intercept into the guest hypervisor. The problem was that the vmexit is emulated in the instruction emulation which later commits the registers right after the write-cr0 instruction. So the l1 guest will continue to run with the l2 rip, rsp and rax resulting in unpredictable behavior. This patch is not the final word, it is just an easy patch to fix the issue. The real fix will be done when the instruction emulator is made aware of nested virtualization. Until this is done this patch fixes the issue and provides an easy way to fix this in -stable too. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22KVM: X86: Report SVM bit to userspace only when supportedJoerg Roedel
commit 4c62a2dc92518c5adf434df8e5c2283c6762672a upstream. This patch fixes a bug in KVM where it _always_ reports the support of the SVM feature to userspace. But KVM only supports SVM on AMD hardware and only when it is enabled in the kernel module. This patch fixes the wrong reporting. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22x86, vm86: Fix preemption bug for int1 debug and int3 breakpoint handlers.Bart Oldeman
commit 6554287b1de0448f1e02e200d02b43914e997d15 upstream. Impact: fix kernel bug such as: BUG: scheduling while atomic: dosemu.bin/19680/0x00000004 See also Ubuntu bug 455067 at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/455067 Commits 4915a35e35a037254550a2ba9f367a812bc37d40 ("Use preempt_conditional_sti/cli in do_int3, like on x86_64.") and 3d2a71a596bd9c761c8487a2178e95f8a61da083 ("x86, traps: converge do_debug handlers") started disabling preemption in int1 and int3 handlers on i386. The problem with vm86 is that the call to handle_vm86_trap() may jump straight to entry_32.S and never returns so preempt is never enabled again, and there is an imbalance in the preempt count. Commit be716615fe596ee117292dc615e95f707fb67fd1 ("x86, vm86: fix preemption bug"), which was later (accidentally?) reverted by commit 08d68323d1f0c34452e614263b212ca556dae47f ("hw-breakpoints: modifying generic debug exception to use thread-specific debug registers") fixed the problem for debug exceptions but not for breakpoints. There are three solutions to this problem. 1. Reenable preemption before calling handle_vm86_trap(). This was the approach that was later reverted. 2. Do not disable preemption for i386 in breakpoint and debug handlers. This was the situation before October 2008. As far as I understand preemption only needs to be disabled on x86_64 because a seperate stack is used, but it's nice to have things work the same way on i386 and x86_64. 3. Let handle_vm86_trap() return instead of jumping to assembly code. By setting a flag in _TIF_WORK_MASK, either TIF_IRET or TIF_NOTIFY_RESUME, the code in entry_32.S is instructed to return to 32 bit mode from V86 mode. The logic in entry_32.S was already present to handle signals. (I chose TIF_IRET because it's slightly more efficient in do_notify_resume() in signal.c, but in fact TIF_IRET can probably be replaced by TIF_NOTIFY_RESUME everywhere.) I'm submitting approach 3, because I believe it is the most elegant and prevents future confusion. Still, an obvious preempt_conditional_cli(regs); is necessary in traps.c to correct the bug. [ hpa: This is technically a regression, but because: 1. the regression is so old, 2. the patch seems relatively high risk, justifying more testing, and 3. we're late in the 2.6.36-rc cycle, I'm queuing it up for the 2.6.37 merge window. It might, however, justify as a -stable backport at a latter time, hence Cc: stable. ] Signed-off-by: Bart Oldeman <bartoldeman@users.sourceforge.net> LKML-Reference: <alpine.DEB.2.00.1009231312330.4732@localhost.localdomain> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: K.Prasad <prasad@linux.vnet.ibm.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Alexander van Heukelum <heukelum@fastmail.fm> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22x86, kdump: Change copy_oldmem_page() to use cached addressingCliff Wickman
commit 37a2f9f30a360fb03522d15c85c78265ccd80287 upstream. The copy of /proc/vmcore to a user buffer proceeds much faster if the kernel addresses memory as cached. With this patch we have seen an increase in transfer rate from less than 15MB/s to 80-460MB/s, depending on size of the transfer. This makes a big difference in time needed to save a system dump. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com> Cc: kexec@lists.infradead.org LKML-Reference: <E1OtMLz-0001yp-Ia@eag09.americas.sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22x86, intr-remap: Set redirection hint in the IRTESuresh Siddha
commit 75e3cfbed6f71a8f151dc6e413b6ce3c390030cb upstream. Currently the redirection hint in the interrupt-remapping table entry is set to 0, which means the remapped interrupt is directed to the processors listed in the destination. So in logical flat mode in the presence of intr-remapping, this results in a single interrupt multi-casted to multiple cpu's as specified by the destination bit mask. But what we really want is to send that interrupt to one of the cpus based on the lowest priority delivery mode. Set the redirection hint in the IRTE to '1' to indicate that we want the remapped interrupt to be directed to only one of the processors listed in the destination. This fixes the issue of same interrupt getting delivered to multiple cpu's in the logical flat mode in the presence of interrupt-remapping. While there is no functional issue observed with this behavior, this will impact performance of such configurations (<=8 cpu's using logical flat mode in the presence of interrupt-remapping) Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <20100827181049.013051492@sbsiddha-MOBL3.sc.intel.com> Cc: Weidong Han <weidong.han@intel.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22x86, mtrr: Assume SYS_CFG[Tom2ForceMemTypeWB] exists on all future AMD CPUsAndreas Herrmann
commit 3fdbf004c1706480a7c7fac3c9d836fa6df20d7d upstream. Instead of adapting the CPU family check in amd_special_default_mtrr() for each new CPU family assume that all new AMD CPUs support the necessary bits in SYS_CFG MSR. Tom2Enabled is architectural (defined in APM Vol.2). Tom2ForceMemTypeWB is defined in all BKDGs starting with K8 NPT. In pre K8-NPT BKDG this bit is reserved (read as zero). W/o this adaption Linux would unnecessarily complain about bad MTRR settings on every new AMD CPU family, e.g. [ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 4863MB of RAM. Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> LKML-Reference: <20100930123235.GB20545@loge.amd.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22x86, olpc: Don't retry EC commands foreverPaul Fox
commit 286e5b97eb22baab9d9a41ca76c6b933a484252c upstream. Avoids a potential infinite loop. It was observed once, during an EC hacking/debugging session - not in regular operation. Signed-off-by: Daniel Drake <dsd@laptop.org> Cc: dilinger@queued.net Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22x86, kexec: Make sure to stop all CPUs before exiting the kernelAlok Kataria
commit 76fac077db6b34e2c6383a7b4f3f4f7b7d06d8ce upstream. x86 smp_ops now has a new op, stop_other_cpus which takes a parameter "wait" this allows the caller to specify if it wants to stop until all the cpus have processed the stop IPI. This is required specifically for the kexec case where we should wait for all the cpus to be stopped before starting the new kernel. We now wait for the cpus to stop in all cases except for panic/kdump where we expect things to be broken and we are doing our best to make things work anyway. This patch fixes a legitimate regression, which was introduced during 2.6.30, by commit id 4ef702c10b5df18ab04921fc252c26421d4d6c75. Signed-off-by: Alok N Kataria <akataria@vmware.com> LKML-Reference: <1286833028.1372.20.camel@ank32.eng.vmware.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Jeremy Fitzhardinge <jeremy@xensource.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22x86, mrst: A function in a header file needs to be marked "inline"H. Peter Anvin
commit 55572b293b3a5929e8c54bc91d14ae6264186bf6 upstream. A function in a header file needs to be explicitly marked "inline", or gcc will complain if it is not used. Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> LKML-Reference: <1274295685-6774-3-git-send-email-jacob.jun.pan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22x86, cpu: Fix renamed, not-yet-shipping AMD CPUID feature bitAndre Przywara
commit 7ef8aa72ab176e0288f363d1247079732c5d5792 upstream. The AMD SSE5 feature set as-it has been replaced by some extensions to the AVX instruction set. Thus the bit formerly advertised as SSE5 is re-used for one of these extensions (XOP). Although this changes the /proc/cpuinfo output, it is not user visible, as there are no CPUs (yet) having this feature. To avoid confusion this should be added to the stable series, too. Signed-off-by: Andre Przywara <andre.przywara@amd.com> LKML-Reference: <1283778860-26843-2-git-send-email-andre.przywara@amd.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
generated by cgit v1.2.3 (git 2.0.4) at 2024-05-29 09:03:49 +0000