md has some plugging infrastructure for RAID5 to use because the
normal plugging infrastructure required a 'request_queue', and when
called from dm, RAID5 doesn't have one of those available.

This relied on the ->unplug_fn callback which doesn't exist any more.

So remove all of that code, both in md and raid5.  Subsequent patches
with restore the plugging functionality.
Signed-off-by: NNeilBrown <neilb@suse.de>

Now that unplugging is done differently, the unplug_fn callback is
never called, so it can be completely discarded.
Signed-off-by: NNeilBrown <neilb@suse.de>

md/raid submits a lot of IO from the various raid threads.
So adding start/finish plug calls to those so that some
plugging happens.
Signed-off-by: NNeilBrown <neilb@suse.de>

Apparently some distros set i2c-algo-bit.bit_test to 1 by
default.  In some cases this causes i2c_bit_add_bus
to fail and prevents the i2c bus from being added.  In the
radeon case, we fail to add the ddc i2c buses which prevents
the driver from being able to detect attached monitors.
The i2c bus works fine even if bit_test fails.  This is likely
due to gpio switching that is required and handled in the
pre/post_xfer hooks, so call the pre/post_xfer hooks in the
bit test as well.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=36221Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org [.38 down to .34]

When warning on the use of deprecated i2c_driver methods
attach_adapter and detach_adapter, mention the name of the driver
which needs to be updated.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Fix a possible problem with mport registration left non-cleared after
fsl_rio_setup() exits on link error.  Abort mport initialization if
registration failed.

This patch is applicable to 2.6.39-rc1 only.  The problem does not exist
for earlier versions.
Signed-off-by: NAlexandre Bounine <alexandre.bounine@idt.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
Cc: Thomas Moll <thomas.moll@sysgo.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAlexandre Bounine <alexandre.bounine@idt.com>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix the wrong members and the wrong function's definition, since the
irq_chip had changed.
Signed-off-by: NWanlong Gao <wanlong.gao@gmail.com>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Make the driver aware of the initial status of the regulator.

The leds-regulator driver was ignoring the initial status of the
regulator; this resulted in rdev->use_count being incremented to 2 after
calling regulator_led_set_value() in the .probe method when a regulator
was already enabled at insmod time, which made it impossible to ever
disable the regulator.
Signed-off-by: NAntonio Ospite <ospite@studenti.unina.it>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Antonio Ospite <ospite@studenti.unina.it>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Daniel Ribeiro <drwyrm@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The platform_device_id table is supposed to be zero-terminated.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit 58085446.

To quote Richard:
	I don't think this should be mainlined. It was a
	misunderstanding on my part.  If you see all the other hdc
	drivers in the same location, they all do the same thing (i.e.
	clear the interrupt status first, then do the work) that
	"glitch" I think I saw was actually two back-to-back
	interrupts.

	Sebastian (the original author of isp1760) explained it to me a
	few days after my submission.

	sorry for the confusion

Cc: Richard Retanubun <RichardRetanubun@ruggedcom.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch disable the optional PM feature inside the Hudson3 platform under
the following conditions:

1. If an isochronous device is connected to xHCI port and is active;
2. Optional PM feature that powers down the internal Bus PLL when the link is
   in low power state is enabled.

The PM feature needs to be disabled to eliminate PLL startup delays when the
link comes out of low power state. The performance of DMA data transfer could
be impacted if system delay were encountered and in addition to the PLL start
up delays. Disabling the PM would leave room for unpredictable system delays
in order to guarantee uninterrupted data transfer to isochronous audio or
video stream devices that require time sensitive information. If data in an
audio/video stream was interrupted then erratic audio or video performance
may be encountered.

AMD PLL quirk is already implemented in OHCI/EHCI driver. After moving the
quirk code to pci-quirks.c and export them, xHCI driver can call it directly
without having the quirk implementation in itself.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

On a resume, when the power is lost during hibernate, the USB core will
call hub_reset_resume for the xHCI USB 2.0 roothub, but not for the USB
3.0 roothub:

