usb: gadget: zero: Fix SuperSpeed enumeration for alternate setting 1

It was impossible to enumerate on a SuperSpeed (XHCI) host
with alternate setting = 1 due to the wrongly set 'bMaxBurst'
field in the SuperSpeed Endpoint Companion descriptor.

Testcase:
<host> modprobe -r usbtest; modprobe usbtest alt=1
<device> modprobe g_zero
plug device to SuperSpeed port on the host.

Without this patch the host always complains like so
"usb 12-2: Not enough bandwidth for new device state.
 usb 12-2: Not enough bandwidth for altsetting 1"

Bug was introduced by commit cf9a08ae in v3.9

Fixes: cf9a08ae5aec (usb: gadget: convert source sink and loopback to
new function interface)

Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
Reviewed-by: Felipe Balbi <balbi@ti.com>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
usb: dwc3: core: Fix gadget for system suspend/resume

During system resume, if the event buffers are not setup before
the gadget controller starts then we start with invalid context
and this can lead to bus access errors. This is especially true for
platforms that loose the controller context during system suspend.
e.g. AM437x.

The following backtrace was found when the system is suspended
and resumed with g_zero loaded on AM437x-evm (USB cable connected
to host all the while).

[  120.981506] WARNING: CPU: 0 PID: 1656 at drivers/bus/omap_l3_noc.c:137 l3_interrupt_handler+0x198/0x28c()
[  120.981514] L3 custom error: MASTER:USB0 WR TARGET:GPMC
[  120.981638] Modules linked in: g_mass_storage usb_f_mass_storage libcomposite configfs bufferclass_ti(O) omaplfb(O) cryptodev(O) dwc3 snd_soc_evm snd_soc_omap snd_pe
[  120.981659] CPU: 0 PID: 1656 Comm: sh Tainted: G           O 3.12.10-gc559824 #1
[  120.981669] Backtrace:
[  120.981705] [<c0017880>] (dump_backtrace+0x0/0x10c) from [<c0017a1c>] (show_stack+0x18/0x1c)
[  120.981730]  r6:c02819ac r5:00000009 r4:ec137cb8 r3:00000000
[  120.981767] [<c0017a04>] (show_stack+0x0/0x1c) from [<c056c0b0>] (dump_stack+0x20/0x28)
[  120.981802] [<c056c090>] (dump_stack+0x0/0x28) from [<c0046d08>] (warn_slowpath_common+0x70/0x90)
[  120.981830] [<c0046c98>] (warn_slowpath_common+0x0/0x90) from [<c0046dcc>] (warn_slowpath_fmt+0x38/0x40)
[  120.981856]  r8:c0855eb0 r7:00000002 r6:f1000700 r5:00000007 r4:80080003
[  120.981886] [<c0046d94>] (warn_slowpath_fmt+0x0/0x40) from [<c02819ac>] (l3_interrupt_handler+0x198/0x28c)
[  120.981900]  r3:c0801ab8 r2:c06cb354
[  120.981936] [<c0281814>] (l3_interrupt_handler+0x0/0x28c) from [<c007162c>] (handle_irq_event_percpu+0x54/0x1b8)
[  120.981962] [<c00715d8>] (handle_irq_event_percpu+0x0/0x1b8) from [<c00717c0>] (handle_irq_event+0x30/0x40)
[  120.981993] [<c0071790>] (handle_irq_event+0x0/0x40) from [<c0074058>] (handle_fasteoi_irq+0x74/0x128)
[  120.982006]  r4:ed0056c0 r3:00000000
[  120.982033] [<c0073fe4>] (handle_fasteoi_irq+0x0/0x128) from [<c0070f34>] (generic_handle_irq+0x28/0x38)
[  120.982046]  r4:0000002a r3:c0073fe4
[  120.982085] [<c0070f0c>] (generic_handle_irq+0x0/0x38) from [<c0015560>] (handle_IRQ+0x38/0x8c)
[  120.982098]  r4:c080137c r3:00000182
[  120.982124] [<c0015528>] (handle_IRQ+0x0/0x8c) from [<c00087e0>] (gic_handle_irq+0x30/0x5c)
[  120.982145]  r6:ec137dd0 r5:c07ac480 r4:fa24010c r3:00000100
[  120.982169] [<c00087b0>] (gic_handle_irq+0x0/0x5c) from [<c056fcc0>] (__irq_svc+0x40/0x54)
[  120.982179] Exception stack(0xec137dd0 to 0xec137e18)
[  120.982195] 7dc0:                                     00000000 a00001d3 00000000 00000004
[  120.982216] 7de0: a0000153 ec1d9010 c080de90 ec137e30 c080debc 00000000 ed756e44 ec137e2c
[  120.982232] 7e00: ec137de0 ec137e18 bf1150e4 bf115474 60000153 ffffffff
[  120.982253]  r7:ec137e04 r6:ffffffff r5:60000153 r4:bf115474
[  120.982327] [<bf115438>] (dwc3_complete+0x0/0x40 [dwc3]) from [<c0338f50>] (dpm_complete+0xd4/0x19c)
[  120.982341]  r5:ed756e10 r4:ed756e64
[  120.982370] [<c0338e7c>] (dpm_complete+0x0/0x19c) from [<c0339034>] (dpm_resume_end+0x1c/0x20)
[  120.982400] [<c0339018>] (dpm_resume_end+0x0/0x20) from [<c006d4ec>] (suspend_devices_and_enter+0x118/0x33c)
[  120.982412]  r4:c0833da4 r3:00000000
[  120.982436] [<c006d3d4>] (suspend_devices_and_enter+0x0/0x33c) from [<c006d928>] (pm_suspend+0x218/0x254)
[  120.982458] [<c006d710>] (pm_suspend+0x0/0x254) from [<c006c594>] (state_store+0x70/0xc0)
[  120.982478]  r6:c057a6cc r5:c06a8320 r4:00000003 r3:0000006d
[  120.982515] [<c006c524>] (state_store+0x0/0xc0) from [<c0264cc0>] (kobj_attr_store+0x1c/0x28)
[  120.982546] [<c0264ca4>] (kobj_attr_store+0x0/0x28) from [<c012ccb8>] (sysfs_write_file+0x170/0x1a4)
[  120.982583] [<c012cb48>] (sysfs_write_file+0x0/0x1a4) from [<c00d17e4>] (vfs_write+0xb8/0x190)
[  120.982611] [<c00d172c>] (vfs_write+0x0/0x190) from [<c00d1bf8>] (SyS_write+0x44/0x78)
[  120.982641] [<c00d1bb4>] (SyS_write+0x0/0x78) from [<c0014660>] (ret_fast_syscall+0x0/0x30)

Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
usb: gadget: gadgetfs: Initialize CHIP to NULL before UDC probe

