This patch (as1255) updates the interface for calling
usb_hub_clear_tt_buffer().  Even the name of the function is changed!

When an async URB (i.e., Control or Bulk) going through a high-speed
hub to a non-high-speed device is cancelled or fails, the hub's
Transaction Translator buffer may be left busy still trying to
complete the transaction.  The buffer has to be cleared; that's what
usb_hub_clear_tt_buffer() does.

It isn't safe to send any more URBs to the same endpoint until the TT
buffer is fully clear.  Therefore the HCD needs to be told when the
Clear-TT-Buffer request has finished.  This patch adds a callback
method to struct hc_driver for that purpose, and makes the hub driver
invoke the callback at the proper time.

The patch also changes a couple of names; "hub_tt_kevent" and
"tt.kevent" now look rather antiquated.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Originally, the USB core had no support for allocating bandwidth when a
particular configuration or alternate setting for an interface was
selected.  Instead, the device driver's URB submission would fail if
there was not enough bandwidth for a periodic endpoint.  Drivers could
work around this, by using the scatter-gather list API to guarantee
bandwidth.

This patch adds host controller API to allow the USB core to allocate or
deallocate bandwidth for an endpoint.  Endpoints are added to or dropped
from a copy of the current schedule by calling add_endpoint() or
drop_endpoint(), and then the schedule is atomically evaluated with a
call to check_bandwidth().  This allows all the endpoints for a new
configuration or alternate setting to be added at the same time that the
endpoints from the old configuration or alt setting are dropped.

Endpoints must be added to the schedule before any URBs are submitted to
them.  The HCD must be allowed to reject a new configuration or alt
setting before the control transfer is sent to the device requesting the
change.  It may reject the change because there is not enough bandwidth,
not enough internal resources (such as memory on an embedded host
controller), or perhaps even for security reasons in a virtualized
environment.

If the call to check_bandwidth() fails, the USB core must call
reset_bandwidth().  This causes the schedule to be reverted back to the
state it was in just after the last successful check_bandwidth() call.

If the call succeeds, the host controller driver (and hardware) will have
changed its internal state to match the new configuration or alternate
setting.  The USB core can then issue a control transfer to the device to
change the configuration or alt setting.  This allows the core to test new
configurations or alternate settings before unbinding drivers bound to
interfaces in the old configuration.

WIP:

The USB core must add endpoints from all interfaces in a configuration
to the schedule, because a driver may claim that interface at any time.
A slight optimization might be to add the endpoints to the schedule once
a driver claims that interface.  FIXME

This patch does not cover changing alternate settings, but it does
handle a configuration change or de-configuration.  FIXME

The code for managing the schedule is currently HCD specific.  A generic
scheduling algorithm could be added for host controllers without
built-in scheduling support.  For now, if a host controller does not
define the check_bandwidth() function, the call to
usb_hcd_check_bandwidth() will always succeed.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add host controller driver API and a slot_id variable to struct
usb_device.  This allows the xHCI host controller driver to ask the
hardware to allocate a slot for the device when a struct usb_device is
allocated.  The slot needs to be allocated at that point because the
hardware can run out of internal resources, and we want to know that very
early in the device connection process.  Don't call this new API for root
hubs, since they aren't real devices.

Add HCD API to let the host controller choose the device address.  This is
especially important for xHCI hardware running in a virtualized
environment.  The guests running under the VM don't need to know which
addresses on the bus are taken, because the hardware picks the address for
them.  Announce SuperSpeed USB devices after the address has been assigned
by the hardware.

Don't use the new get descriptor/set address scheme with xHCI.  Unless
special handling is done in the host controller driver, the xHC can't
issue control transfers before you set the device address.  Support for
the older addressing scheme will be added when the xHCI driver supports
the Block Set Address Request (BSR) flag in the Address Device command.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Modify the USB core to handle the new USB 3.0 speed, "SuperSpeed".  This
is 5.0 Gbps (wire speed).  There are probably more places that check for
speed that I've missed.

SuperSpeed devices have a 512 byte endpoint 0 max packet size.  This shows
up as a bMaxPacketSize0 set to 0x09 (see table 9-8 of the USB 3.0 bus
spec).

xHCI spec says that the xHC can handle intervals up to 2^15 microframes.  That
might change when real silicon becomes available.