[  164.748310] usb usb1: root hub lost power or was reset
[  164.748353] usb usb2: root hub lost power or was reset
[  164.748487] usb usb3: root hub lost power or was reset
[  164.748488] xhci_hcd 0000:01:00.0: Stop HCD
...
[  164.870039] hub 4-0:1.0: hub_resume
...
[  164.870054] hub 3-0:1.0: hub_reset_resume

This causes issues later, because the USB core assumes the USB 3.0 hub
attached to the USB 3.0 roothub is still active.  It attempts to queue a
control URB for the external hub, which fails because all the device
slot contexts were released when the USB 3.0 roothub lost power:

[  164.980044] hub 4-1:1.0: hub_resume
[  164.980047] xhci_hcd 0000:01:00.0: Get port status returned 0x10101
[  164.980049] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980053] hub 3-0:1.0: port 1: status 0101 change 0001
[  164.980056] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980060] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc90008948440, 32'h202e1, 4'hf);
[  164.980062] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980066] xhci_hcd 0000:01:00.0: clear port connect change, actual port 0 status  = 0x2e1
[  164.980069] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980072] xhci_hcd 0000:01:00.0: get port status, actual port 1 status  = 0x2a0
[  164.980074] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980077] xhci_hcd 0000:01:00.0: Get port status returned 0x100
[  164.980079] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980082] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980085] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980088] hub 4-1:1.0: port 4: status 0000 change 0000
[  164.980091] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980094] hub 4-1:1.0: activate --> -22
[  164.980113] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980117] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980119] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980123] hub 4-1:1.0: can't resume port 4, status -22
[  164.980126] hub 4-1:1.0: port 4 status ffff.ffff after resume, -22
[  164.980129] usb 4-1.4: can't resume, status -22
[  164.980131] hub 4-1:1.0: logical disconnect on port 4

This causes issues when a USB 3.0 hard drive is attached to the external
USB 3.0 hub when the system is hibernated:

[ 6249.849653] sd 8:0:0:0: [sdb] Unhandled error code
[ 6249.849659] sd 8:0:0:0: [sdb]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[ 6249.849663] sd 8:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 2a 08 00 00 02 00
[ 6249.849671] end_request: I/O error, dev sdb, sector 10760

Make sure to inform the USB core that *both* xHCI roothubs lost power.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

This patch clear PORT_POWER when suspend a USB3.0 device behind a USB3.0
external hub, so the system can suspend and resume.

Note USB3.0 device may not work after system resume and this is a temporary
workaround. The correct fix will be in future patches.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

If I unplug a device while the UAS driver is loaded, I get an oops
in usb_free_streams().  This is because usb_unbind_interface() calls
usb_disable_interface() which calls usb_disable_endpoint() which sets
ep_out and ep_in to NULL.  Then the UAS driver calls usb_pipe_endpoint()
which returns a NULL pointer and passes an array of NULL pointers to
usb_free_streams().

I think the correct fix for this is to check for the NULL pointer
in usb_free_streams() rather than making the driver check for this
situation.  My original patch for this checked for dev->state ==
USB_STATE_NOTATTACHED, but the call to usb_disable_interface() is
conditional, so not all drivers would want this check.

Note from Sarah Sharp: This patch does avoid a potential dereference,
but the real fix (which will be implemented later) is to set the
.soft_unbind flag in the usb_driver structure for the UAS driver, and
all drivers that allocate streams.  The driver should free any streams
when it is unbound from the interface.  This avoids leaking stream rings
in the xHCI driver when usb_disable_interface() is called.

This should be queued for stable trees back to 2.6.35.
Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

Currently, when resetting a device, xHCI driver disables all but one
endpoints and frees their rings, but leaves alone any streams that
might have been allocated. Later, when users try to free allocated
streams, we oops in xhci_setup_no_streams_ep_input_ctx() because
ep->ring is NULL.