Otherwise the value from the last probe would be retained that possibly is
freed since (the UDC is removed) and therefore no longer relevant. Reproducible
with the dummy UDC:

  modprobe dummy_hcd
  mount -t gadgetfs gadgetfs /dev/gadget
  umount /dev/gadget
  rmmod dummy_hcd
  mount -t gadgetfs gadgetfs /dev/gadget

BUG: unable to handle kernel paging request at ffffffffa066fd9d
Call Trace:
 [<ffffffff811d0cd2>] ? d_alloc_name+0x22/0x50
 [<ffffffff812b74dc>] ? selinux_d_instantiate+0x1c/0x20
 [<ffffffffa067d687>] gadgetfs_create_file+0x27/0xa0 [gadgetfs]
 [<ffffffffa067da70>] ? setup_req.isra.4+0x80/0x80 [gadgetfs]
 [<ffffffffa067dbac>] gadgetfs_fill_super+0x13c/0x180 [gadgetfs]
 [<ffffffff811bc832>] mount_single+0x92/0xc0
 [<ffffffffa067d0f8>] gadgetfs_mount+0x18/0x20 [gadgetfs]
 [<ffffffff811bc8f9>] mount_fs+0x39/0x1b0
 [<ffffffff8116b220>] ? __alloc_percpu+0x10/0x20
 [<ffffffff811d6da3>] vfs_kern_mount+0x63/0xf0
 [<ffffffff811d93be>] do_mount+0x23e/0xac0
 [<ffffffff811660eb>] ? strndup_user+0x4b/0xf0
 [<ffffffff811d9f63>] SyS_mount+0x83/0xc0
 [<ffffffff81695b69>] system_call_fastpath+0x16/0x1b

Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Felipe Balbi <balbi@ti.com>
usb: musb: dsps: move debugfs_remove_recursive()

When the platform initialization fails due to missing resources, it will
return -EPROBE_DEFER after dsps_musb_init() has been called.

