aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2012-04-24Merge branches 'mad-response' and 'mlx4' into fixesRoland Dreier1-1/+1
2012-04-24IB/mlx4: Fix memory leaks in ib_link_query_port()Jesper Juhl1-1/+1
If the call to mlx4_MAD_IFC() fails in ib_link_query_port() we will currently do 'return err;' which will leak 'in_mad' and 'out_mad'. We should instead do 'goto out;' where we'll properly free the memory we previously allocated. Signed-off-by: Jesper Juhl <[email protected]> Acked-by: Or Gerlitz <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2012-04-24IB/mad: Don't send response for failed MADsJack Morgenstein1-3/+3
Commit 0b307043049f ("IB/mad: Return error response for unsupported MADs") does not failed MADs (eg those that return IB_MAD_RESULT_FAILURE) properly -- these MADs should be silently discarded. (We should not force the lower-layer drivers to return SUCCESS | CONSUMED in this case, since the MAD is NOT successful). Unsupported MADs are not failures -- they return SUCCESS, but with an "unsupported error" status value inside the response MAD. Reviewed-by: Hal Rosenstock <[email protected]> Signed-off-by: Jack Morgenstein <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2012-04-24IB/mad: Set 'D' bit in response for unhandled MADsJack Morgenstein1-0/+2
Commit 0b307043049f ("IB/mad: Return error response for unsupported MADs") does not handle directed-route MADs properly -- it fails to set the 'D' bit in the response MAD status field. This is a problem for SmInfo MADs when the receiver does not have an SM running. Reviewed-by: Hal Rosenstock <[email protected]> Signed-off-by: Jack Morgenstein <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2012-04-24USB: EHCI: fix crash during suspend on ASUS computersAlan Stern2-0/+17
This patch (as1545) fixes a problem affecting several ASUS computers: The machine crashes or corrupts memory when going into suspend if the ehci-hcd driver is bound to any controllers. Users have been forced to unbind or unload ehci-hcd before putting their systems to sleep. After extensive testing, it was determined that the machines don't like going into suspend when any EHCI controllers are in the PCI D3 power state. Presumably this is a firmware bug, but there's nothing we can do about it except to avoid putting the controllers in D3 during system sleep. The patch adds a new flag to indicate whether the problem is present, and avoids changing the controller's power state if the flag is set. Runtime suspend is unaffected; this matters only for system suspend. However as a side effect, the controller will not respond to remote wakeup requests while the system is asleep. Hence USB wakeup is not functional -- but of course, this is already true in the current state of affairs. This fixes Bugzilla #42728. Signed-off-by: Alan Stern <[email protected]> Tested-by: Steven Rostedt <[email protected]> Tested-by: Andrey Rahmatullin <[email protected]> Tested-by: Oleksij Rempel (fishor) <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-04-24usb gadget: uvc: uvc_request_data::length field must be signedLaurent Pinchart2-2/+2
The field is used to pass the UVC request data length, but can also be used to signal an error when setting it to a negative value. Switch from unsigned int to __s32. Reported-by: Fernandez Gonzalo <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-04-24staging: octeon-ethernet: fix build errors by including interrupt.hImre Kaloz3-0/+3
This patch fixes the following build failures: drivers/staging/octeon/ethernet.c: In function 'cvm_oct_cleanup_module': drivers/staging/octeon/ethernet.c:799:2: error: implicit declaration of function 'free_irq' drivers/staging/octeon/ethernet-rx.c: In function 'cvm_oct_no_more_work': drivers/staging/octeon/ethernet-rx.c:119:3: error: implicit declaration of function 'enable_irq' drivers/staging/octeon/ethernet-rx.c: In function 'cvm_oct_do_interrupt': drivers/staging/octeon/ethernet-rx.c:136:2: error: implicit declaration of function 'disable_irq_nosync' drivers/staging/octeon/ethernet-rx.c: In function 'cvm_oct_rx_initialize': drivers/staging/octeon/ethernet-rx.c:532:2: error: implicit declaration of function 'request_irq' drivers/staging/octeon/ethernet-tx.c: In function 'cvm_oct_tx_initialize': drivers/staging/octeon/ethernet-tx.c:712:2: error: implicit declaration of function 'request_irq' drivers/staging/octeon/ethernet-tx.c: In function 'cvm_oct_tx_shutdown': drivers/staging/octeon/ethernet-tx.c:723:2: error: implicit declaration of function 'free_irq' Signed-off-by: Imre Kaloz <[email protected]> Acked-by: David Daney <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-04-24staging: zcache: fix Kconfig crypto dependencySeth Jennings1-1/+1
ZCACHE is a boolean in the Kconfig. When selected, it should require that CRYPTO be builtin (=y). Currently, ZCACHE=y and CRYPTO=m is a valid configuration when it should not be. This patch changes the zcache Kconfig to enforce this dependency. Signed-off-by: Seth Jennings <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-04-24staging: tidspbridge: remove usage of OMAP2_L4_IO_ADDRESSOmar Ramirez Luna2-9/+19
Instead now use ioremap. This is needed for 3.4 since this change emerged in mainline during one of the previous rc cycles. These solves the following compilation breaks: drivers/staging/tidspbridge/core/tiomap3430.c: In function ‘bridge_brd_start’: drivers/staging/tidspbridge/core/tiomap3430.c:425:4: error: implicit declaration of function ‘OMAP2_L4_IO_ADDRESS’ drivers/staging/tidspbridge/core/wdt.c: In function ‘dsp_wdt_init’: drivers/staging/tidspbridge/core/wdt.c:56:2: error: implicit declaration of function ‘OMAP2_L4_IO_ADDRESS’ For control registers a new function needs to be defined so we can get rid of a layer violation, but that approach must be queued for the next merge window. As seen in: http://www.arm.linux.org.uk/developer/build/ platform: omap4430-sdp build: uImage config: randconfig version: 3.4.0-rc3 start time: Apr 20 2012 01:07 Reported-by: Tony Lindgren <[email protected]> Signed-off-by: Omar Ramirez Luna <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-04-24iwlwifi: use correct released ucode versionMeenakshi Venkataraman4-18/+27
Report correctly the latest released version of the iwlwifi firmware for all iwlwifi-supported devices. Cc: [email protected] #3.3+ Signed-off-by: Meenakshi Venkataraman <[email protected]> Signed-off-by: Wey-Yi Guy <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2012-04-24iwlwifi: fix hardware queue programmingJohannes Berg2-8/+43
Newer devices have 20 (5000 series) or 30 (6000 series) hardware queues, rather than the 16 that 4965 had. This was added to the driver a long time ago, but improperly: the queue registers for the higher queues aren't just continuations of the registers for the first 16 queues, they are in other places. Therefore, the hardware would lock up when trying to activate queue 16 or above and the device would have to be restarted. Thanks goes to Emmanuel who identified this and told me how the queue programming should be done. Note that we don't use queues 20 and higher today and doing so needs more work than this. Cc: [email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Wey-Yi Guy <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2012-04-24Merge tag 'hsi_fixes_for_3.4' of git://gitorious.org/kernel-hsi/kernel-hsiLinus Torvalds2-106/+119
Pull HSI fixes and ABI documentation from Carlos Chinea * tag 'hsi_fixes_for_3.4' of git://gitorious.org/kernel-hsi/kernel-hsi: HSI: Add HSI ABI documentation HSI: hsi_char: Remove max_data_size from sysfs HSI: hsi: Rework hsi_event interface HSI: hsi: Remove controllers and ports from the bus HSI: hsi: Fix error path cleanup on client registration HSI: hsi: Rework hsi_controller release
2012-04-24Add Foxconn / Hon Hai IDs for btusb moduleSteven Harms1-0/+3
This change adds 0x0489:0xe033 to the btusb module. This bluetooth usb device is integrated in the Acer TimelineX AS4830TG-6808 notebook. Output from /sys/kernel/debug/usb/devices: T: Bus=01 Lev=02 Prnt=02 Port=05 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e033 Rev= 2.29 S: Manufacturer=Broadcom Corp S: Product=Acer Module S: SerialNumber=60D819F74101 C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 32 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 32 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 64 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 64 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 64 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 64 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Signed-off-by: Steven Harms <[email protected]> Signed-off-by: Gustavo Padovan <[email protected]>
2012-04-24asix: Fix tx transfer padding for full-speed USBIngo van Lil1-2/+2
The asix.c USB Ethernet driver avoids ending a tx transfer with a zero- length packet by appending a four-byte padding to transfers whose length is a multiple of maxpacket. However, the hard-coded 512 byte maxpacket length is valid for high-speed USB only; full-speed USB uses 64 byte packets. Signed-off-by: Ingo van Lil <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-04-24net/davinci_emac: fix failing PHY connect attemptsAnatolij Gustschin1-1/+1
PHY connect attempts fail if no PHY id is specified in the emac platform data and another mdio bus has been registered before 'davinci_mdio' bus. In this case when configuring the interface, there will be an attempt to connect to already attached PHY on the previously registered mdio bus: net eth1: PHY already attached net eth1: could not connect to phy smsc911x-0:01 IP-Config: Failed to open eth1 IP-Config: Device `eth1' not found Fix this by modifying match_first_device() to match first PHY device on 'davinci_mdio' bus. Signed-off-by: Anatolij Gustschin <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-04-24ehea: only register irq after setting up portsThadeu Lima de Souza Cascardo1-12/+18
If we receive an interrupt too early before we set up ports in the probe function, there won't be any port ready to handle it. Only registering the irq after the ports are setup fixes the problem, and works fine without losing any interrupts. This causes crashes in some situations: [c000000f7ff7fd60] d000000008e223f0 .ehea_neq_tasklet+0x78/0x148 [ehea] [c000000f7ff7fe00] c0000000000b6cac .tasklet_hi_action+0xdc/0x210 [c000000f7ff7fea0] c0000000000b7cc8 .__do_softirq+0x178/0x300 [c000000f7ff7ff90] c000000000022694 .call_do_softirq+0x14/0x24 [c000000f68ee7900] c000000000010e04 .do_softirq+0xec/0x110 [c000000f68ee79a0] c0000000000b789c .irq_exit+0xac/0xe0 [c000000f68ee7a20] c0000000000110bc .do_IRQ+0x114/0x2a8 [c000000f68ee7ae0] c00000000000553c hardware_interrupt_entry+0x18/0x1c Signed-off-by: David S. Miller <[email protected]>
2012-04-24qeth: Use blkt defaults for OSA Express 4Stefan Raspl1-1/+2
The previous blkt defaults for OSA Express 4 cards produced inadequate performance for streaming workloads. The present patch will apply a set of more appropriate defaults. Signed-off-by: Stefan Raspl <[email protected]> Reviewed-by: Ursula Braun <[email protected]> Signed-off-by: Frank Blaschka <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-04-24qeth: allow change of blkt default valuesUrsula Braun1-1/+2
There exist qeth sysfs blkt attributes to change the default blkt values. But blkt changes are reset during online setting due to a 2nd invocation of qeth_determine_capabilites(). This patch makes sure blkt default values are configured during 1st run of qeth_determine_capabilities() only. Thus blkt changes are kept during online setting. Signed-off-by: Ursula Braun <[email protected]> Reported-by: Horst Hartmann <[email protected]> Signed-off-by: Frank Blaschka <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-04-24net: usb: smsc95xx: fix mtuStephane Fillod1-0/+1
Make smsc95xx recalculate the hard_mtu after adjusting the hard_header_len. Without this, usbnet adjusts the MTU down to 1488 bytes, and the host is unable to receive standard 1500-byte frames from the device. Inspired by same fix on cdc_eem 78fb72f7936c01d5b426c03a691eca082b03f2b9. Tested on ARM/Beagle. Signed-off-by: Stephane Fillod <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-04-23Merge tag 'md-3.4-fixes' of git://neil.brown.name/mdLinus Torvalds2-5/+6
Pull a few more md bug fixes from NeilBrown: "2 are tagged for -stable, one being for a fairly serious bug that can corrupt metadata and make it hard to recovery an array. The other is for a more recent regression since 3.3" * tag 'md-3.4-fixes' of git://neil.brown.name/md: md: fix possible corruption of array metadata on shutdown. md: don't call ->add_disk unless there is good reason. DM RAID: Use safe version of rdev_for_each
2012-04-24md: fix possible corruption of array metadata on shutdown.NeilBrown1-1/+2
commit c744a65c1e2d59acc54333ce8 md: don't set md arrays to readonly on shutdown. removed the possibility of a 'BUG' when data is written to an array that has just been switched to read-only, but also introduced the possibility that the array metadata could be corrupted. If, when md_notify_reboot gets the mddev lock, the array is in a state where it is assembled but hasn't been started (as can happen if the personality module is not available, or in other unusual situations), then incorrect metadata will be written out making it impossible to re-assemble the array. So only call __md_stop_writes() if the array has actually been activated. This patch is needed for any stable kernel which has had the above commit applied. Cc: [email protected] Reported-by: Christoph Nelles <[email protected]> Signed-off-by: NeilBrown <[email protected]>
2012-04-24md: don't call ->add_disk unless there is good reason.NeilBrown1-2/+2
Commit 7bfec5f35c68121e7b18 md/raid5: If there is a spare and a want_replacement device, start replacement. cause md_check_recovery to call ->add_disk much more often. Instead of only when the array is degraded, it is now called whenever md_check_recovery finds anything useful to do, which includes updating the metadata for clean<->dirty transition. This causes unnecessary work, and causes info messages from ->add_disk to be reported much too often. So refine md_check_recovery to only do any actual recovery checking (including ->add_disk) if MD_RECOVERY_NEEDED is set. This fix is suitable for 3.3.y: Cc: [email protected] Reported-by: Jan Ceuleers <[email protected]> Signed-off-by: NeilBrown <[email protected]>
2012-04-24DM RAID: Use safe version of rdev_for_eachJonathan Brassow1-2/+2
Fix segfault caused by using rdev_for_each instead of rdev_for_each_safe Commit dafb20fa34320a472deb7442f25a0c086e0feb33 mistakenly replaced a safe iterator with an unsafe one when making some macro changes. Signed-off-by: Jonathan Brassow <[email protected]> Signed-off-by: NeilBrown <[email protected]>
2012-04-23drm/i915: fix integer overflow in i915_gem_do_execbuffer()Xi Wang1-0/+5
On 32-bit systems, a large args->num_cliprects from userspace via ioctl may overflow the allocation size, leading to out-of-bounds access. This vulnerability was introduced in commit 432e58ed ("drm/i915: Avoid allocation for execbuffer object list"). Signed-off-by: Xi Wang <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]>
2012-04-23drm/i915: fix integer overflow in i915_gem_execbuffer2()Xi Wang1-1/+2
On 32-bit systems, a large args->buffer_count from userspace via ioctl may overflow the allocation size, leading to out-of-bounds access. This vulnerability was introduced in commit 8408c282 ("drm/i915: First try a normal large kmalloc for the temporary exec buffers"). Signed-off-by: Xi Wang <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]>
2012-04-23ACPI: Convert wake_sleep_flags to a value instead of functionKonrad Rzeszutek Wilk1-24/+28
With commit a2ef5c4fd44ce3922435139393b89f2cce47f576 "ACPI: Move module parameter gts and bfs to sleep.c" the wake_sleep_flags is required when calling acpi_enter_sleep_state, which means that if there are functions outside the sleep.c code they can't get the wake_sleep_flags values. This converts the function in to a exported value and converts the module config operands to a function. Acked-by: Rafael J. Wysocki <[email protected]> Acked-by: Lin Ming <[email protected]> [v2: Parameters can be turned on/off dynamically] [v3: unsigned char -> u8] [v4: val -> kp->arg] Signed-off-by: Konrad Rzeszutek Wilk <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: H. Peter Anvin <[email protected]>
2012-04-23brcmsmac: "INTERMEDIATE but not AMPDU" only when tracingEldad Zack1-2/+1
I keep getting the following messages on the log buffer: [ 2167.097507] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2281.331305] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2281.332539] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2329.876605] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2329.877354] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2462.280756] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2615.651689] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU From the code comment I understand that this something that can - and does, quite frequently - happen. Signed-off-by: Eldad Zack <[email protected]> Acked-by: Franky Lin<[email protected]> Signed-off-by: John W. Linville <[email protected]>
2012-04-23rtlwifi: Fix oops on unloadLarry Finger1-0/+1
Under some circumstances, a PCI-based driver reports the following OOPs: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Oops: 0000 [#1] SMP --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Pid: 19627, comm: rmmod Not tainted 3.2.9-2.fc16.x86_64 #1 LENOVO 05962RU/05962RU Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP: 0010:[<ffffffffa0418d39>] [<ffffffffa0418d39>] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce] --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Process rmmod (pid: 19627, threadinfo ffff880050262000, task ffff8801156d5cc0) Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Stack: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] 0000000000000002 ffff8801176c2540 ffff880050263ca8 ffffffffa03348e7 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] 0000000000000282 0000000180150014 ffff880050263fd8 ffff8801176c2810 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] ffff880050263bc8 ffffffff810550e2 00000000000002c0 ffff8801176c0d40 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Call Trace: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] [<ffffffffa03348e7>] _rtl_pci_rx_interrupt+0x187/0x650 [rtlwifi] --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Code: ff 09 d0 89 07 48 83 c4 08 5b 5d c3 66 0f 1f 44 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 40 84 f6 89 d3 74 13 84 d2 75 57 <8b> 07 48 83 c4 08 5b 5d c1 e8 1f c3 0f 1f 00 84 d2 74 ed 80 fa Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP [<ffffffffa0418d39>] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce] Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RSP <ffff880050263b58> Mar 19 08:14:35 kvothe kernel: [ 6584.626011] CR2: 00000000000006e0 Mar 19 08:14:35 kvothe kernel: [ 6584.646491] ---[ end trace 8636c766dcfbe0e6 ]--- This oops is due to interrupts not being disabled in this particular path. Reported-by: Dave Airlie <[email protected]> Tested-by: Dave Airlie <[email protected]> Signed-off-by: Larry Finger <[email protected]> Cc: Stable <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2012-04-23ipw2200: Fix race condition in the command completion acknowledgeStanislav Yakovlev1-1/+12
Driver incorrectly validates command completion: instead of waiting for a command to be acknowledged it continues execution. Most of the time driver gets acknowledge of the command completion in a tasklet before it executes the next one. But sometimes it sends the next command before it gets acknowledge for the previous one. In such a case one of the following error messages appear in the log: Failed to send SYSTEM_CONFIG: Already sending a command. Failed to send ASSOCIATE: Already sending a command. Failed to send TX_POWER: Already sending a command. After that you need to reload the driver to get it working again. This bug occurs during roaming (reported by Sam Varshavchik) https://bugzilla.redhat.com/show_bug.cgi?id=738508 and machine booting (reported by Tom Gundersen and Mads Kiilerich) https://bugs.archlinux.org/task/28097 https://bugzilla.redhat.com/show_bug.cgi?id=802106 This patch doesn't fix the delay issue during firmware load. But at least device now works as usual after boot. Cc: [email protected] Signed-off-by: Stanislav Yakovlev <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2012-04-23iwlwifi: do not nulify ctx->vif on resetStanislaw Gruszka2-4/+9
ctx->vif is dereferenced in different part of iwlwifi code, so do not nullify it. This should address at least one of the possible reasons of WARNING at iwlagn_mac_remove_interface, and perhaps some random crashes when firmware reset is performed. Cc: [email protected] Signed-off-by: Stanislaw Gruszka <[email protected]> Signed-off-by: Wey-Yi Guy <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2012-04-23ath9k: fix tx power settings for AR9287Gabor Juhos1-0/+2
The 'ath9k_hw_update_regulatory_maxpower' helper function has been introduced by commit a55f858852e4345d0a31af593c46738ca8614bff (ath9k_hw: Cleanup TX power calculation for AR9287). Updating of the max_power_level value has been moved into the helper function in that change, however the removed code from 'ath9k_hw_ar9287_set_txpower' has not been replaced with a call of the new helper function. Due to that missing call, retrieving tx power for 2x2 and 3x3 chainmask is not handled properly. During the calculation of the tx power for 2x2 and 3x3 chainmasks the values are reduced. Those reductions must be compensated during retrieving. Fix this by adding the missing call of the helper function. Signed-off-by: Gabor Juhos <[email protected]> Acked-by: Sujith Manoharan <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2012-04-23ath9k: add an extra boolean parameter to ath9k_hw_apply_txpowerGabor Juhos5-8/+10
In order to unifying regulatory limit handling commit ca2c68cc7bc80fc4504fb420df04cce99c9ee6ec (ath9k_hw: clean up tx power handling) introduced a new helper function 'ath9k_hw_apply_txpower', and the direct calls of 'ah->eep_ops->set_txpower' has been replaced by a call of the helper function. This caused a change in the behaviour of the 'ath9k_hw_set_txpowerlimit' function. The purpose of that function is to calculate and store the rate txpower table and the regulatory limit without touching the hardware registers. Before the commit, the 'test' parameter of the function was passed to the 'ah->eep_ops->set_txpower'. Now the calling of the 'set_txpower' function happens indirectly through 'ath9k_hw_apply_txpower', so the 'test' argument of the 'set_txpower' is always 'false'. This patch restores the original behaviour of 'ath9k_hw_set_txpowerlimit' by adding a new argument to 'ath9k_hw_apply_txpower.' Signed-off-by: Gabor Juhos <[email protected]> Acked-by: Felix Fietkau <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2012-04-23dma/ste_dma40: fix erroneous comparisonLinus Walleij1-1/+1
A small fallout from Vinod's conversions to dma_transfer_direction, this small comparison was done with a dma_data_direction instead. Fix it by comparing against the correct enum. Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2012-04-23dma/ste_dma40: explicitly include regulator consumer headerLinus Walleij1-0/+1
The patch "ARM: amba: Remove AMBA level regulator support" breaks the DMA40 driver since the <linux/amba/bus.h> header implicitly included the regulator consumer header. So include it explicitly and fix the build error. Cc: Mark Brown <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2012-04-23dma40: Improve the logic of stopping logical chanNarayanan G2-123/+199
can be directly stopped by issuing a SUSPEND_REQ on the EE bits. There is no need to suspend the physical channel and restart it. Also, the support for pre-V2 hw is discontinued. EE bits for writing: 00: disable only if AS=11 or AS=00 01: enable 10: suspend_req only if AS=01 & EE=01 or EE=11 11: round / no change for writing Signed-off-by: Narayanan G <[email protected]> Acked-by: Linus Walleij <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2012-04-23drm/exynos: added missed vm area region mapping type.Inki Dae1-0/+2
with this patch, if the memory region is physically non-continuous then VM_MIXEDMAP is set to vm->vm_flags otherwise VM_PFNMAP. we had missed this flag setting. Signed-off-by: Inki Dae <[email protected]> Signed-off-by: Kyungmin Park <[email protected]>
2012-04-23drm/exynos: fixed exynos_drm_gem_map_pages bug.Inki Dae1-13/+3
this patch fixes the problem that the physical memory region to be mapped to user space could be exceeded. if page fault address was placed at between buffer start and end then memory region to be mapped would be exceeded. Signed-off-by: Inki Dae <[email protected]> Signed-off-by: Kyungmin Park <[email protected]>
2012-04-23drm/exynos: fixed duplicatd memory allocation bug.Inki Dae1-12/+0
the gem was already allocated at gem allocation time but is allocated at page fault handler so this patch fixes the problem that gem was allocated one more time. Signed-off-by: Inki Dae <[email protected]> Signed-off-by: Kyungmin Park <[email protected]>
2012-04-23HSI: hsi_char: Remove max_data_size from sysfsCarlos Chinea1-1/+1
Remove max_data_size sysfs entry. Otherwise is possible to have a buffer overrun if its value is increased after the device is open. Signed-off-by: Carlos Chinea <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Acked-by: Linus Walleij <[email protected]>
2012-04-23HSI: hsi: Rework hsi_event interfaceCarlos Chinea1-47/+54
Remove custom hack and make use of the notifier chain interfaces for delivering events from the ports to their associated clients. Clients that want to receive port events need to register their callbacks using hsi_register_port_event(). The callbacks can be called in interrupt context. Use hsi_unregestier_port_event() to undo the registration. Signed-off-by: Carlos Chinea <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Acked-by: Linus Walleij <[email protected]>
2012-04-23HSI: hsi: Remove controllers and ports from the busCarlos Chinea1-19/+1
HSI controllers and ports do not belong to the HSI bus. Those devices are not supposed to have a driver attached to them. Signed-off-by: Carlos Chinea <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Acked-by: Linus Walleij <[email protected]>
2012-04-23HSI: hsi: Fix error path cleanup on client registrationCarlos Chinea1-1/+1
HSI client structure should be freed on error path after calling device_registration by dropping a reference to it. Signed-off-by: Carlos Chinea <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Acked-by: Linus Walleij <[email protected]>
2012-04-23HSI: hsi: Rework hsi_controller releaseCarlos Chinea1-42/+66
Use the proper release mechanism for hsi_controller and hsi_ports structures. Free the structures through their associated device release callbacks. Signed-off-by: Carlos Chinea <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Acked-by: Linus Walleij <[email protected]>
2012-04-23[SCSI] Revert "[SCSI] libsas: fix sas port naming"Dan Williams1-1/+1
This reverts commit a692b0eec5efae382dfa800e8b4b083f172921a7. Tom reports: [ 8.741033] ------------[ cut here ]------------ [ 8.741038] WARNING: at fs/sysfs/dir.c:508 sysfs_add_one+0xc1/0xf0() [ 8.741040] Hardware name: To Be Filled By O.E.M. [ 8.741041] sysfs: cannot create duplicate filename ...and missing 2 out of 4 drives connected to mvsas. Commit a692b0ee made the assumption that all the phy ids an lldd registers to libsas are unique. However, in the "multi-chip" case mvsas does a rather annoying duplication of phy ids in the array passed to libsas. So, for example, chip0 has phy0-3 at ha phy index 0-3 and chip1 has its phy0-3 at ha phy index 4-7. The more natural model would be to create a scsi_host (and sas_ha) per chip (controller), but for now revert the naming fix which unfortunately means dealing with unpredictable end-device names for a bit longer. Cc: Xiangliang Yu <[email protected]> Cc: Patrick Thomson <[email protected]> Reported-by: Tom Rini <[email protected]> Tested-by: Tom Rini <[email protected]> Signed-off-by: Dan Williams <[email protected]> Signed-off-by: James Bottomley <[email protected]>
2012-04-23[SCSI] libsas: fix false positive 'device attached' conditionsDan Williams1-1/+8
Normalize phy->attached_sas_addr to return a zero-address in the case when device-type == NO_DEVICE or the linkrate is invalid to handle expanders that put non-zero sas addresses in the discovery response: sas: ex 5001b4da000f903f phy02:U:0 attached: 0100000000000000 (no device) sas: ex 5001b4da000f903f phy01:U:0 attached: 0100000000000000 (no device) sas: ex 5001b4da000f903f phy03:U:0 attached: 0100000000000000 (no device) sas: ex 5001b4da000f903f phy00:U:0 attached: 0100000000000000 (no device) Reported-by: Andrzej Jakowski <[email protected]> Signed-off-by: Dan Williams <[email protected]> Cc: [email protected] Signed-off-by: James Bottomley <[email protected]>
2012-04-23[SCSI] libsas, libata: fix start of life for a sas ata_portDan Williams5-45/+50
This changes the ordering of initialization and probing events from: 1/ allocate rphy in PORTE_BYTES_DMAED, DISCE_REVALIDATE_DOMAIN 2/ allocate ata_port and schedule port probe in DISCE_PROBE ...to: 1/ allocate ata_port in PORTE_BYTES_DMAED, DISCE_REVALIDATE_DOMAIN 2/ allocate rphy in PORTE_BYTES_DMAED, DISCE_REVALIDATE_DOMAIN 3/ schedule port probe in DISCE_PROBE This ordering prevents PHYE_SIGNAL_LOSS_EVENTS from sneaking in to destrory ata devices before they have been fully initialized: BUG: unable to handle kernel paging request at 0000000000003b10 IP: [<ffffffffa0053d7e>] sas_ata_end_eh+0x12/0x5e [libsas] ... [<ffffffffa004d1af>] sas_unregister_common_dev+0x78/0xc9 [libsas] [<ffffffffa004d4d4>] sas_unregister_dev+0x4f/0xad [libsas] [<ffffffffa004d5b1>] sas_unregister_domain_devices+0x7f/0xbf [libsas] [<ffffffffa004c487>] sas_deform_port+0x61/0x1b8 [libsas] [<ffffffffa004bed0>] sas_phye_loss_of_signal+0x29/0x2b [libsas] ...and kills the awkward "sata domain_device briefly existing in the domain without an ata_port" state. Reported-by: Michal Kosciowski <[email protected]> Signed-off-by: Dan Williams <[email protected]> Acked-by: Jeff Garzik <[email protected]> Signed-off-by: James Bottomley <[email protected]>
2012-04-23[SCSI] libsas: fix ata_eh clobbering ex_phys via smp_ata_check_readyDan Williams1-1/+15
The check_ready implementation in the expander-attached ata device case polls on sas_ex_phy_discover(). The effect is that the ex_phy fields (critically ->attached_sas_addr) can change. When ata_eh ends and libsas comes along to revalidate the domain sas_unregister_devs_sas_addr() can fail to lookup devices to remove, or fail to re-add an ata device that ata_eh marked as disabled. So change the code to skip the sas_address and change count updates when ata_eh is active. Cc: Jack Wang <[email protected]> Tested-by: Maciej Patelczyk <[email protected]> Tested-by: Bartek Nowakowski <[email protected]> Tested-by: Jacek Danecki <[email protected]> Signed-off-by: Dan Williams <[email protected]> Signed-off-by: James Bottomley <[email protected]>
2012-04-23[SCSI] libsas: unify domain_device sas_rphy lifetimesDan Williams2-7/+10
Since the domain_device can out live the scsi_target we need the rphy to follow suit otherwise we run into issues like: BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 IP: [<ffffffffa011561b>] sas_ata_printk+0x43/0x6f [libsas] PGD 0 Oops: 0000 [#1] SMP CPU 1 Modules linked in: ses enclosure isci libsas scsi_transport_sas fuse sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf microcode pcspkr igb joydev iTCO_wdt ioatdma iTCO_vendor_support i2c_i801 i2c_core dca wmi hed ipv6 pata_acpi ata_generic [last unloaded: scsi_wait_scan] Pid: 129, comm: kworker/u:3 Not tainted 3.3.0-rc5-isci+ #1 Intel Corporation SandyBridge Platform/To be filled by O.E.M. RIP: 0010:[<ffffffffa011561b>] [<ffffffffa011561b>] sas_ata_printk+0x43/0x6f [libsas] RSP: 0018:ffff88042232dd70 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8804283165b8 RCX: ffff88042232dda0 RDX: ffff88042232dd78 RSI: ffff8804283165b8 RDI: ffffffffa01188d7 RBP: ffff88042232ddd0 R08: ffff880388454000 R09: ffff8803edfde1f8 R10: ffff8803edfde1f8 R11: ffff8803edfde1f8 R12: ffff880428316750 R13: ffff880388454000 R14: ffff8803f88b31d0 R15: ffff8803f8b21d50 FS: 0000000000000000(0000) GS:ffff88042ee20000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000050 CR3: 0000000001a05000 CR4: 00000000000406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process kworker/u:3 (pid: 129, threadinfo ffff88042232c000, task ffff88042230c920) Stack: 0000000000000000 ffff880400000018 ffff88042232dde0 ffff88042232dda0 ffffffffa01188c4 ffff88042ee93af0 ffff88042232ddb0 ffffffff8100e047 ffff88042232de10 ffff880420e5a2c8 ffff8803f8b21d50 ffff8803edfde1f8 Call Trace: [<ffffffff8100e047>] ? load_TLS+0xb/0xf [<ffffffffa01156ad>] async_sas_ata_eh+0x66/0x95 [libsas] [<ffffffff810655e1>] async_run_entry_fn+0x9e/0x131 Reported-by: Tom Jackson <[email protected]> Tested-by: Tom Jackson <[email protected]> Signed-off-by: Dan Williams <[email protected]> Signed-off-by: James Bottomley <[email protected]>
2012-04-23[SCSI] libsas: fix sas_get_port_device regressionDan Williams1-4/+5
Commit 899fcf4 "[SCSI] libsas: set attached device type and target protocols for local phys" setup 'phy' to be dereferenced after list_for_each_entry(phy, &port->phy_list, port_phy_el) (i.e. phy == &port->phy_list) resulting in reports like: BUG: unable to handle kernel NULL pointer dereference at 00000000000002b0 IP: [<ffffffffa00ce948>] sas_discover_domain+0x29e/0x4fb [libsas] ...fix by deferring sas_phy_set_target() to the end of sas_get_port_device(). Reported-by: Tom Jackson <[email protected]> Tested-by: Tom Jackson <[email protected]> Signed-off-by: Dan Williams <[email protected]> Signed-off-by: James Bottomley <[email protected]>
2012-04-23[SCSI] libsas: fix sas_find_bcast_phy() in the presence of 'vacant' physThomas Jackson1-5/+12
If an expander reports 'PHY VACANT' for a phy index prior to the one that generated a BCN libsas fails rediscovery. Since a vacant phy is defined as a valid phy index that will never have an attached device just continue the search. Cc: <[email protected]> Signed-off-by: Thomas Jackson <[email protected]> Signed-off-by: Dan Williams <[email protected]> Signed-off-by: James Bottomley <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.