Add FIXME note for SuperSpeed isochronous endpoints.  They can transmit up
to 16 packets in one "burst" before they wait for an acknowledgment of the
packets.  They can do up to 3 bursts per microframe (determined by the
mult value in the endpoint companion descriptor).  The xHCI driver doesn't
have support for isoc yet, so fix this later.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add PCI initialization code to take control of the xHCI host controller
away from the BIOS, halt, and reset the host controller.  The xHCI spec
says that BIOSes must give up the host controller within 5 seconds.

Add some host controller glue functions to handle hardware initialization
and memory allocation for the host controller.  The current xHCI
prototypes use PCI interrupts, but the xHCI spec requires MSI-X
interrupts.  Add code to support MSI-X interrupts, but use the PCI
interrupts for now.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1237) changes the way the PCI host controller drivers
avoid retaining bogus hardware states during resume-from-hibernation.
Previously we had reset the hardware as part of preparing to reinstate
the memory image.  But we can do better now with the new PM framework,
since we know exactly which resume operations are from hibernation.

The pci_resume method is changed to accept a flag indicating whether
the system is resuming from hibernation.  When this flag is set, the
drivers will reset the hardware to get rid of any existing state.

Similarly, the pci_suspend method is changed to remove the
pm_message_t argument.  It's no longer needed, since no special action
has to be taken when preparing to reinstate the memory image.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1236) converts the USB PCI power management routines
over to the new PM framework.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Wireless USB endpoint state has a sequence number and a current
window and not just a single toggle bit.  So allow HCDs to provide a
endpoint_reset method and call this or clear the software toggles as
required (after a clear halt, set configuration etc.).

usb_settoggle() and friends are then HCD internal and are moved into
core/hcd.h and all device drivers call usb_reset_endpoint() instead.

If the device endpoint state has been reset (with a clear halt) but
the host endpoint state has not then subsequent data transfers will
not complete. The device will only work again after it is reset or
disconnected.
Signed-off-by: NDavid Vrabel <david.vrabel@csr.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

If a USB PCI controller is behind a cardbus bridge, we are trying to
restore its configuration registers too early, before the cardbus
bridge is operational.  To fix this, call pci_restore_state() from
usb_hcd_pci_resume() and remove usb_hcd_pci_resume_early() which is
no longer necessary (the configuration spaces of USB controllers that
are not behind cardbus bridges will be restored by the PCI PM core
with interrupts disabled anyway).

This patch fixes the regression from 2.6.28 tracked as
http://bugzilla.kernel.org/show_bug.cgi?id=12659

[ Side note: the proper long-term fix is probably to just force the
  unplug event at suspend time instead of doing a plug/unplug at resume
  time, but this patch is fine regardless  - Linus ]
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reported-by: NMiles Lane <miles.lane@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit a0d4922d
(USB: fix up suspend and resume for PCI host controllers) attempted
to fix the suspend-resume of PCI USB controllers, but unfortunately
it did that incorrectly and interrupts are left enabled by the USB
controllers' ->suspend_late() callback as a result.  This leads to
serious problems during suspend which are very difficult to debug.

Fix the issue by removing the ->suspend_late() callback of PCI
USB controllers and moving the code from there to the ->suspend()
callback executed with interrupts enabled.  Additionally, make
the ->resume() callback of PCI USB controllers execute
pci_enable_wake(dev, PCI_D0, false) to disable wake-up from the
full power state (PCI_D0).
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Tested-by: NAndrey Borzenkov <arvidjaar@mail.ru>
Tested-by: N"Jeff Chua" <jeff.chua.linux@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: "Zdenek Kabelac" <zdenek.kabelac@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1192) rearranges the USB PCI host controller suspend and
resume and resume routines:

	Use pci_wake_from_d3() for enabling and disabling wakeup,
	instead of pci_enable_wake().

	Carry out the actual state change while interrupts are
	disabled.

	Change the order of the preparations to agree with the
	general recommendation for PCI devices, instead of
	messing around with the wakeup settings while the device
	is in D3.

		In .suspend:
			Call the underlying driver to disable IRQ
				generation;
			pci_wake_from_d3(device_may_wakeup());
			pci_disable_device();

		In .suspend_late:
			pci_save_state();
			pci_set_power_state(D3hot);
			(for PPC_PMAC) Disable ASIC clocks

		In .resume_early:
			(for PPC_PMAC) Enable ASIC clocks
			pci_set_power_state(D0);
			pci_restore_state();

		In .resume:
			pci_enable_device();
			pci_set_master();
			pci_wake_from_d3(0);
			Call the underlying driver to reenable IRQ
				generation

	Add the necessary .suspend_late and .resume_early method
	pointers to the PCI host controller drivers.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1177) modifies the USB core suspend and resume