Let's free not only rings but also stream data as well, so that
calling free_streams() on a device that was reset will be safe.

This should be queued for stable trees back to 2.6.35.
Reviewed-by: NMicah Elizabeth Scott <micah@vmware.com>
Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

When we get a port status change event, we need to figure out what type of
port it came from: a USB 3.0 port, or a USB 2.0/1.1 port.  We can't know
which usb_hcd to use until that point, so hcd will be NULL for part of the
function.  Unfortunately, if any of the sanity checks fail, we'll jump to
the cleanup label before hcd is set to a valid pointer, and then we'll
attempt to tell the USB core to kick the hcd, which is NULL.

Skip kicking the roothub if the sanity checks fail.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

When parsing exponent-expressed intervals we subtract 1 from the
value and then expect it to match with original + 1, which is
highly unlikely, and we end with frequent spew:

	usb 3-4: ep 0x83 - rounding interval to 512 microframes

Also, parsing interval for fullspeed isochronous endpoints was
incorrect - according to USB spec they use exponent-based
intervals (but xHCI spec claims frame-based intervals). I trust
USB spec more, especially since USB core agrees with it.

This should be queued for stable kernels back to 2.6.31.
Reviewed-by: NMicah Elizabeth Scott <micah@vmware.com>
Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

The logic of the handling Missed Service Error Events was pretty
confusing as we were checking the same condition several times.
In addition, it caused compiler warning since the compiler could
not figure out that event_trb is actually unused in case we are
skipping current TD.

Fix that by rearranging "skip" condition checks, and factor out
skip_isoc_td() so that it is called explicitly.
Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Remove 'inline' markings from file-local functions and let compiler
do its job and inline what makes sense for given architecture.
Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

There were some places that compared port_speed == -1 where port_speed
is a u8.  This doesn't work unless we cast the -1 to u8.  Some places
did it correctly.

Instead of using -1 directly, I've created a DUPLICATE_ENTRY define
which does the cast and is more descriptive as well.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Macro arguments used in expressions need to be enclosed in parenthesis
to avoid unpleasant surprises.

This should be queued for kernels back to 2.6.31
Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

Isochronous and interrupt SuperSpeed endpoints use the same mechanisms
for decoding bInterval values as HighSpeed ones so adjust the code
accordingly.

Also bandwidth reservation for SuperSpeed matches highspeed, not
low/full speed.
Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch moves the HcInterrupt register write to clear the
pending interrupt to after the isr work is done, doing this removes
glitches in the irq line.
Signed-off-by: NRichard Retanubun <richardretanubun@ruggedcom.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The driver did not take the zero flag in the USB request. If the
request length is the same as the endpoint's maxpacket, an additional
ZLP with no data has to be transmitted.

The method used here is inspired to what is done in fsl_udc_core.c
(and pxa27x_udc.c and at91_udc.c) where this is supported.

There already was a discussion about this topic with people from
Keymile, and I propose here a better implementation:

http://thread.gmane.org/gmane.linux.usb.general/38951Signed-off-by: NValentin Longchamp <valentin.longchamp@keymile.com>
Acked-by: NLi Yang <leoli@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There are two -ENODEV error paths in qcprobe where the allocated private
data is not freed, this patch adds the two missing kfrees to avoid
leaking memory on the error path
Signed-off-by: NSteven Hardy <shardy@redhat.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Rework the qcprobe logic such that serial->private is not set when
qcprobe exits with -ENODEV, otherwise serial->private will point to freed
memory on -ENODEV
Signed-off-by: NSteven Hardy <shardy@redhat.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

qcprobe function allocates serial->private but this is never freed, this
patch adds a new function qc_release() which frees serial->private, after
calling usb_wwan_release
Signed-off-by: NSteven Hardy <shardy@redhat.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

usb serial: ftdi_sio: add two missing USB ID's for Hameg interfaces HO720
and HO730

Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Bind only modem AT command endpoint to option.
Signed-off-by: NMarius B. Kotsbak <marius@kotsbak.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There was an unlock missing on the error path.