dsps_musb_init() calls dsps_musb_dbg_init() to allocate the debugfs
nodes. At a later point in time, the probe will be retried, and
dsps_musb_dbg_init() will be called again. debugfs_create_dir() will
fail this time, as the node already exists, and so the entire device
probe will fail with -ENOMEM.

Fix this by moving debugfs_remove_recursive() from dsps_remove() to the
plaform's exit function, so it will be cleanly torn down when the probe
fails. It also feels more natural this way, as .exit is the counterpart
to .init.

Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
usb : gadget : fsl: fix the fault issue on rmmod

completion in udc_controller->done should be assign with proper
value before complete called. The complete called in fsl_udc_release
which intern called from usb_del_gadget_udc, so moving assignment
before calling usb_del_gadget_udc

Signed-off-by: Suresh Gupta <suresh.gupta@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
usb: gadget: rndis: Include "u_rndis.h"

Include "u_rndis.h" in order to fix the following sparse warning:

drivers/usb/gadget/rndis.c:1144:5: warning: symbol 'rndis_init' was not declared. Should it be static?
drivers/usb/gadget/rndis.c:1177:6: warning: symbol 'rndis_exit' was not declared. Should it be static?

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
usb: phy: return an error in usb_get_phy() if try_module_get() fails

In case we found a matching USB PHY in usb_get_phy() but the call to
try_module_get() fails, we shouldn't return a (probably soon dangling)
pointer but an ERR_PTR instead.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
usb: gadget: ffs: race between ffs_epfile_io() and ffs_func_eps_disable()

ffs_epfile_io() is called from userspace, while ffs_func_eps_disable() might be
called from USB disconnect interrupt, the two functions would run in parallel
but they are not well protected, that epfile->ep would be removed by
ffs_func_eps_disable() during ffs_epfile_io() is referring this pointer, then
it leads to kernel PANIC.

The scenario is as below:

Thread 1                                 Thread 2
   |                                        |
SyS_read                             dwc3_gadget_disconnect_interrupt
   |                                        |
ffs_epfile_read                         reset_config
   |                                        |
ffs_epfile_io                       ffs_func_eps_disable
   |                                        |
 -----                      usb_ep_disable():  epfile->ep->ep->desc = NULL
   |                                        |
usb_ep_align_maybe():                     -----
it refers ep->desc->wMaxPacketSize        -----

Signed-off-by: Chao Bi <chao.bi@intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
PCI: designware: Fix comment for setting number of lanes

Corrects comment for setting number of lanes.

Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
PCI: designware: Fix iATU programming for cfg1, io and mem viewport

This patch corrects iATU programming for cfg1, io and mem viewport.  Enable
ATU only after configuring it.

Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
Signed-off-by: Ajay Khandelwal <ajay.khandelwal@st.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Cc: stable@vger.kernel.org
PCI: designware: Use new OF interrupt mapping when possible

Use new OF interrupt mapping (of_irq_parse_and_map_pci()) when possible.
This is the recommended method of doing the IRQ mapping.  For old
devicetrees we fall back to the previous practice.

This makes INTB, INTC, and INTD work on i.MX.

Tested-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jingoo Han <jg1.han@samsung.com>
PCI: rcar: Use new OF interrupt mapping when possible

Use new OF interrupt mapping (of_irq_parse_and_map_pci()) when possible.
This is the recommended method of doing the IRQ mapping.  For old
devicetrees we fall back to the previous practice.

This allows interrupts to be remapped across bridges.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
PCI: tegra: Use new OF interrupt mapping when possible

Use new OF interrupt mapping (of_irq_parse_and_map_pci()) when possible.
This is the recommended method of doing the IRQ mapping.  For old
devicetrees we fall back to the previous practice.

This allows interrupts to be remapped across bridges.

Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
ahci: do not request irq for dummy port

System may crash in ahci_hw_interrupt() or ahci_thread_fn() when
accessing the interrupt status in a port's private_data if the port is
actually a DUMMY port.

00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller

