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

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>

Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

When `echo Y > /sys/module/usbcore/parameters/usbfs_snoop` and
usb_control_msg() returns error, a lot of kernel memory is dumped to dmesg
until unhandled kernel paging request occurs.
Signed-off-by: NMichal Sojka <sojkam1@fel.cvut.cz>
Cc: stable@kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

USB defines usb_device_type pointing to usb_device_pm_ops that
provides system-wide PM callbacks only and usb_bus_type pointing to
usb_bus_pm_ops that provides runtime PM callbacks only.  However,
the USB runtime PM callbacks may be defined in usb_device_pm_ops
which makes it possible to drop usb_bus_pm_ops and will allow us
to consolidate the handling of subsystems by the PM core code.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>

After redefining CONFIG_PM to depend on (CONFIG_PM_SLEEP ||
CONFIG_PM_RUNTIME) the CONFIG_PM_OPS option is redundant and can be
replaced with CONFIG_PM.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

A subsequent patch will modify device_set_wakeup_capable() in such
a way that it will call functions which may sleep and therefore it
shouldn't be called under spinlocks.  In preparation to that, modify
usb_set_device_state() to avoid calling device_set_wakeup_capable()
under device_state_lock.
Tested-by: NMinchan Kim <minchan.kim@gmail.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>

Use the Mult and bMaxBurst values from the endpoint companion
descriptor to calculate the max length of an isoc transfer.

Add USB_SS_MULT macro to access Mult field of bmAttributes, at
Sarah's suggestion.

This patch should be queued for the 2.6.36 and 2.6.37 stable trees, since
those were the first kernels to have isochronous support for SuperSpeed
devices.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

USB 3.0 devices have a slightly different suspend sequence than USB
2.0/1.1 devices.  There isn't support for USB 3.0 device suspend yet, so
make khubd leave autosuspend disabled for USB 3.0 hubs.  Make sure that
USB 3.0 roothubs still have autosuspend enabled, since that path in the
xHCI driver works fine.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

USB_PORT_STAT_SUPER_SPEED is a made up symbol that the USB core used to
track whether USB ports had a SuperSpeed device attached.  This is a
linux-internal symbol that was used when SuperSpeed and non-SuperSpeed
devices would show up under the same xHCI roothub.  This particular
port status is never returned by external USB 3.0 hubs.  (Instead they
have a USB_PORT_STAT_SPEED_5GBPS that uses a completely different speed
mask.)

Now that the xHCI driver registers two roothubs, USB 3.0 devices will only
show up under USB 3.0 hubs.  Rip out USB_PORT_STAT_SUPER_SPEED and replace
it with calls to hub_is_superspeed().
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The hcd->flags are in a sorry state.  Some of them are clearly specific to
the particular roothub (HCD_POLL_RH, HCD_POLL_PENDING, and
HCD_WAKEUP_PENDING), but some flags are related to PCI device state
(HCD_HW_ACCESSIBLE and HCD_SAW_IRQ).  This is an issue when one PCI device
can have two roothubs that share the same IRQ line and hardware.

Make sure to set HCD_FLAG_SAW_IRQ for both roothubs when an interrupt is
serviced, or an URB is unlinked without an interrupt.  (We can't tell if
the host actually serviced an interrupt for a particular bus, but we can
tell it serviced some interrupt.)

HCD_HW_ACCESSIBLE is set once by usb_add_hcd(), which is set for both
roothubs as they are added, so it doesn't need to be modified.
HCD_POLL_RH and HCD_POLL_PENDING are only checked by the USB core, and
they are never set by the xHCI driver, since the roothub never needs to be
polled.

The usb_hcd's state field is a similar mess.  Sometimes the state applies
to the underlying hardware: HC_STATE_HALT, HC_STATE_RUNNING, and
HC_STATE_QUIESCING.  But sometimes the state refers to the roothub state:
HC_STATE_RESUMING and HC_STATE_SUSPENDED.