routines.  The resume functions now will take a pm_message_t argument,
so they will know what sort of resume is occurring.  The new argument
is also passed to the port suspend/resume and bus suspend/resume
routines (although they don't use it for anything but debugging).

In addition, special pm_message_t values are used for user-initiated,
device-initiated (i.e., remote wakeup), and automatic suspend/resume.
By testing these values, drivers can tell whether or not a particular
suspend was an autosuspend.  Unfortunately, they can't do the same for
resumes -- not until the pm_message_t argument is also passed to the
drivers' resume methods.  That will require a bigger change.

IMO, the whole Power Management framework should have been set up this
way in the first place.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

usbmon can only be built as a module if usbcore is a module too. Trivial
changes to the relevant Kconfig and Makefile (and a few trivial changes
elsewhere) allow usbmon to be built as a module even if usbcore is
builtin.

This is verified to work in all 9 permutations (3 correctly prohibited
by Kconfig, 6 build a suitable result).
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NPete Zaitcev <zaitcev@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This will let us use this header in other header files.
Will be needed for the FHCI USB Host driver.
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1151) protects usbcore against drivers that try to
unlink an URB after the URB's device or bus have been removed.  The
core does not currently check for this, and certain drivers can cause
a crash if they are running while an HCD is unloaded.

Certainly it would be best to fix the guilty drivers.  But a little
defensive programming doesn't hurt, especially since it appears that
quite a few drivers need to be fixed.

The patch prevents the problem by grabbing a reference to the device
while an unlink is in progress and using a new spinlock to synchronize
unlinks with device removal.  (There's no need to acquire a reference
to the bus as well, since the device structure itself keeps a
reference to the bus.)  In addition, the kerneldoc is updated to
indicate that URBs should not be unlinked after the disconnect method
returns.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1139) adds a warning to the system log whenever ehci-hcd
is loaded after ohci-hcd or uhci-hcd.  Nowadays most distributions are
pretty good about not doing this; maybe the warning will help convince
anyone still doing it wrong.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>  [2.6.27]
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1069c) changes the way OHCI root-hub status-change
interrupts are enabled.  Currently a special HCD method,
hub_irq_enable(), is called when the hub driver is finished using a
root hub.  This approach turns out to be subject to races, resulting
in unnecessary polling.

The patch does away with the method entirely.  Instead, the driver
automatically enables the RHSC interrupt when no more status changes
are present.  This scheme is safe with controllers using
level-triggered semantics for their interrupt flags.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We can't allow hubs on the 7th tier as they would allow
devices on the 8th tier.
Signed-off-by: NFelipe Balbi <felipe.balbi@nokia.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This changes usb_create_hcd() to be able to handle the fact that
pci_name() has changed to a constant string.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This reverts commit e8721549.

Andrey Borzenkov reports that it resulted in a totally hung machine for
him when loading the OHCI driver.  Extensive netconsole capture with
SysRq output shows that modprobe gets stuck in ohci_hub_status_data()
when probing and enabling the OHCI controller, see for example

	http://lkml.org/lkml/2008/7/5/236

for an analysis.

The problem appears to be an interrupt flood triggered by the commit
that gets reverted, and Andrey confirmed that the revert makes things
work for him again.
Reported-and-tested-by: NAndrey Borzenkov <arvidjaar@mail.ru>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NDavid Brownell <david-b@pacbell.net>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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: NAlan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1069b) changes the way OHCI root-hub status-change
interrupts are enabled.  Currently a special HCD method,
hub_irq_enable(), is called when the hub driver is finished using a
root hub.  This approach turns out to be subject to races, resulting
in unnecessary polling.