Also I did a small cleanup by changing ep->dev->lock for just dev->lock.
They're the same lock, but dev->lock is shorter and that's how it is
used for the spin_unlock_irqrestore() call.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Booting latest kernel on my test machine produces a lockdep
warning from the usb_amd_find_chipset_info() function:

 WARNING: at /data/lemmy/linux.trees.git/kernel/lockdep.c:2465 lockdep_trace_alloc+0x95/0xc2()
 Hardware name: Snook
 Modules linked in:
 Pid: 959, comm: work_for_cpu Not tainted 2.6.39-rc2+ #22
 Call Trace:
  [<ffffffff8103c0d4>] warn_slowpath_common+0x80/0x98
  [<ffffffff812387e6>] ? T.492+0x24/0x26
  [<ffffffff8103c101>] warn_slowpath_null+0x15/0x17
  [<ffffffff81068667>] lockdep_trace_alloc+0x95/0xc2
  [<ffffffff810ed9ac>] slab_pre_alloc_hook+0x18/0x3b
  [<ffffffff810ef227>] kmem_cache_alloc_trace+0x25/0xba
  [<ffffffff812387e6>] T.492+0x24/0x26
  [<ffffffff81238816>] pci_get_subsys+0x2e/0x73
  [<ffffffff8123886c>] pci_get_device+0x11/0x13
  [<ffffffff814082a9>] usb_amd_find_chipset_info+0x3f/0x18a
...

It turns out that this function calls pci_get_device under a spin_lock
with irqs disabled, but the pci_get_device function is only allowed in
preemptible context.

This patch fixes the warning by making all data-structure
modifications on temporal storage and commiting this back
into the visible structure at the end. While at it, this
patch also moves the pci_dev_put calls out of the spinlocks
because this function might sleep too.
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We should free both descriptors.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

In file included from drivers/usb/host/ohci-hcd.c:1028:0:
drivers/usb/host/ohci-au1xxx.c:36:7: warning: "__BIG_ENDIAN" is not defined
Signed-off-by: NYoichi Yuasa <yuasa@linux-mips.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add PID 0x0103 for serial port of the OCT DK201 docking station.
Reported-by: NJan Hoogenraad <jan@hoogenraad.net>
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix build failure introduced by commit
7acc6197 (usb: musb: Idle path retention
and offmode support for OMAP3) when building without gadget
support.

  CC      drivers/usb/musb/omap2430.o
drivers/usb/musb/omap2430.c: In function ‘musb_otg_notifications’:
drivers/usb/musb/omap2430.c:262: error: ‘struct musb’ has no member named ‘gadget_driver’
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1458) fixes a problem affecting ultra-reliable systems:
When hardware failover of an EHCI controller occurs, the data
structures do not get released correctly.  This is because the routine
responsible for removing unused QHs from the async schedule assumes
the controller is running properly (the frame counter is used in
determining how long the QH has been idle) -- but when a failover
causes the controller to be electronically disconnected from the PCI
bus, obviously it stops running.

The solution is simple: Allow scan_async() to remove a QH from the
async schedule if it has been idle for long enough _or_ if the
controller is stopped.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-and-Tested-by: NDan Duval <dan.duval@stratus.com>
CC: <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

During processing of bunch of eem frames if "echo" command is found
skb is cloned and the cloned version should be used to send reply.
Unfortunately, the data of the original skb were actually used and
the cloned skb is never freed.

Using the cloned skb and freeing the skb in the completion callback
for usb request.
Signed-off-by: NYauheni Kaliuta <yauheni.kaliuta@nokia.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

I added new ProdutIds for two devices from CTI GmbH Leipzig.
Signed-off-by: NChristian Simon <simon@swine.de>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Because the disconnect function in the composite driver will call spin_lock,
this driver has to call spin_unlock before calling driver->disconnet().
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>