Alan Stern recently made the USB core not rely on the hcd->state variable.
Internally, the xHCI driver still checks for HC_STATE_SUSPENDED, so leave
that code in.  Remove all references to HC_STATE_HALT, since the xHCI
driver only sets and doesn't test those variables.  We still have to set
HC_STATE_RUNNING, since Alan's patch has a bug that means the roothub
won't get registered if we don't set that.

Alan's patch made the USB core check a different variable when trying to
determine whether to suspend a roothub.  The xHCI host has a split
roothub, where two buses are registered for one PCI device.  Each bus in
the xHCI split roothub can be suspended separately, but both buses must be
suspended before the PCI device can be suspended.  Therefore, make sure
that the USB core checks HCD_RH_RUNNING() for both roothubs before
suspending the PCI host.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Introduce the notion of a PCI device that may be associated with more than
one USB host controller driver (struct usb_hcd).  This patch is the start
of the work to separate the xHCI host controller into two roothubs: a USB
3.0 roothub with SuperSpeed-only ports, and a USB 2.0 roothub with
HS/FS/LS ports.

One usb_hcd structure is designated to be the "primary HCD", and a pointer
is added to the usb_hcd structure to keep track of that.  A new function
call, usb_hcd_is_primary_hcd() is added to check whether the USB hcd is
marked as the primary HCD (or if it is not part of a roothub pair).  To
allow the USB core and xHCI driver to access either roothub in a pair, a
"shared_hcd" pointer is added to the usb_hcd structure.

Add a new function, usb_create_shared_hcd(), that does roothub allocation
for paired roothubs.  It will act just like usb_create_hcd() did if the
primary_hcd pointer argument is NULL.  If it is passed a non-NULL
primary_hcd pointer, it sets usb_hcd->shared_hcd and usb_hcd->primary_hcd
fields.  It will also skip the bandwidth_mutex allocation, and set the
secondary hcd's bandwidth_mutex pointer to the primary HCD's mutex.

IRQs are only allocated once for the primary roothub.

Introduce a new usb_hcd driver flag that indicates the host controller
driver wants to create two roothubs.  If the HCD_SHARED flag is set, then
the USB core PCI probe methods will allocate a second roothub, and make
sure that second roothub gets freed during rmmod and in initialization
error paths.

When usb_hc_died() is called with the primary HCD, make sure that any
roothubs that share that host controller are also marked as being dead.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The xHCI driver essentially has both a USB 2.0 and a USB 3.0 roothub.  So
setting the HCD_USB3 bits in the hcd->driver->flags is a bit misleading.
Add a new field to usb_hcd, bcdUSB.  Store the result of
hcd->driver->flags & HCD_MASK in it.  Later, when we have the xHCI driver
register the two roothubs, we'll set the usb_hcd->bcdUSB field to HCD_USB2
for the USB 2.0 roothub, and HCD_USB3 for the USB 3.0 roothub.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Change the bandwith_mutex in struct usb_hcd to a pointer.  This will allow
the pointer to be shared across usb_hcds for the upcoming work to split
the xHCI driver roothub into a USB 2.0/1.1 and a USB 3.0 bus.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Refactor out the code in usb_add_hcd() to request the IRQ line for the
HCD.  This will only need to be called once for the two xHCI roothubs, so
it's easier to refactor it into a function, rather than wrapping the long
if-else block into another if statement.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Make the labels for the goto statements in usb_hcd_pci_probe()
describe the cleanup they do, rather than being numbered err[1-4].
This makes it easier to add error handling later.

The error handling for this function looks a little fishy, since
set_hs_companion() isn't called until the very end of the function, and
clear_hs_companion() is called if this function fails earlier than that.
But it should be harmless to clear a NULL pointer, so leave the error
handling as-is.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Make the USB 3.0 roothub registered by the USB core have a SuperSpeed
Endpoint Companion Descriptor after the interrupt endpoint.  All USB 3.0
devices are required to have this, and the USB 3.0 bus specification
(section 10.13.1) says which values the descriptor should have.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