<snip console output for linux-3.15-rc1>
[    9.352080] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x1 impl SATA mode
[    9.352084] ahci 0000:00:1f.2: flags: 64bit ncq sntf pm led clo pio slum part ccc
[    9.368155] Console: switching to colour frame buffer device 128x48
[    9.439759] mgag200 0000:11:00.0: fb0: mgadrmfb frame buffer device
[    9.446765] mgag200 0000:11:00.0: registered panic notifier
[    9.470166] scsi1 : ahci
[    9.479166] scsi2 : ahci
[    9.488172] scsi3 : ahci
[    9.497174] scsi4 : ahci
[    9.506175] scsi5 : ahci
[    9.515174] scsi6 : ahci
[    9.518181] ata1: SATA max UDMA/133 abar m2048@0x95c00000 port 0x95c00100 irq 91
[    9.526448] ata2: DUMMY
[    9.529182] ata3: DUMMY
[    9.531916] ata4: DUMMY
[    9.534650] ata5: DUMMY
[    9.537382] ata6: DUMMY
[    9.576196] [drm] Initialized mgag200 1.0.0 20110418 for 0000:11:00.0 on minor 0
[    9.845257] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    9.865161] ata1.00: ATAPI: Optiarc DVD RW AD-7580S, FX04, max UDMA/100
[    9.891407] ata1.00: configured for UDMA/100
[    9.900525] scsi 1:0:0:0: CD-ROM            Optiarc  DVD RW AD-7580S  FX04 PQ: 0 ANSI: 5
[   10.247399] iTCO_vendor_support: vendor-support=0
[   10.261572] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[   10.269764] iTCO_wdt: unable to reset NO_REBOOT flag, device disabled by hardware/BIOS
[   10.301932] sd 0:2:0:0: [sda] 570310656 512-byte logical blocks: (291 GB/271 GiB)
[   10.317085] sd 0:2:0:0: [sda] Write Protect is off
[   10.328326] sd 0:2:0:0: [sda] Write cache: disabled, read cache: disabled, supports DPO and FUA
[   10.375452] BUG: unable to handle kernel NULL pointer dereference at 000000000000003c
[   10.384217] IP: [<ffffffffa0133df0>] ahci_hw_interrupt+0x100/0x130 [libahci]
[   10.392101] PGD 0
[   10.394353] Oops: 0000 [#1] SMP
[   10.397978] Modules linked in: sr_mod(+) cdrom sd_mod iTCO_wdt crc_t10dif iTCO_vendor_support crct10dif_common ahci libahci libata lpc_ich mfd_core mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ttm drm i2c_core megaraid_sas dm_mirror dm_region_hash
dm_log dm_mod
[   10.426499] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.0-rc1 #1
[   10.433495] Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.S013.032920111005 03/29/2011
[   10.443886] task: ffffffff81906460 ti: ffffffff818f0000 task.ti: ffffffff818f0000
[   10.452239] RIP: 0010:[<ffffffffa0133df0>]  [<ffffffffa0133df0>] ahci_hw_interrupt+0x100/0x130 [libahci]
[   10.462838] RSP: 0018:ffff880033c03d98  EFLAGS: 00010046
[   10.468767] RAX: 0000000000a400a4 RBX: ffff880029a6bc18 RCX: 00000000fffffffa
[   10.476731] RDX: 00000000000000a4 RSI: ffff880029bb0000 RDI: ffff880029a6bc18
[   10.484696] RBP: ffff880033c03dc8 R08: 0000000000000000 R09: ffff88002f800490
[   10.492661] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000000
[   10.500625] R13: ffff880029a6bd98 R14: 0000000000000000 R15: ffffc90000194000
[   10.508590] FS:  0000000000000000(0000) GS:ffff880033c00000(0000) knlGS:0000000000000000
[   10.517623] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   10.524035] CR2: 000000000000003c CR3: 00000000328ff000 CR4: 00000000000007b0
[   10.531999] Stack:
[   10.534241]  0000000000000017 ffff880031ba7d00 000000000000005c ffff880031ba7d00
[   10.542535]  0000000000000000 000000000000005c ffff880033c03e10 ffffffff810c2a1e
[   10.550827]  ffff880031ae2900 000000008108fb4f ffff880031ae2900 ffff880031ae2984
[   10.559121] Call Trace:
[   10.561849]  <IRQ>
[   10.563994]  [<ffffffff810c2a1e>] handle_irq_event_percpu+0x3e/0x1a0
[   10.571309]  [<ffffffff810c2bbd>] handle_irq_event+0x3d/0x60
[   10.577631]  [<ffffffff810c4fdd>] try_one_irq.isra.6+0x8d/0xf0
[   10.584142]  [<ffffffff810c5313>] note_interrupt+0x173/0x1f0
[   10.590460]  [<ffffffff810c2a8e>] handle_irq_event_percpu+0xae/0x1a0
[   10.597554]  [<ffffffff810c2bbd>] handle_irq_event+0x3d/0x60
[   10.603872]  [<ffffffff810c5727>] handle_edge_irq+0x77/0x130
[   10.610199]  [<ffffffff81014b8f>] handle_irq+0xbf/0x150
[   10.616040]  [<ffffffff8109ff4e>] ? vtime_account_idle+0xe/0x50
[   10.622654]  [<ffffffff815fca1a>] ? atomic_notifier_call_chain+0x1a/0x20
[   10.630140]  [<ffffffff816038cf>] do_IRQ+0x4f/0xf0
[   10.635490]  [<ffffffff815f8aed>] common_interrupt+0x6d/0x6d
[   10.641805]  <EOI>
[   10.643950]  [<ffffffff8149ca9f>] ? cpuidle_enter_state+0x4f/0xc0
[   10.650972]  [<ffffffff8149ca98>] ? cpuidle_enter_state+0x48/0xc0
[   10.657775]  [<ffffffff8149cb47>] cpuidle_enter+0x17/0x20
[   10.663807]  [<ffffffff810b0070>] cpu_startup_entry+0x2c0/0x3d0
[   10.670423]  [<ffffffff815dfcc7>] rest_init+0x77/0x80
[   10.676065]  [<ffffffff81a60f47>] start_kernel+0x40f/0x41a
[   10.682190]  [<ffffffff81a60941>] ? repair_env_string+0x5c/0x5c
[   10.688799]  [<ffffffff81a60120>] ? early_idt_handlers+0x120/0x120
[   10.695699]  [<ffffffff81a605ee>] x86_64_start_reservations+0x2a/0x2c
[   10.702889]  [<ffffffff81a60733>] x86_64_start_kernel+0x143/0x152
[   10.709689] Code: a0 fc ff 85 c0 8b 4d d4 74 c3 48 8b 7b 08 89 ca 48 c7 c6 60 66 13 a0 31 c0 e8 9d 70 28 e1 8b 4d d4 eb aa 0f 1f 84 00 00 00 00 00 <45> 8b 64 24 3c 48 89 df e8 23 47 4c e1 41 83 fc 01 19 c0 48 83
[   10.731470] RIP  [<ffffffffa0133df0>] ahci_hw_interrupt+0x100/0x130 [libahci]
[   10.739441]  RSP <ffff880033c03d98>
[   10.743333] CR2: 000000000000003c
[   10.747032] ---[ end trace b6e82636970e2690 ]---
[   10.760190] Kernel panic - not syncing: Fatal exception in interrupt
[   10.767291] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)

