UDC needs to release lock before calling out to gadget driver, since
it may need to reenter.  The change fixes kernel BUG observed on rt
kernel.

> kernel BUG at kernel/rtmutex.c:683!
> stopped custom tracer.
> Oops: Exception in kernel mode, sig: 5 [#1]
> PREEMPT MPC834x ITX
> NIP: c021629c LR: c0216270 CTR: 00000000
> REGS: df761d70 TRAP: 0700   Not tainted  (2.6.23.9-rt13)
> MSR: 00021032 <ME,IR,DR>  CR: 28000022  XER: 00000000
> TASK = df632080[241] 'IRQ-38' THREAD: df760000
> GPR00: 00000001 df761e20 df632080 00000000 11111111 00000000 df761e6c
> 00000000
> GPR08: df761e48 00000000 df761e50 00000000 80000000 ede5cdde 1fffd000
> 00800000
> GPR16: ffffffff 00000000 007fff00 00000040 00000000 007ffeb0 00000000
> 1fff8b08
> GPR24: 00000000 00000026 00000000 df79a320 c026b2e8 c02240bc 00009032
> df79a320
> NIP [c021629c] rt_spin_lock_slowlock+0x9c/0x200
> LR [c0216270] rt_spin_lock_slowlock+0x70/0x200
> Call Trace:
> [df761e20] [c0216270] rt_spin_lock_slowlock+0x70/0x200 (unreliable)
> [df761e90] [c0182828] fsl_ep_disable+0xcc/0x154
> [df761eb0] [c0184d30] eth_reset_config+0x88/0x1d0
> [df761ed0] [c0184ec0] eth_disconnect+0x48/0x64
> [df761ef0] [c01831a4] reset_queues+0x60/0x78
> [df761f00] [c0183b74] fsl_udc_irq+0x9b8/0xa58
> [df761f50] [c003ef30] handle_IRQ_event+0x64/0x100
> [df761f80] [c003f758] thread_simple_irq+0x6c/0xc8
> [df761fa0] [c003f888] do_irqd+0xd4/0x2e4
> [df761fd0] [c0032284] kthread+0x50/0x8c
> [df761ff0] [c000f9b4] kernel_thread+0x44/0x60
Signed-off-by: Li Yang <leoli@freescale.com>
Cc: Eugene T. Bordenkircher <Eugene_Bordenkircher@selinc.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Add the interface info matching to all Huawei cards, as they all also
contain a Mass Storage Device interface (usually containing Windows
drivers) which should not get bound by this driver.

See also drivers/usb/storage/unusual_devs.h
Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

I've just got a USB GPRS/EDGE modem branded Manufacturer Micromax Model
MMX610U (see http://www.airtel.in/level2_t3data.aspx?path=1/106/179)
working by adding another product ID to pl2303.  Modem info reports same
module as  Max Arnold's i.e.SIMCOM SIM600  but  with product ID 0x0612
(cf Ox0611).

From: Steve Murphy <steve@gnusis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Like the HP53{00,70} scanner other devices of the OEM Avision require
the USB_QUIRK_STRING_FETCH_255 to correct set a configuration with
"recent" Linux kernels.
Signed-off-by: René Rebe <rene@exactcode.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This patch adds support for rev 2 of an existing unusual_devs entry
enabling ROKR W5s to work. Greg, please apply.

From: Javier Smaldone <javier@smaldone.com.ar>
Signed-off-by: Phil Dibowitz <phil@ipom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

It turns out that the unusual_devs entry for the Motorola M600i needs
another flag. This patch adds it. Thanks to Atte André Jensen
<atte@ballbreaker.dk>.
Signed-off-by: Phil Dibowitz <phil@ipom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This patch (as1101) updates the unusual_devs entry for the Cypress
ATACB pass-through.  The protocol field is changed from US_PR_BULK to
US_PR_DEVICE, since the Cypress devices already set bInterfaceProtocol
to Bulk-only.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This patch (as1099) fixes a performance regression in ehci-hcd.  The
fundamental problem is that queue headers get removed from the
schedule too quickly, since the code checks for a counter advancing
rather than making an actual time-based check.  The latency involved
in removing the queue header and then relinking it can severely
degrade certain kinds of workloads.

The patch replaces a simple counter with a timestamp derived from the
controller's uframe value.  In addition, the delay for unlinking an
idle queue header is increased from 5 ms to 10 ms; since some
controllers (nVidia) have a latency of up to 1 ms for unlinking, this
reduces the relative impact from 20% to 10%.

Finally, a logical error left over from the IAA watchdog-timer
conversion is corrected.  Now the driver will always either unlink an
idle queue header or set up a timer to unlink it later.  The old code
would sometimes fail to do either.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <david-b@pacbell.net>
Cc: Leonid <leonidv11@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This patch (as1098) changes the way ehci-hcd schedules its periodic
Iso transfers.  That the current scheduling code is wrong is clear on
the face of it: Sometimes it returns -EL2NSYNC (meaning that an URB
couldn't be scheduled because it was submitted too late), but it does
this even when the URB_ISO_ASAP flag is set (meaning the URB should be
scheduled as soon as possible).

The new code properly implements as-soon-as-possible scheduling,
assigning the next unexpired slot as the URB's starting point.  It
also is more careful about checking for Iso URB completion: It doesn't
bother to check for activity during frames that are already over,
and it allows for the possibility that some of the URB's packets may
have raced the hardware when they were submitted and so never got used
(the packet status is set to -EXDEV).

This fixes problems several people have experienced with USB video
applications.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This patch (as1097) fixes a bug in the remote-wakeup handling in
ehci-hcd.  The driver currently does not keep track of whether the
change-suspend feature is enabled for each port; the feature is
automatically reset the first time it is read.  But recent changes to
the hub driver require that the feature be read at least twice in
order to work properly.

A bit-vector is added for storing the change-suspend feature values.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This patch (as1096) fixes an annoying problem: When a full-speed or
low-speed device is plugged into an EHCI controller, it fails to
enumerate at high speed and then is handed over to the companion
controller.  But usbcore logs a misleading and unwanted error message
when the high-speed enumeration fails.

The patch adds a new HCD method, port_handed_over, which asks whether
a port has been handed over to a companion controller.  If it has, the
error message is suppressed.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This patch (as1095) cleans up the HCD glue and several of the EHCI
bus-glue files.  The ehci->is_tdi_rh_tt flag is redundant, since it
means the same thing as the hcd->has_tt flag, so it is removed and the
other flag used in its place.

Some of the bus-glue files didn't get the relinquish_port method added
to their hc_driver structures.  Although that routine currently
doesn't do anything for controllers with an integrated TT, in the
future it might.  So the patch adds it where it is missing.

Lastly, some of the bus-glue files have erroneous entries for their
hc_driver's suspend and resume methods.  These method pointers are
specific to PCI and shouldn't be used otherwise.

(The patch also includes an invisible whitespace fix.)
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>

This patch (as1094) changes the output of the "descriptors" binary
attribute.  Now it will contain the device descriptor followed by all
the configuration descriptors, not just the descriptor for the current
config.

Userspace libraries want to have access to the kernel's cached
descriptor information, so they can learn about device characteristics
without having to wake up suspended devices.  So far the only user of
this attribute is the new libusb-1.0 library; thus changing its
contents shouldn't cause any problems.

This should be considered for 2.6.26, if for no other reason than to
minimize the range of releases in which the attribute contains only the
current config descriptor.

Also, it doesn't hurt that the patch removes the device locking --
which was formerly needed in order to know for certain which config was
indeed current.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

There is a potential deadlock when the usb_generic driver is unbound
from a device.  The problem is that generic_disconnect() is called
with the device lock held, and it removes a bunch of device attributes
from sysfs.  If a user task happens to be running an attribute method
at the time, the removal will block until the method returns.  But at
least one of the attribute methods (the store routine for power/level)
needs to acquire the device lock!

This patch (as1093) eliminates the deadlock by moving the calls to
create and remove the sysfs attributes from the usb_generic driver
into usb_new_device() and usb_disconnect(), where they can be invoked
without holding the device lock.

Besides, the other sysfs attributes are created when the device is
registered and removed when the device is unregistered.  So it seems
only fitting for the extra attributes to be created and removed at the
same time.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Uninitialised Apple iSight drivers present with a distinctive USB ID.
Once firmware has been uploaded, they disconnect and reconnect with a
new ID. At this point they can be driven by the uvcvideo driver. As this
is unique to the Apple cameras and not functionality shared by any other
UVC devices, it makes sense to provide the firmware loading
functionality in a separate driver. This driver will read an isight.fw
file extracted from the Apple driver using the tools at
http://bersace03.free.fr/ift/ and upload it to the camera. It will also
handle the case where the device loses its firmware during hibernation
and must have it reloaded.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This patch adds support for the range of PIDs
that have been allocated for FTDI based devices
at Matrix Orbital.

A small number of units have been shipped early 2008
with a faulty USB Descriptor.  Products that may have
this issue have been marked with the existing quirk to
work around the problem.
Signed-off-by: R. Molenkamp <rmolenkamp@matrixorbital.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

> +#define	ARCH_KMALLOC_MINALIGN		(sizeof(long) * 2)
> +#define	ARCH_SLAB_MINALIGN		(sizeof(long) * 2)

This doesn't work if SLAB is selected and slab debugging is enabled as
these are passed to the preprocessor, and the preprocessor doesn't
understand sizeof.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

* 'for-linus' of git://git.kernel.dk/linux-2.6-block:
  cfq-iosched: fix RCU problem in cfq_cic_lookup()
  block: make blktrace use per-cpu buffers for message notes
  Added in elevator switch message to blktrace stream
  Added in MESSAGE notes for blktraces
  block: reorder cfq_queue to save space on 64bit builds
  block: Move the second call to get_request to the end of the loop
  splice: handle try_to_release_page() failure
  splice: fix sendfile() issue with relay

Specify the minimum slab/kmalloc alignment to be 8 bytes.  This fixes a
crash when SLOB is selected as the memory allocator.  The FRV arch needs
this so that it can use the load- and store-double instructions without
faulting.  By default SLOB sets the minimum to be 4 bytes.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Fix a typo in the header guard of asm/ipc.h.
Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

cfq_cic_lookup() needs to properly protect ioc->ioc_data before
dereferencing it and also exclude updaters of ioc->ioc_data as well.

Also add a number of comments documenting why the existing RCU usage
is OK.

Thanks a lot to "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> for
review and comments!
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Currently it uses a single static char array, but that risks
being corrupted when multiple users issue message notes at the
same time. Make the buffers dynamically allocated when the trace
is setup and make them per-cpu instead.

The default max message size of 1k is also very large, the
interface is mainly for small text notes. So shrink it to 128 bytes.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Signed-off-by: Alan D. Brunelle <alan.brunelle@hp.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Allows messages to be inserted into blktrace streams.
Signed-off-by: Alan D. Brunelle <alan.brunelle@hp.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

saves 8 bytes of padding & increases objects/slab from 30 to 32 on my
AMD64 config
Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

In function get_request_wait, the second call to get_request could be
moved to the end of the while loop, because if the first call to
get_request fails, the second call will fail without sleep.
Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

splice currently assumes that try_to_release_page() always suceeds,
but it can return failure. If it does, we cannot steal the page.

Acked-by: Mingming Cao <cmm@us.ibm.com
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Splice isn't always incrementing the ppos correctly, which broke
relay splice.
Signed-off-by: Tom Zanussi <zanussi@comcast.net>
Tested-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
  pciehp: add message about pciehp_slot_with_bus option
  pci hotplug core: add check of duplicate slot name
  pciehp: move msleep after power off
  pciehp: poll cmd completion if hotplug interrupt is disabled
  pciehp: fix slow probing
  pciehp: fix NULL dereference in interrupt handler
  shpchp: add message about shpchp_slot_with_bus option
  PCI: don't enable ASPM on devices with mixed PCIe/PCI functions

Some (broken?) platform assign the same slot name to multiple hotplug
slots. On such system, slot initialization would fail because of name
collision. The pciehp driver already have a "slot_with_bus" module
option which adds the bus number into the slot name. This patch adds
the message about this module option that will be displayed when slot
name collision is detected.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

Fix the following errors reported by Jan C. Nordholz in
http://bugzilla.kernel.org/show_bug.cgi?id=10751.

kobject_add_internal failed for 2 with -EEXIST, don't try to register things with the same name in the same directory.
Pid: 1, comm: swapper Tainted: G        W 2.6.26-rc3 #1
 [<c0266980>] kobject_add_internal+0x140/0x190
 [<c0266afd>] kobject_init_and_add+0x2d/0x40
 [<c027bc91>] pci_hp_register+0x81/0x2f0
 [<c027fd07>] pciehp_probe+0x1a7/0x470
 [<c01b3b84>] sysfs_add_one+0x44/0xa0
 [<c01b3c1f>] sysfs_addrm_start+0x3f/0xb0
 [<c01b497a>] sysfs_create_link+0x8a/0xf0
 [<c0279570>] pcie_port_probe_service+0x50/0x80
 [<c02e0545>] driver_sysfs_add+0x55/0x70
 [<c02e0662>] driver_probe_device+0x82/0x180
 [<c02e07cc>] __driver_attach+0x6c/0x70
 [<c02dfe0a>] bus_for_each_dev+0x3a/0x60
 [<c05db2d0>] pcied_init+0x0/0x80
 [<c02e04e6>] driver_attach+0x16/0x20
 [<c02e0760>] __driver_attach+0x0/0x70
 [<c02e0341>] bus_add_driver+0x1a1/0x220
 [<c05db2d0>] pcied_init+0x0/0x80
 [<c02e09cd>] driver_register+0x4d/0x120
 [<c05db050>] ibm_acpiphp_init+0x0/0x190
 [<c0125aab>] printk+0x1b/0x20
 [<c05db2d0>] pcied_init+0x0/0x80
 [<c05db2de>] pcied_init+0xe/0x80
 [<c05c751a>] kernel_init+0x10a/0x300
 [<c0120138>] schedule_tail+0x18/0x50
 [<c0103b9a>] ret_from_fork+0x6/0x1c
 [<c05c7410>] kernel_init+0x0/0x300
 [<c05c7410>] kernel_init+0x0/0x300
 [<c010485b>] kernel_thread_helper+0x7/0x1c
 =======================
pci_hotplug: Unable to register kobject '2'<3>pciehp: pci_hp_register failed with error -22

Slot with the same name can be registered multiple times if shpchp or
pciehp driver is loaded after acpiphp is loaded because ACPI based
hotplug driver and Native OS hotplug driver trying to handle the same
physical slot. In this case, current pci_hotplug core will call
kobject_init_and_add() muliple time with the same name. This is the
cause of this problem. To fix this problem, this patch adds the check
into pci_hp_register() to see if the slot with the same name.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

According to the PCI Express specification, we must wait for at least
1 second after turning power off before taking any action that relies
on power having been removed from the slot/adapter. For this, current
pciehp wait for 1 second after issuing the power off command in
hpc_power_off_slot() function. But waiting for 1 second in
hpc_power_off_slot() can make pciehp probing slow-down because pciehp
probe code calls hpc_power_off_slot() if the slot is not occupied just
in case. We don't need to wait for 1 second at the pciehp probe time
because there is no action on that empty slot. So move 1 second wait
from hpc_power_off_slot() to the caller of hpc_power_off_slot().
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

Fix improper long wait for command completion in pciehp probing.

As described in PCI Express specification, software notification is
not generated if the command that occurs as a result of a write to the
Slot Control register that disables software notification of command
completed events. Since pciehp driver doesn't take it into account,
such command is issued in pciehp probing, and it causes improper long
wait for command completion.

This patch changes the pciehp driver to take such command into
account.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

Fix the "pciehp probing slow" problem reported from Jan C. Nordholz in
http://bugzilla.kernel.org/show_bug.cgi?id=10751.

The command completed bit in Slot Status register applies only to
commands issued to control the attention indicator, power indicator,
power controller, or electromechanical interlock. However, writes to
other parts of the Slot Control register would end up writing to the
control fields. Hence, any write to Slot Control register is
considered as a command. However, if the controller doesn't support
any of attention indicator, power indicator, power controller and
electromechanical interlock, command completed bit would not set in
writing to Slot Control register. In this case, we should not wait for
command completed bit set, otherwise all commands would be considered
not completed in timeout seconds (1 sec.).

The cause of the problem is pciehp driver didn't take this situation
into account. This patch changes pciehp to take it into account. This
patch also add the check for "No Command Completed Support" bit in
Slot Capability register. If it is set, we should not wait for command
completed bit set as well.

This problem seems to be revealed by the commit
c27fb883 that fixed the bug that
pciehp did not wait for command completed properly (pciehp just
ignored the command completion event).
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

Fix the following NULL dereference problem reported from Pierre Ossman
and Ingo Molnar.

pciehp: HPC vendor_id 8086 device_id 27d0 ss_vid 0 ss_did 0
pciehp: pciehp_find_slot: slot (device=0x0) not found
BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
IP: [<ffffffff80494a8b>] pciehp_handle_presence_change+0x7e/0x113
PGD 0
Oops: 0000 [1]
CPU 0
Modules linked in:
Pid: 1, comm: swapper Tainted: G        W 2.6.26-rc3-sched-devel.git-00001-g2b99b26-dirty #170
RIP: 0010:[<ffffffff80494a8b>]  [<ffffffff80494a8b>] pciehp_handle_presence_change+0x7e/0x113
RSP: 0000:ffff81003f83fbb0  EFLAGS: 00010046
RAX: 0000000000000039 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000046
RBP: ffff81003f83fbd0 R08: 0000000000000001 R09: ffffffff80245103
R10: 0000000000000020 R11: 0000000000000000 R12: ffff81003ea53a30
R13: 0000000000000000 R14: 0000000000000011 R15: ffffffff80495926
FS:  0000000000000000(0000) GS:ffffffff80be7400(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000070 CR3: 0000000000201000 CR4: 00000000000006a0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo ffff81003f83e000, task ffff81003f840000)
Stack:  0000000000000008 ffff81003f83fbf6 ffff81003ea53a30 0000000000000008
 ffff81003f83fc10 ffffffff80495ab4 0000000000000011 0000000000000002
 0000000000000202 0000000000000202 00000000fffffff4 ffff81003ea53a30
Call Trace:
 [<ffffffff80495ab4>] pcie_isr+0x18e/0x1bc
 [<ffffffff80260831>] request_irq+0x106/0x12f
 [<ffffffff80495fb6>] pcie_init+0x15e/0x6cc
 [<ffffffff804933a3>] pciehp_probe+0x64/0x541
 [<ffffffff8048f4e7>] pcie_port_probe_service+0x4c/0x76
 [<ffffffff8054af70>] driver_probe_device+0xd4/0x1f0
 [<ffffffff8054b108>] __driver_attach+0x7c/0x7e
 [<ffffffff8054b08c>] ? __driver_attach+0x0/0x7e
 [<ffffffff8054a4b6>] bus_for_each_dev+0x53/0x7d
 [<ffffffff8054ad3c>] driver_attach+0x1c/0x1e
 [<ffffffff8054a9c2>] bus_add_driver+0xdd/0x25b
 [<ffffffff80c09d3d>] ? pcied_init+0x0/0x8b
 [<ffffffff8054b288>] driver_register+0x5f/0x13e
 [<ffffffff80c09d3d>] ? pcied_init+0x0/0x8b
 [<ffffffff8048f441>] pcie_port_service_register+0x47/0x49
 [<ffffffff80c09d52>] pcied_init+0x15/0x8b
 [<ffffffff80bf3938>] kernel_init+0x75/0x243
 [<ffffffff808639d2>] ? _spin_unlock_irq+0x2b/0x3a
 [<ffffffff80228d1f>] ? finish_task_switch+0x57/0x9a
 [<ffffffff8020c258>] child_rip+0xa/0x12
 [<ffffffff8020bcec>] ? restore_args+0x0/0x30
 [<ffffffff80bf38c3>] ? kernel_init+0x0/0x243
 [<ffffffff8020c24e>] ? child_rip+0x0/0x12

Code: 83 80 00 00 00 48 39 f0 75 e1 0f b6 c9 48 c7 c2 00 0e 8d 80 48 c7 c6 8a 60 a6 80 48 c7 c7 10 db a8 80 31 c0 e8 3f 8d d9 ff 31 db <48> 8b 43 70 48 8d 75 ef 48 89 df ff 50 30 80 7d ef 00 74 37 48
RIP  [<ffffffff80494a8b>] pciehp_handle_presence_change+0x7e/0x113
 RSP <ffff81003f83fbb0>
CR2: 0000000000000070
Kernel panic - not syncing: Fatal exception

The situation under which it occurs is hw and timing related: it appears
to happen on a system that has PCI hotplug hardware but with no active
hotplug cards, and another interrupt in the same (shared) IRQ line
arrives too early, before the hotplug-slot entry has been set up - as
triggered by CONFIG_DEBUG_SHIRQ=y:

This patch contains the following two fixes.

(1) Clear all events bits in Slot Status register to prevent the pciehp
    driver from detecting the spurious events that would have been occur
    before pciehp loading.

(2) Add check whether slot initialization had been already done.

This is short term fix. We need more structural fixes to install
interrupt handler after slot initialization is done.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

Some (broken?) platform assign the same slot name to multiple hotplug
slots. On such system, slot initialization would fail because of name
collision. The shpchp driver already have a "slot_with_bus" module
option which adds the bus number into the slot name. This patch adds
the message about this module option that will be displayed when slot
name collision is detected.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

* git://git.kernel.org/pub/scm/linux/kernel/git/hskinnemoen/avr32-2.6:
  avr32: Fix cpufreq oops when ondemand governor is default
  avr32: Update defconfigs
  avr32: export strnlen_user
  avr32: export copy_page

There's a reason why using C99 initialisers even in the supposedly
trivial structs is a good idea.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Move the AP7 cpufreq init to late_initcall() so that we don't try to
bring up cpufreq until the governor is ready. x86 also uses
late_initcall() for this.
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>