In USB 3.0, there are two types of resets: a "hot" port reset and a "warm"
port reset.  The hot port reset is always tried first, and involves
sending the reset signaling for a shorter amount of time.  But sometimes
devices don't respond to the hot reset, and a "Bigger Hammer" is needed.

External hubs and roothubs will automatically try a warm reset when the
hot reset fails, and they will set a status change bit to indicate when
there is a "BH reset" change.  Make sure the USB core clears that port
status change bit, or we'll get lots of status change notifications on the
interrupt endpoint of the USB 3.0 hub.

(Side note: you may be confused why the USB 3.0 spec calls the same type
of reset "warm reset" in some places and "BH reset" in other places.  "BH"
reset is supposed to stand for "Big Hammer" reset, but it also stands for
"Brad Hosler".  Brad died shortly after the USB 3.0 bus specification was
started, and they decided to name the reset after him.  The suggestion was
made shortly before the spec was finalized, so the wording is a bit
inconsistent.)
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Update the USB core to deal with USB 3.0 hubs.  These hubs have a slightly
different hub descriptor than USB 2.0 hubs, with a fixed (rather than
variable length) size.  Change the USB core's hub descriptor to have a
union for the last fields that differ.  Change the host controller drivers
that access those last fields (DeviceRemovable and PortPowerCtrlMask) to
use the union.

Translate the new version of the hub port status field into the old
version that khubd understands.  (Note: we need to fix it to translate the
roothub's port status once we stop converting it to USB 2.0 hub status
internally.)

Add new code to handle link state change status.  Send out new control
messages that are needed for USB 3.0 hubs, like Set Hub Depth.

This patch is a modified version of the original patch submitted by John
Youn.  It's updated to reflect the removal of the "bitmap" #define, and
change the hub descriptor accesses of a couple new host controller
drivers.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Cc: Tony Olech <tony.olech@elandigitalsystems.com>
Cc: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: Max Vozeler <mvz@vozeler.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Rodolfo Giometti <giometti@linux.it>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Anton Vorontsov <avorontsov@mvista.com>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Cc: Lothar Wassmann <LW@KARO-electronics.de>
Cc: Olav Kongas <ok@artecdesign.ee>
Cc: Martin Fuzzey <mfuzzey@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <dbrownell@users.sourceforge.net>

We would like to allow host controller drivers to stop using hcd->state.
Unfortunately, some host controller drivers use hcd->state as an
implicit way of telling the core that a controller has died.  The
roothub registration functions must assume the host died if hcd->state
equals HC_STATE_HALT.

To facilitate drivers that don't want to set hcd->state to
HC_STATE_RUNNING in their initialization routines, we set the state to
running before calling the host controller's start function.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The irq enabling code is going to be refactored into a new function, so
clean up some checkpatch errors before moving it.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The PM core reacts badly when the return code from usb_runtime_suspend()
is not 0, -EAGAIN, or -EBUSY.  The PM core regards this as a fatal error,
and refuses to run anymore PM helper functions.  In particular,
usbfs_open() and other usbfs functions will fail because the PM core will
return an error code when usb_autoresume_device() is called.  This causes
libusb and/or lsusb to either hang or segfault.

If a USB device cannot suspend for some reason (e.g. a hub doesn't report
it has remote wakeup capabilities), we still want lsusb and other
userspace programs to work.  So return -EBUSY, which will fill people's
log files with failed tries, but will ensure userspace still works.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

On a laptop I see these errors on (most) resumes:
    hub 3-0:1.0: over-current change on port 1
    hub 3-0:1.0: over-current change on port 2

Since over-current conditions can disappear quite quickly it's better to
downgrade that message to debug level, recheck for an over-current
condition a little later and only print and over-current condition error
if that condition (still) exists when it's rechecked.