Cc: Alexander Gordeev <agordeev@redhat.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-of-by: David Milburn <dmilburn@redhat.com>
Fixes: 5ca72c4f7c41 ("AHCI: Support multiple MSIs")
[IA64] Change default PSR.ac from '1' to '0' (Fix erratum #237)

April 2014 Itanium processor specification update:

http://www.intel.com/content/www/us/en/processors/itanium/itanium-specification-update.html

describes this erratum:

=========================================================================
237. Under a complex set of conditions, store to load forwarding for a
sub 8-byte load may complete incorrectly

Problem: A load instruction may complete incorrectly when a code sequence
using 4-byte or smaller load and store operations to the same address
is executed in combination with specific timing of all the following
concurrent conditions: store to load forwarding, alignment checking
enabled, a mis-predicted branch, and complex cache utilization activity.

Implication: The affected sub 8-byte instruction may complete
incorrectly resulting in unpredictable system behavior. There is an
extremely low probability of exposure due to the significant number of
complex microarchitectural concurrent conditions required to encounter
the erratum.

Workaround: Set PSR.ac = 0 to completely avoid the erratum. Disabling
Hyper-Threading will significantly reduce exposure to the conditions
that contribute to encountering the erratum.

Status: See the Summary Table of Changes for the affected steppings.
=========================================================================

[Table of changes essentially lists all models from McKinley to Tukwila]

The PSR.ac bit controls whether the processor will always generate
an unaligned reference trap (0x5a00) for a misaligned data access
(when PSR.ac=1) or if it will let the access succeed when running
on a cpu that implements logic to handle some unaligned accesses.

Way back in 2008 in commit b704882e70d87d7f56db5ff17e2253f3fa90e4f3
  [IA64] Rationalize kernel mode alignment checking
we made the decision to always enable strict checking. We were
already doing so in trap/interrupt context because the common
preamble code set this bit - but the rest of supervisor code
(and by inheritance user code) ran with PSR.ac=0.

We now reverse that decision and set PSR.ac=0 everywhere in the
kernel (also inherited by user processes). This will avoid the
erratum using the method described in the Itanium specification
update.  Net effect for users is that the processor will handle
unaligned access when it can (typically with a tiny performance
bubble in the pipeline ... but much less invasive than taking a
trap and having the OS perform the access).

Signed-off-by: Tony Luck <tony.luck@intel.com>
aio: block io_destroy() until all context requests are completed

deletes aio context and all resources related to. It makes sense that
no IO operations connected to the context should be running after the context
is destroyed. As we removed io_context we have no chance to
get requests status or call io_getevents().

man page for io_destroy says that this function may block until
all context's requests are completed. Before kernel 3.11 io_destroy()
blocked indeed, but since aio refactoring in 3.11 it is not true anymore.

Here is a pseudo-code that shows a testcase for a race condition discovered
in 3.11:

  initialize io_context
  io_submit(read to buffer)
  io_destroy()

  // context is destroyed so we can free the resources
  free(buffers);

  // if the buffer is allocated by some other user he'll be surprised
  // to learn that the buffer still filled by an outstanding operation
  // from the destroyed io_context

The fix is straight-forward - add a completion struct and wait on it
in io_destroy, complete() should be called when number of in-fligh requests
reaches zero.

If two or more io_destroy() called for the same context simultaneously then
only the first one waits for IO completion, other calls behaviour is undefined.

Tested: ran http://pastebin.com/LrPsQ4RL testcase for several hours and
  do not see the race condition anymore.

Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Merge tag 'please-pull-ia64-erratum' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux

Pull itanium erratum fix from Tony Luck:
 "Small workaround for a rare, but annoying, erratum #237"

* tag 'please-pull-ia64-erratum' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux:
  [IA64] Change default PSR.ac from '1' to '0' (Fix erratum #237)
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux

Pull s390 patches from Martin Schwidefsky:
 "An update to the oops output with additional information about the
  crash.  The renameat2 system call is enabled.  Two patches in regard
  to the PTR_ERR_OR_ZERO cleanup.  And a bunch of bug fixes"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/sclp_cmd: replace PTR_RET with PTR_ERR_OR_ZERO
  s390/sclp: replace PTR_RET with PTR_ERR_OR_ZERO
  s390/sclp_vt220: Fix kernel panic due to early terminal input
  s390/compat: fix typo
  s390/uaccess: fix possible register corruption in strnlen_user_srst()
  s390: add 31 bit warning message
  s390: wire up sys_renameat2
  s390: show_registers() should not map user space addresses to kernel symbols
  s390/mm: print control registers and page table walk on crash
  s390/smp: fix smp_stop_cpu() for !CONFIG_SMP
  s390: fix control register update
sfc:On MCDI timeout, issue an FLR (and mark MCDI to fail-fast)

When an MCDI command times out (whether or not we find it
completed when we poll), call efx_mcdi_abandon(), which tells
all subsequent MCDI calls to fail-fast, and queues up an FLR.

Because an FLR doesn't lead to receiving any reboot even from
the MC (unlike most other types of reset), we have to call
efx_ef10_reset_mc_allocations.
In efx_start_all(), if a reset (of any kind) is pending, we
bail out.
Without this, attempts to reconfigure (e.g. change mtu) can
cause driver/mc state inconsistency if the first MCDI call
triggers an FLR.

For similar reasons, on EF10, in
efx_reset_down(method=RESET_TYPE_MCDI_TIMEOUT), set the number
of active queues to zero before calling efx_stop_all().
And, on farch, in efx_reset_up(method=RESET_TYPE_MCDI_TIMEOUT),
set active_queues and flushes pending & outstanding to zero.

efx_mcdi_mode_{poll,event}() should not take us out of fail-fast
 mode. Instead, this is done by efx_mcdi_reset() after the FLR
completes.

The new FLR reset_type RESET_TYPE_MCDI_TIMEOUT doesn't really
fit into the hierarchy of reset 'scopes' whereby efx_reset()
decides some resets subsume others.  Thus, it uses separate logic.

Also, fixed up some inconsistency around RESET_TYPE_MC_BIST,
which was in the wrong place in that hierarchy.

Signed-off-by: Shradha Shah <sshah@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
staging: delete rtl8187se wireless driver

There is a "real" driver for this hardware now in drivers/net/ so remove
the staging version as it's not needed anymore.

Reported-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: John W. Linville" <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>