The patch does away with the method entirely.  Instead, the driver
automatically enables the RHSC interrupt when no more status changes
are present.  This scheme is safe with controllers using
level-triggered semantics for their interrupt flags.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The .suspend and .resume method pointers in struct usb_hcd have not
been fully understood by host-controller driver writers.  They are
meant for use with PCI controllers; other platform-specific drivers
generally should not refer to them.

To try and clarify matters, this patch (as1065) renames those methods
to .pci_suspend and .pci_resume.  It eliminates corresponding dead code
and bogus references in the ohci-ssb and u132-hcd drivers.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Currently EHCI root hubs enumerate with a bDeviceProtocol code
indicating that they possess a Transaction Translator.  However the
vast majority of controllers do not; they rely on a companion
controller to handle full- and low-speed communications.  This patch
(as1064) changes the root-hub device descriptor to match the actual
situation.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There's a new PM-related change notice for the USB 2.0 specification
called "Link Power Management" (LPM).  It defines a new "L1 Suspend"
state which resembles the current (L2) suspend state, except that it
can be entered and exited much more quickly.  It should thus be more
useful for runtime PM, even though it doesn't mandate reduced power
draw from VBUS.

This patch provides the relevant #defines for usbcore.  Actually
implementing these mechanisms requires host silicon that can generate
new USB packets, plus hubs handling some new requests and peripherals
which understand the new packets.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fixes a number of coding style issues in the USB internal header files.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

usb: dma bounce buffer support V4

This patch adds dma bounce buffer support to the usb core. These buffers
can be enabled with the HCD_LOCAL_MEM flag, and they make sure that all data
passed to the host controller is allocated using dma_alloc_coherent().
Signed-off-by: NMagnus Damm <damm@igel.co.jp>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch hands over the port to the companion when the
hub_port_connect_change fails.
Signed-off-by: NBalaji Rao <balajirrao@gmail.com>
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as999) fixes a problem that sometimes shows up when host
controller driver modules are loaded in the wrong order.  If ehci-hcd
happens to initialize an EHCI controller while the companion OHCI or
UHCI controller is in the middle of a port reset, the reset can fail
and the companion may get very confused.  The patch adds an
rw-semaphore and uses it to keep EHCI initialization and port resets
mutually exclusive.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NDavid Brownell <david-b@pacbell.net>
Cc: David Miller <davem@davemloft.net>
Cc: Dely L Sy <dely.l.sy@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as988) breaks usb_hcd_endpoint_disable() apart into two
routines.  The first, usb_hcd_flush_endpoint() does the -ESHUTDOWN
unlinking of all URBs in the endpoint's queue and waits for them to
complete.  The second, usb_hcd_disable_endpoint() -- renamed for
better grammatical style -- merely calls the HCD's endpoint_disable
method.  The changeover is easy because the routine currently has only
one caller.

This separation of function will be exploited in the following patch:
When a device is suspended, the core will be able to cancel all
outstanding URBs for that device while leaving the HCD's
endpoint-related data structures intact for later.

As an added benefit, HCDs no longer need to check for existing URBs in
their endpoint_disable methods.  It is now guaranteed that there will
be none.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as979) removes the last vestiges of urb->status from the
host controller drivers and the root-hub emulator.  Now the field
doesn't get set until just before the URB's completion routine is
called.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
CC: Olav Kongas <ok@artecdesign.ee>
CC: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
CC: Tony Olech <tony.olech@elandigitalsystems.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as978) reorganizes the way usbmon uses urb->status.  It
now accepts the status value as an argument.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NPete Zaitcev <zaitcev@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as954) implements a suggestion of David Brownell's.  Now
the host controller drivers are responsible for linking and unlinking
URBs to/from their endpoint queues.  This eliminates the possiblity of
strange situations where usbcore thinks an URB is linked but the HCD
thinks it isn't.  It also means HCDs no longer have to check for URBs
being dequeued before they were fully enqueued.

In addition to the core changes, this requires changing every host
controller driver and the root-hub URB handler.  For the most part the
required changes are fairly small; drivers have to call
usb_hcd_link_urb_to_ep() in their urb_enqueue method,
usb_hcd_check_unlink_urb() in their urb_dequeue method, and
usb_hcd_unlink_urb_from_ep() before giving URBs back.  A few HCDs make
matters more complicated by the way they split up the flow of control.