Add similar logic to hub over-current changes. (That code is untested,
as those changes do not occur on this laptop.)
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The hcd->state variable is a disaster.  It's not clearly owned by
either usbcore or the host controller drivers, and they both change it
from time to time, potentially stepping on each other's toes.  It's
not protected by any locks.  And there's no mechanism to prevent it
from going through an invalid transition.

This patch (as1451) takes a first step toward fixing these problems.
As it turns out, usbcore uses hcd->state for essentially only two
things: checking whether the controller's root hub is running and
checking whether the controller has died.  Therefore the patch adds
two new atomic bitflags to the hcd structure, to store these pieces of
information.  The new flags are used only by usbcore, and a private
spinlock prevents invalid combinations (a dead controller's root hub
cannot be running).

The patch does not change the places where usbcore sets hcd->state,
since HCDs may depend on them.  Furthermore, there is one place in
usb_hcd_irq() where usbcore still must use hcd->state: An HCD's
interrupt handler can implicitly indicate that the controller died by
setting hcd->state to HC_STATE_HALT.  Nevertheless, the new code is a
big improvement over the current code.

The patch makes one other change.  The hcd_bus_suspend() and
hcd_bus_resume() routines now check first whether the host controller
has died; if it has then they return immediately without calling the
HCD's bus_suspend or bus_resume methods.

This fixes the major problem reported in Bugzilla #29902: The system
fails to suspend after a host controller dies during system resume.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NAlex Terekhov <a.terekhov@gmail.com>
CC: <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The Patch below removes one to many "n's" in a word..
Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
CC: Alan Stern <stern@rowland.harvard.edu>
CC: linux-usb@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The USB stack historically has conflated device numbers (i.e., the
value of udev->devnum) with device addresses.  This is understandable,
because until recently the two values were always the same.

But with USB-3.0 they aren't the same, so we should start calling
these things by their correct names.  This patch (as1449b) changes many
of the references to "address" in the hub driver to "device number"
or "devnum".

The patch also removes some unnecessary or misleading comments.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NLuben Tuikov <ltuikov@yahoo.com>
Reviewed-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

If the device isn't reset, the XHCI HCD sends
SET ADDRESS to address 0 while the device is
already in Addressed state, and the request is
dropped on the floor as it is addressed to the
default address. This sequence of events, which this
patch fixes looks like this:

usb_reset_and_verify_device()
	hub_port_init()
		hub_set_address()
			SET_ADDRESS to 0 with 1
		usb_get_device_descriptor(udev, 8)
		usb_get_device_descriptor(udev, 18)
	descriptors_changed() --> goto re_enumerate:
		hub_port_logical_disconnect()
			kick_khubd()

And then:

hub_events()
	hub_port_connect_change()
		usb_disconnect()
			usb_disable_device()
		new device struct
		sets device state to Powered
		choose_address()
		hub_port_init() <-- no reset, but SET ADDRESS to 0 with 1, timeout!

The solution is to always reset the device in
hub_port_init() to put it in a known state.

Note from Sarah Sharp:

This patch should be queued for stable trees all the way back to 2.6.34,
since that was the first kernel that supported configured device reset.
The code this patch touches has been there since 2.6.32, but the bug
would never be hit before 2.6.34 because the xHCI driver would
completely reject an attempt to reset a configured device under xHCI.
Signed-off-by: NLuben Tuikov <ltuikov@yahoo.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

This reverts commit 637d11bf.  Sarah
wants to tweak it some more before it's applied to the tree.

Cc: Luben Tuikov <ltuikov@yahoo.com>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

If the device isn't reset, the XHCI HCD sends
SET ADDRESS to address 0 while the device is
already in Addressed state, and the request is
dropped on the floor as it is addressed to the
default address. This sequence of events, which this
patch fixes looks like this:

usb_reset_and_verify_device()
	hub_port_init()
		hub_set_address()
			SET_ADDRESS to 0 with 1
		usb_get_device_descriptor(udev, 8)
		usb_get_device_descriptor(udev, 18)
	descriptors_changed() --> goto re_enumerate:
		hub_port_logical_disconnect()
			kick_khubd()

