summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2009-03-23USB: usbfs: keep async URBs until the device file is closedAlan Stern
commit 6ff10464096540e14d7575a72c50d0316d003714 upstream. The usbfs driver manages a list of completed asynchronous URBs. But it is too eager to free the entries on this list: destroy_async() gets called whenever an interface is unbound or a device is removed, and it deallocates the outstanding struct async entries for all URBs on that interface or device. This is wrong; the user program should be able to reap an URB any time after it has completed, regardless of whether or not the interface is still bound or the device is still present. This patch (as1222) moves the code for deallocating the completed list entries from destroy_async() to usbdev_release(). The outstanding entries won't be freed until the user program has closed the device file, thereby eliminating any possibility that the remaining URBs might still be reaped. This fixes a bug in which a program can hang in the USBDEVFS_REAPURB ioctl when the device is unplugged. Reported-and-tested-by: Martin Poupe <martin.poupe@upek.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-23USB: Updated unusual-devs entry for USB mass storage on Nokia 6233Moritz Muehlenhoff
commit 716a9c8561d9c50ec454f4fbd39a265892feda2c upstream. Current firmware revision 5.60 still behaves the same, so update the quirk up a (non-existing) 99.99 revision. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493415 Signed-off-by: Moritz Muehlenhoff <jmm@debian.org> Tested-by: Jan Heitkoetter <devnull@heitkoetter.net> Signed-off-by: Phil Dibowitz <phil@ipom.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-23USB: unusual_devs: Add support for GI 0431 SD-Card interfaceJan Dumon
commit c497e715f93d148d751c055401568684eea0bf6b upstream. Enable the SD-Card interface on the GI 0431 HSUPA stick from Option. The unusual_devs.h entry is necessary because the device descriptor is vendor-specific. That prevents usb-storage from binding to it as an interface driver. T: Bus=07 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 15 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1 P: Vendor=0af0 ProdID=7501 Rev= 0.00 S: Manufacturer=Option N.V. S: Product=Globetrotter HSUPA Modem C:* #Ifs=11 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=hso E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=hso E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=hso E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=hso E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 9 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=hso E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#=10 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8c(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Jan Dumon <j.dumon@option.com> Signed-off-by: Phil Dibowitz <phil@ipom.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-23USB: storage: Unusual USB device Prolific 2507 variation addedThomas Bartosik
commit 8a0845c51b2e300f5204a323b874f7f58ea0eff7 upstream. The "c-enter" USB to Toshiba 1.8" IDE enclosure needs special treatment to work flawlessly. This patch is absolutely trivial, as the integrated USB-IDE bridge is already identified to be an "unusual" device, only the bcdDevice is different (lower) to the bcdDeviceMin already included in the kernel. It is a Prolific 2507 bridge. T: Bus=02 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=067b ProdID=2507 Rev= 0.01 S: Manufacturer=Prolific Technology Inc. S: Product=ATAPI-6 Bridge Controller S: SerialNumber=00000272 C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Thomas Bartosik <tbartdev@gmx-topmail.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-23USB: serial: new cp2101 device idRobert M. Kenney
commit c6535668798b0644e1af5934c2aec0e912280449 upstream. From: Robert M. Kenney <rmk@unh.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-23USB: serial: ftdi: enable UART detection on gnICE JTAG adaptors blacklist ↵Michael Hennerich
interface0 commit b0d659002168146ec6b03d1ef062d8dcf05ff510 upstream. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-23USB: serial: add FTDI USB/Serial converter devicesAxel Wachtler
commit 7f82b6dd7015aabca2fd55fb690248f742cd67f3 upstream. Add the following devices to the USB FTDI SIO device table: Bus 001 Device 009: ID 03eb:2109 Atmel Corp. http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4187 Bus 001 Device 008: ID 1cf1:0001 http://www.dresden-elektronik.de/shop/prod75.html Bus 001 Device 007: ID 1c1f:0004 http://www.dresden-elektronik.de/shop/prod64.html Signed-off-by: Axel Wachtler <axel.wachtler@atmel.com> Signed-off-by: Robert Richter <robert.richter@amd.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-23USB: Option: let cdc-acm handle Sony Ericsson F3507g / Dell 5530Dan Williams
commit 0cc6bfe901b946df125d8e37186d8e45f876457d upstream. The generic cdc-acm driver is now the best one to handle Sony Ericsson F3507g-based devices (which the Dell 5530 is a rebrand of), now that all the pieces are in place (ie, cac477e8f1038c41b6f29d3161ce351462ef3df7). Removing the IDs from option allows cdc-acm to handle the device. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-23USB: Add device id for Option GTM380 to option driverAchilleas Kotsis
commit e7f2f0d77a7b483a26054f29ba8393831b25a8a4 upstream. Option GTM380 in Modem mode uses Product ID 0x7201. This has been tested and works on production systems for over 6 months. Signed-off-by: Achilleas Kotsis <akots@exponent.gr> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-23USB: option.c: add ZTE 622 modem deviceAlbert Pauw
commit 9ea19b82f3126da4e47d6b94563a3c2cd586f6e2 upstream. Please consider this small patch for the usb option-card driver. This patch adds the ZTE 622 usb modem device. Signed-off-by: Albert Pauw <albert.pauw@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-23USB: Add Vendor/Product ID for new CDMA U727 to option driverDirk Hohndel
commit 56a21827439a4d715b510bfaf488534e6f4ad2f8 upstream. * newer versions of the Novatel Wireless U727 CDMA 3G USB stick have a different Product ID (0x5010); adding this ID makes them work just fine with the option driver Signed-off-by: Dirk Hohndel <hohndel@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-23USB: EHCI: Fix isochronous URB leakKarsten Wiese
commit 508db8c954d55ed30f870d2c24d741ba6269d13c upstream. ehci-hcd uses usb_get_urb() and usb_put_urb() in an unbalanced way causing isochronous URB's kref.counts incrementing once per usb_submit_urb() call. The culprit is *usb being set to NULL when usb_put_urb() is called after URB is given back. Due to other fixes there is no need for ehci-hcd to deal with usb_get_urb() nor usb_put_urb() anymore, so patch removes their usages in ehci-hcd. Patch also makes ehci_to_hcd(ehci)->self.bandwidth_allocated adjust, if a stream finishes. Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-23USB: EHCI: expedite unlinks when the root hub is suspendedAlan Stern
commit 391016f6e2fe3b9979b4c6880a76e5e434d6947c upstream. This patch (as1225) fixes a bug in ehci-hcd. The condition for whether unlinked QHs can become IDLE should not be that the controller is halted, but rather that the controller isn't running. In other words when the root hub is suspended, the hardware doesn't own any QHs. This fixes a problem that can show up during hibernation: If a QH is only partially unlinked when the root hub is frozen, then when the root hub is thawed the QH won't be in the IDLE state. As a result it can't be used properly for new URB submissions. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Brandon Philips <brandon@ifup.org> Tested-by: Brandon Philips <brandon@ifup.org> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-23V4L/DVB (10218): cx23885: Fix Oops for mixed install of analog and digital ↵Andy Walls
only cards commit cd8f894eacf13996d920fdd2aef1afc55156b191 upstream. Analog support for HVR-1250 has not been completed, but does exist for the HVR-1800. Since both cards use the same driver, it tries to create the analog dev for both devices, which is not possible. This causes a NULL error to show up in video_open and mpeg_open. -Mark Iterations through the cx23885_devlist must check for NULL pointers as some supported devices only have DVB support at the moment. Mark Jenks encoutered an Oops in a system with both an HVR-1250 and HVR-1800 installed. -Andy Reported-by: Mark Jenks <mjenks1968@gmail.com> Tested-by: Mark Jenks <mjenks1968@gmail.com> Signed-off-by: Mark Jenks <mjenks1968@gmail.com> Signed-off-by: Andy Walls <awalls@radix.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-23thinkpad-acpi: fix module autoloading for older modelsMathieu Chouquet-Stringer
commit b36a50f92d1c4300a88f606b4d2bbdc4f442a2d7 upstream. Looking at the source, there seems to be a missing * to match my DMI string. I mean for newer IBM and Lenovo's laptops you match either one of the following: MODULE_ALIAS("dmi:bvnIBM:*:svnIBM:*:pvrThinkPad*:rvnIBM:*"); MODULE_ALIAS("dmi:bvnLENOVO:*:svnLENOVO:*:pvrThinkPad*:rvnLENOVO:*"); While for older Thinkpads, you do this (for instance): IBM_BIOS_MODULE_ALIAS("1[0,3,6,8,A-G,I,K,M-P,S,T]"); with IBM_BIOS_MODULE_ALIAS being MODULE_ALIAS("dmi:bvnIBM:bvr" __type "ET??WW") Note there's no * terminating the string. As result, udev doesn't load anything because modprobe cannot find anything matching this (my machine actually): udevtest: run: '/sbin/modprobe dmi:bvnIBM:bvr1IET71WW(2.10):bd06/16/2006:svnIBM:pn236621U:pvrNotAv Signed-off-by: Mathieu Chouquet-Stringer <mchouque@free.fr> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-23dm io: respect BIO_MAX_PAGES limitMikulas Patocka
commit d659e6cc98766a1a61d6bdd283f95d149abd7719 upstream. dm-io calls bio_get_nr_vecs to get the maximum number of pages to use for a given device. It allocates one additional bio_vec to use internally but failed to respect BIO_MAX_PAGES, so fix this. This was the likely cause of: https://bugzilla.redhat.com/show_bug.cgi?id=173153 Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-23dm ioctl: validate name length when renamingMilan Broz
commit bc0fd67feba2e0770aad85393500ba77c6489f1c upstream. When renaming a mapped device validate the length of the new name. The rename ioctl accepted any correctly-terminated string enclosed within the data passed from userspace. The other ioctls enforce a size limit of DM_NAME_LEN. If the name is changed and becomes longer than that, the device can no longer be addressed by name. Fix it by properly checking for device name length (including terminating zero). Signed-off-by: Milan Broz <mbroz@redhat.com> Reviewed-by: Jonathan Brassow <jbrassow@redhat.com> Reviewed-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-23dm crypt: fix kcryptd_async_done parameterHuang Ying
commit b2174eebd1fadb76454dad09a1dacbc17081e6b0 upstream. In the async encryption-complete function (kcryptd_async_done), the crypto_async_request passed in may be different from the one passed to crypto_ablkcipher_encrypt/decrypt. Only crypto_async_request->data is guaranteed to be same as the one passed in. The current kcryptd_async_done uses the passed-in crypto_async_request directly which may cause the AES-NI-based AES algorithm implementation to panic. This patch fixes this bug by only using crypto_async_request->data, which points to dm_crypt_request, the crypto_async_request passed in. The original data (convert_context) is gotten from dm_crypt_request. [mbroz@redhat.com: reworked] Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Milan Broz <mbroz@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-23ata_piix: add workaround for Samsung DB-P70Tejun Heo
commit e9c1670c2a14ef9cc20d86b24b829f3947aad34e upstream. Samsung DB-P70 somehow botched the first ICH9 SATA port. The board doesn't expose the first port but somehow SStatus reports link online while failing SRST protocol leading to repeated probe failures and thus long boot delay. Because the BIOS doesn't carry any identifying DMI information, the port can't be blacklisted safely. Fortunately, the controller does have subsystem vendor and ID set. It's unclear whether the subsystem IDs are used only for the board but it can be safely worked around by disabling SIDPR access and just using SRST works around the problem. Even when the workaround is triggered on an unaffected board the only side effect will be missing SCR access. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Joseph Jang <josephjang@gmail.com> Reported-by: Jonghyon Sohn <mrsohn@gmail.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16hwmon: (it87) Properly decode -128 degrees C temperatureJean Delvare
commit e267d25005c861fe6afda343f044536342c9f8b4 upstream The it87 driver is reporting -128 degrees C as +128 degrees C. That's not a terribly likely temperature value but let's still get it right, especially when it simplifies the code. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16ARM: Add i2c_board_info for RiscPC PCF8583Russell King
commit 531660ef5604c75de6fdead9da1304051af17c09 upstream Add the necessary i2c_board_info structure to fix the lack of PCF8583 RTC on RiscPC. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16ide-iops: fix odd-length ATAPI PIO transfersSergei Shtylyov
commit a509538d4fb4f99cdf0a095213d57cc3b2347615 upstream. Commit 9567b349f7e7dd7e2483db99ee8e4a6fe0caca38 (ide: merge ->atapi_*put_bytes and ->ata_*put_data methods) introduced a regression WRT the odd-length ATAPI PIO transfers -- the final word didn't get written (causing command timeouts). Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16i2c: Timeouts reach -1Roel Kluin
commit a746b578d8406b2db0e9f0d040061bc1f78433cf upstream With a postfix decrement these timeouts reach -1 rather than 0, but after the loop it is tested whether they have become 0. As pointed out by Jean Delvare, the condition we are waiting for should also be tested before the timeout. With the current order, you could exit with a timeout error while the job is actually done. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16i2c: Fix misplaced parenthesesRoel Kluin
commit f29d2e0275a4f03ef2fd158e484508dcb0c64efb upstream Fix misplaced parentheses. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16hwmon: (f71882fg) Hide misleading error messageJean Delvare
commit 603eaa1bdd3e0402085e815cc531bb0a32827a9e upstream If the F71882FG chip is at address 0x4e, then the probe at 0x2e will fail with the following message in the logs: f71882fg: Not a Fintek device This is misleading because there is a Fintek device, just at a different address. So I propose to degrade this message to a debug message. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Hans de Goede <hdegoede@redhat.com>
2009-03-16ACPI: fix broken usage of name.asciiHenrique de Moraes Holschuh
This issue was fixed indirectly in mainline by commit 0175d562a29ad052c510782c7e76bc63d5155b9b. acpi_namespace_node's name.ascii field is four chars, and not NULL- terminated except by pure luck. So, it cannot be used by sscanf() without a length restriction. This is the minimal fix for both stable 2.6.27 and 2.6.28. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Lin Ming <ming.m.lin@intel.com> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16V4L: ivtv: fix decoder crash regressionHans Verkuil
(cherry picked from commit ac9575f75c52bcb455120f8c43376b556acba048) The video_ioctl2 conversion of ivtv in kernel 2.6.27 introduced a bug causing decoder commands to crash. The decoder commands should have been handled from the video_ioctl2 default handler, ensuring correct mapping of the argument between user and kernel space. Unfortunately they ended up before the video_ioctl2 call, causing random crashes. Thanks to hannes@linus.priv.at for testing and helping me track down the cause! Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16V4L: tda8290: fix TDA8290 + TDA18271 initializationMichael Krufky
(cherry picked from commit 439b72b69e4992e9ec34b74304f0fa95623934eb) Don't call tda8290_init_tuner unless we have either a TDA8275 or TDA8275A present. Calling this function will cause a TDA18271 to get sick, so we should only call it when needed. Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16DVB: s5h1409: Perform s5h1409 soft reset after tuningDevin Heitmueller
(cherry picked from commit 67e70baf043cfdcdaf5972bc94be82632071536b) Just like with the s5h1411, the s5h1409 needs a soft-reset in order for it to know that the tuner has been told to change frequencies. This change changes the behavior from "random tuning times between 500ms to complete tuning lock failures" to "tuning lock consistently within 700ms". Thanks to Robert Krakora <rob.krakora@messagenetsystems.com> for doing initial testing of the patch on the KWorld 330U. Thanks to Andy Walls <awalls@radix.net> for doing testing of the patch on the HVR-1600. Thanks to Michael Krufky <mkrufky@linuxtv.org> for doing additional testing. Signed-off-by: Devin Heitmueller <dheitmueller@linuxtv.org> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16zaurus: add usb id for motomagx phonesDmitriy Taychenachev
commit 52c0326beaa3cb0049d0f1c51c6ad5d4a04e4430 upstream. The Motorola MOTOMAGX phones (Z6, E8, Zn5 so far) are providing combined ACM/BLAN USB configuration. Since it has Vendor Specific class, the corresponding drivers (cdc-acm, zaurus) can't find it just by interface info. This patch adds usb id so the zaurus driver can properly handle this combined device. Signed-off-by: Dmitriy Taychenachev <dimichxp@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16xen/blkfront: use blk_rq_map_sg to generate ring entriesJens Axboe
commit 9e973e64ac6dc504e6447d52193d4fff1a670156 upstream. On occasion, the request will apparently have more segments than we fit into the ring. Jens says: > The second problem is that the block layer then appears to create one > too many segments, but from the dump it has rq->nr_phys_segments == > BLKIF_MAX_SEGMENTS_PER_REQUEST. I suspect the latter is due to > xen-blkfront not handling the merging on its own. It should check that > the new page doesn't form part of the previous page. The > rq_for_each_segment() iterates all single bits in the request, not dma > segments. The "easiest" way to do this is to call blk_rq_map_sg() and > then iterate the mapped sg list. That will give you what you are > looking for. > Here's a test patch, compiles but otherwise untested. I spent more > time figuring out how to enable XEN than to code it up, so YMMV! > Probably the sg list wants to be put inside the ring and only > initialized on allocation, then you can get rid of the sg on stack and > sg_init_table() loop call in the function. I'll leave that, and the > testing, to you. [Moved sg array into info structure, and initialize once. -J] Signed-off-by: Jens Axboe <jens.axboe@oracle.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Sven Köhler <sven.koehler@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16USB: option: add BenQ 3g modem informationJesse Sung
commit 28fb66821f884870987a0b5ab064ef651d9f7c16 upstream. This patch addes the BenQ 3g modem support to the option driver. From: Jesse Sung <jsung@novell.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16USB: EHCI: slow down ITD reuseKarsten Wiese
commit 9aa09d2f8f4bc440d6db1c3414d4009642875240 upstream. Currently ITDs are immediately recycled whenever their URB completes. However, EHCI hardware can sometimes remember some ITD state. This means that when the ITD is reused before end-of-frame it may sometimes cause the hardware to reference bogus state. This patch defers reusing such ITDs by moving them into a new ehci member cached_itd_list. ITDs resting in cached_itd_list are moved back into their stream's free_list once scan_periodic() detects that the active frame has elapsed. This makes the snd_usb_us122l driver (in kernel since .28) work right when it's hooked up through EHCI. [ dbrownell@users.sourceforge.net: comment fixups ] Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de> Tested-by: Philippe Carriere <philippe-f.carriere@wanadoo.fr> Tested-by: Federico Briata <federicobriata@gmail.com> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16sis190: add identifier for Atheros AR8021 PHYFrancois Romieu
commit 708f6e27c3f75166433b69174a8348308e55d073 upstream. Fixes http://bugzilla.kernel.org/show_bug.cgi?id=10994 Contributed by pablomme@googlemail.com, coenraad@wish.org.za and a few others. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Cc: Daniel Drake <dsd@gentoo.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16sdhci: fix led namingHelmut Schaa
commit 5dbace0c9ba110c1a3810a89fa6bf12b7574b5a3 upstream. Fix the led device naming for the sdhci driver. The led class documentation defines the led name to have the form "devicename:colour:function" while not applicable sections should be left blank. To comply with the documentation the led device name is changed from "mmc*" to "mmc*::". Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16RDMA/nes: Don't allow userspace QPs to use STag zeroFaisal Latif
commit c12e56ef6951f4fce1afe9ef6aab9243ea9a9b04 upstream. STag zero is a special STag that allows consumers to access any bus address without registering memory. The nes driver unfortunately allows STag zero to be used even with QPs created by unprivileged userspace consumers, which means that any process with direct verbs access to the nes device can read and write any memory accessible to the underlying PCI device (usually any memory in the system). Such access is usually given for cluster software such as MPI to use, so this is a local privilege escalation bug on most systems running this driver. The driver was using STag zero to receive the last streaming mode data; to allow STag zero to be disabled for unprivileged QPs, the driver now registers a special MR for this data. Signed-off-by: Faisal Latif <faisal.latif@intel.com> Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16PCIe: portdrv: call pci_disable_device during removeAlex Chiang
commit d89987193631bf23d1735c55d13a06d4b8d0e9bd upstream. The PCIe port driver calls pci_enable_device() during probe but never calls pci_disable_device() during remove. Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16PCI: Enable PCIe AER only after checking firmware supportAndrew Patterson
commit 1f9f13c8d59c1d8da1a602b71d1ab96d1d37d69e upstream. The PCIe port driver currently sets the PCIe AER error reporting bits for any root or switch port without first checking to see if firmware will grant control. This patch moves setting these bits to the AER service driver aer_enable_port routine. The bits are then set for the root port and any downstream switch ports after the check for firmware support (aer_osc_setup) is made. The patch also unsets the bits in a similar fashion when the AER service driver is unloaded. Reviewed-by: Alex Chiang <achiang@hp.com> Signed-off-by: Andrew Patterson <andrew.patterson@hp.com> Signed-off-by: Jesse Barnes <jbarnes@hobbes.lan> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16PCI: Add PCI quirk to disable L0s ASPM state for 82575 and 82598Alexander Duyck
commit 649426efcfbc67a8b033497151816cbac9fd0cfa upstream. This patch is intended to disable L0s ASPM link state for 82598 (ixgbe) parts due to the fact that it is possible to corrupt TX data when coming back out of L0s on some systems. The workaround had been added for 82575 (igb) previously, but did not use the ASPM api. This quirk uses the ASPM api to prevent the ASPM subsystem from re-enabling the L0s state. Instead of adding the fix in igb to the ixgbe driver as well it was decided to move it into a pci quirk. It is necessary to move the fix out of the driver and into a pci quirk in order to prevent the issue from occuring prior to driver load to handle the possibility of the device being passed to a VM via direct assignment. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> CC: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16mtd_dataflash: fix probing of AT45DB321C chips.Will Newton
commit 229cc58ba2b5a83b0b55764c6cb98695c106238a upstream. Commit 771999b65f79264acde4b855e5d35696eca5e80c ("[MTD] DataFlash: bugfix, binary page sizes now handled") broke support for probing AT45DB321C flash chips. These chips do not support the "page size" status bit, so if we match the JEDEC id return early. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Will Newton <will.newton@gmail.com> Cc: David Woodhouse <dwmw2@infradead.org> Acked-by: David Brownell <dbrownell@users.sourceforge.net> 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>
2009-03-16mmc_test: fix basic read testRabin Vincent
commit 58a5dd3e0e77029d3db1f8fa75d0b54b38169d5d upstream. Due to a typo in the Basic Read test, it's currently identical to the Basic Write test. Fix this. Signed-off-by: Rabin Vincent <rabin@rab.in> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16mmc: s3cmci: fix s3c2410_dma_config() arguments.Ben Dooks
commit 7c48ed3383bfb2106694807361ec187fe8a4333d upstream. The s3cmci driver is calling s3c2410_dma_config with incorrect data for the DCON register. The S3C2410_DCON_HWTRIG is implicit in the channel configuration and the device selection of S3C2410_DCON_CH0_SDI is incorrect as the DMA system may not select channel 0. Signed-off-by: Ben Dooks <ben@simtec.co.uk> Acked-by: Pierre Ossman <drzeus@drzeus.cx> 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>
2009-03-16md/raid10: Don't skip more than 1 bitmap-chunk at a time during recovery.NeilBrown
commit 09b4068a7fe442efc40e9dcbcf5ff37c3338ab15 upstream. When doing recovery on a raid10 with a write-intent bitmap, we only need to recovery chunks that are flagged in the bitmap. However if we choose to skip a chunk as it isn't flag, the code currently skips the whole raid10-chunk, thus it might not recovery some blocks that need recovering. This patch fixes it. In case that is confusing, it might help to understand that there is a 'raid10 chunk size' which guides how data is distributed across the devices, and a 'bitmap chunk size' which says how much data corresponds to a single bit in the bitmap. This bug only affects cases where the bitmap chunk size is smaller than the raid10 chunk size. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16md/raid10: Don't call bitmap_cond_end_sync when we are doing recovery.NeilBrown
commit 78200d45cde2a79c0d0ae0407883bb264caa3c18 upstream. For raid1/4/5/6, resync (fixing inconsistencies between devices) is very similar to recovery (rebuilding a failed device onto a spare). The both walk through the device addresses in order. For raid10 it can be quite different. resync follows the 'array' address, and makes sure all copies are the same. Recover walks through 'device' addresses and recreates each missing block. The 'bitmap_cond_end_sync' function allows the write-intent-bitmap (When present) to be updated to reflect a partially completed resync. It makes assumptions which mean that it does not work correctly for raid10 recovery at all. In particularly, it can cause bitmap-directed recovery of a raid10 to not recovery some of the blocks that need to be recovered. So move the call to bitmap_cond_end_sync into the resync path, rather than being in the common "resync or recovery" path. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16md: avoid races when stopping resync.NeilBrown
commit 73d5c38a9536142e062c35997b044e89166e063b upstream. There has been a race in raid10 and raid1 for a long time which has only recently started showing up due to a scheduler changed. When a sync_read request finishes, as soon as reschedule_retry is called, another thread can mark the resync request as having completed, so md_do_sync can finish, ->stop can be called, and ->conf can be freed. So using conf after reschedule_retry is not safe. Similarly, when finishing a sync_write, calling md_done_sync must be the last thing we do, as it allows a chain of events which will free conf and other data structures. The first of these requires action in raid10.c The second requires action in raid1.c and raid10.c Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16libata: make sure port is thawed when skipping resetsTejun Heo
commit d6515e6ff4ad3db4bd5ef2dd4e1026a7aca2482e upstream. When SCR access is available and the link is offline, softreset is skipped as it only wastes time and some controllers don't respond very well. However, the skip path forgot to thaw the port, which not only blocks further event notification from the port but also causes repeated EH invocations on the same event on drivers which rely on ->thaw() to clear events if the IRQ is shared with another device or port. This problem has always been there but is uncovered by recent sata_nv nf2/3 change which dropped hardreset support while maintaining SCR access. nf2/3 doesn't clear hotplug event mask from the interrupt handler but relies on ->thaw() to clear them. When the hardreset was there, the reset action was never skipped and the port was always thawed but, with the hardreset gone, ->prereset() determines that there's no need for softreset and both ->softreset() and ->thaw() are skipped. This leads to stuck hotplug event in the IRQ status register triggering hotplug event whenever IRQ is delieverd on the same IRQ. As the controller shares the same IRQ for both ports, this happens on every IO if one port is occpupied and the other isn't. This patch fixes the problem by making sure that the port is thawed on reset-skip path. bko#11615 reports this problem. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Robert Hancock <hancockrwd@gmail.com> Reported-by: Dan Andresan <danyer@gmail.com> Reported-by: Arne Woerner <arne_woerner@yahoo.com> Reported-by: Stefan Lippers-Hollmann <s.L-H@gmx.de> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16libata: Don't trust current capacity values in identify words 57-58Robert Hancock
commit 968e594afdbc40b4270f9d4032ae8350475749d6 upstream. Hanno Böck reported a problem where an old Conner CP30254 240MB hard drive was reported as 1.1TB in capacity by libata: http://lkml.org/lkml/2009/2/13/134 This was caused by libata trusting the drive's reported current capacity in sectors in identify words 57 and 58 if the drive does not support LBA and the current CHS translation values appear valid. Unfortunately it seems older ATA specs were vague about what this field should contain and a number of drives used values with wrong byte order or that were totally bogus. There's no unique information that it conveys and so we can just calculate the number of sectors from the reported current CHS values. While we're at it, clean up this function to use named constants for the identify word values. Signed-off-by: Robert Hancock <hancockrwd@gmail.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-16jsm: additional device supportAdam Lackorzynski
commit ffa7525c13eb3db0fd19a3e1cffe2ce6f561f5f3 upstream. I have a Digi Neo 8 PCI card (114f:00b1) Serial controller: Digi International Digi Neo 8 (rev 05) that works with the jsm driver after using the following patch. Signed-off-by: Adam Lackorzynski <adam@os.inf.tu-dresden.de> Cc: Scott H Kilau <Scott_Kilau@digi.com> Cc: Wendy Xiong <wendyx@us.ibm.com> Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk> 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>
2009-03-16intel-agp: fix a panic with 1M of shared memory, no GTT entriesLubomir Rintel
commit 9c1e8a4ebcc04226cb6f3a1bf1d72f4cafd6b089 upstream. When GTT size is equal to amount of video memory, the amount of GTT entries is computed lower than zero, which is invalid and leads to off-by-one error in intel_i915_configure() Originally posted here: http://bugzilla.kernel.org/show_bug.cgi?id=12539 http://bugzilla.redhat.com/show_bug.cgi?id=445592 Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Cc: Lubomir Rintel <lkundrak@v3.sk> Cc: Dave Airlie <airlied@linux.ie> Reviewed-by: Eric Anholt <eric@anholt.net> 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>
2009-03-16hpilo: new pci deviceDavid Altobelli
commit 31d8b5631f095cb7100cfccc95c801a2547ffe2b upstream. Future iLO devices will have an HP vendor id. Signed-off-by: David Altobelli <david.altobelli@hp.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>