In addition some method interfaces get changed.  The endpoint argument
for urb_enqueue is now redundant so it is removed.  The unlink status
is required by usb_hcd_check_unlink_urb(), so it has been added to
urb_dequeue.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
CC: Olav Kongas <ok@artecdesign.ee>
CC: Tony Olech <tony.olech@elandigitalsystems.com>
CC: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This introduces /sys/bus/devices/usb*/authorized_default; it dictates
what is going to be the default authorization state for devices
connected to the host. User space can set that using the sysfs file.

We hook to the root hub instead of to the device controller as it is
quite easy to get to it in sysfs from the device structure (device
5-4.3 is usb5) vs. backtracking to the controller device.

By default it is set to be 'authorized' (!0) for normal, wired USB
devices and 'unauthorized' (0) for Wireless USB devices.

As suggested by Adrian Bunk, make authorized_default static
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as916) completes the separation of code paths for suspend
and resume of root hubs as opposed to non-root devices.  Root hubs
will be power-managed through their bus_suspend and bus_resume
methods, whereas normal devices will use usb_port_suspend() and
usb_port_resume().

Changes to the hcd_bus_{suspend,resume} routines mostly represent
motion of code that was already present elsewhere.  They include:

	Adding debugging log messages,

	Setting the device state appropriately, and

	Adding a resume recovery time delay.

Changes to the port-suspend and port-resume routines in hub.c include:

	Removal of checks for root devices (since they will never
	be triggered), and

	Removal of checks for NULL or invalid device pointers (these
	were left over from earlier kernel versions and aren't needed
	at all).
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as866) adds new entry points for external USB device
suspend and resume requests, as opposed to internally-generated
autosuspend or autoresume.  It also changes the existing
remote-wakeup code paths to use the new routines, since remote wakeup
is not the same as autoresume.

As part of the change, it turns out to be necessary to do remote
wakeup of root hubs from a workqueue.  We had been using khubd, but it
does autoresume rather than an external resume.  Using the
ksuspend_usb_wq workqueue for this purpose seemed a logical choice.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as841) removes from usbcore a couple of support routines
meant to help with bandwidth allocation.  With the changes to uhci-hcd
in the previous patch, these routines are no longer used anywhere.
Also removed is the CONFIG_USB_BANDWIDTH option; it no longer does
anything and is no longer needed since the HCDs now handle bandwidth
issues correctly.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.

The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around.  On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).

Where appropriate, an arch may override the generic storage facility and do
something different with the variable.  On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.

Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions.  Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller.  A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.

I've build this code with allyesconfig for x86_64 and i386.  I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.

This will affect all archs.  Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:

	struct pt_regs *old_regs = set_irq_regs(regs);

And put the old one back at the end:

	set_irq_regs(old_regs);

Don't pass regs through to generic_handle_irq() or __do_IRQ().

In timer_interrupt(), this sort of change will be necessary:

	-	update_process_times(user_mode(regs));
	-	profile_tick(CPU_PROFILING, regs);
	+	update_process_times(user_mode(get_irq_regs()));
	+	profile_tick(CPU_PROFILING);

I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().

Some notes on the interrupt handling in the drivers:

 (*) input_dev() is now gone entirely.  The regs pointer is no longer stored in
     the input_dev struct.

 (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking.  It does
     something different depending on whether it's been supplied with a regs
     pointer or not.

 (*) Various IRQ handler function pointers have been moved to type
     irq_handler_t.
Signed-Off-By: NDavid Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)

This patch (as740) removes the existing support for autosuspend of
root hubs.  That support fit in rather awkwardly with the rest of
usbcore and it was used only by ohci-hcd.  It won't be needed any more
since the hub driver will take care of autosuspending all hubs, root
or external.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

As part of the ongoing program to flatten out the HCD bus-glue layer,
this patch (as771b) eliminates the hcpriv, release, and kref fields
from struct usb_bus.  hcpriv and release were not being used for
anything worthwhile, and kref has been moved into the enclosing
usb_hcd structure.

Along with those changes, the patch gets rid of usb_bus_get and
usb_bus_put, replacing them with usb_get_hcd and usb_put_hcd.

The one interesting aspect is that the dev_set_drvdata call was
removed from usb_put_hcd, where it clearly doesn't belong.  This means
the driver private data won't get reset to NULL.  It shouldn't cause
any problems, since the private data is undefined when no driver is
bound.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>