And then:

hub_events()
	hub_port_connect_change()
		usb_disconnect()
			usb_disable_device()
		new device struct
		sets device state to Powered
		choose_address()
		hub_port_init() <-- no reset, but SET ADDRESS to 0 with 1, timeout!

The solution is to always reset the device in
hub_port_init() to put it in a known state.
Signed-off-by: NLuben Tuikov <ltuikov@yahoo.com>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

My Galaxy Spica needs this quirk when in modem mode, otherwise
it causes endless USB bus resets and is unusable in this mode.

Unfortunately Samsung decided to reuse ID of its old CDMA phone SGH-I500
for the modem part.
That's why in addition to this patch the visor driver must be prevented
from binding to SPH-I500 ID, so ACM driver can do that.
Signed-off-by: NMaciej Szmigiero <mhej@o2.pl>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1448) adds a quirks entry for the Keytouch QWERTY Panel
firmware, used in the IEC 60945 keyboard.  This device crashes during
enumeration when the computer asks for its configuration string
descriptor.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: Nkholis <nur.kholis.majid@gmail.com>
CC: <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Provide optional hooks for the host controller driver to override the
default DMA mapping and unmapping routines.  In general, these shouldn't
be necessary unless the host controller has special DMA requirements,
such as alignment contraints.  If these are not specified, the
general usb_hcd_(un)?map_urb_for_dma functions will be used instead.
Also, pass the status to unmap_urb_for_dma so it can know whether the
DMA buffer has been overwritten.

Finally, add a flag to be used by these implementations if they
allocated a temporary buffer so it can be freed properly when unmapping.
Signed-off-by: NRobert Morell <rmorell@nvidia.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The convention is to prefix symbols exported from the USB HCD core with
"usb_hcd".  This change makes unmap_urb_setup_for_dma() and
unmap_urb_for_dma() consistent with that.
Signed-off-by: NRobert Morell <rmorell@nvidia.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The USB core keeps track of pending resume requests for root hubs, in
order to resolve races between wakeup requests and suspends.  However
the code that does this is subject to another race (between wakeup
requests and resumes) because the WAKEUP_PENDING flag is cleared
before the resume occurs, leaving a window in which another wakeup
request might arrive.

This patch (as1447) fixes the problem by clearing the WAKEUP_PENDING
flag after the resume instead of before it.

This fixes Bugzilla #24952.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NPaul Bender <pebender@san.rr.com>
Tested-by: Nwarpme <warpme@o2.pl>
Cc: stable <stable@kernel.org> [.36+]
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

If anyone comes across a high-speed hub that (by mistake or by design)
claims to have no Transaction Translators, plugging a full- or
low-speed device into it will cause the USB stack to crash.  This
patch (as1446) prevents the problem by ignoring such devices, since
the kernel has no way to communicate with them.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NPerry Neben <neben@vmware.com>
CC: <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fixing all coding style issues in buffer.c
Signed-off-by: NTobias Ollmann <tobias.ollmann@gmx.at>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This converts error codes specific to USB to generic error codes
that can be returned to user space. Tests showed that it is so small
that it is better inlined.
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The dev->power.async_suspend can only be set at the condition of
dev->power.status is DPM_ON. The dev->power.status will be initialized
as DPM_ON at device_initialize.
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
is used to configure any non-standard kernel with a much larger scope than
only small devices.

This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
references to the option throughout the kernel.  A new CONFIG_EMBEDDED
option is added that automatically selects CONFIG_EXPERT when enabled and
can be used in the future to isolate options that should only be
considered for embedded systems (RISC architectures, SLOB, etc).

Calling the option "EXPERT" more accurately represents its intention: only
expert users who understand the impact of the configuration changes they
are making should enable it.
Reviewed-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NDavid Woodhouse <david.woodhouse@intel.com>
Signed-off-by: NDavid Rientjes <rientjes@google.com>
Cc: Greg KH <gregkh@suse.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Robin Holt <holt@sgi.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>