There are various functions within the USB core that will need to
disable USB 3.0 link power states.  For example, when a USB device
driver is being bound to an interface, we need to disable USB 3.0 LPM
until we know if the driver will allow hub-initiated LPM transitions.
Another example is when the USB core is switching alternate interface
settings.  The USB 3.0 timeout values are dependent on what endpoints
are enabled, so we want to ensure that LPM is disabled until the new alt
setting is fully installed.

Multiple functions need to disable LPM, and those functions can even be
nested.  For example, usb_bind_interface() could disable LPM, and then
call into the driver probe function, which may attempt to switch to a
different alt setting.  Therefore, we need to keep a count of the number
of functions that require LPM to be disabled at any point in time.

Introduce two new USB core API calls, usb_disable_lpm() and
usb_enable_lpm().  These functions increment and decrement a new
variable in the usb_device, lpm_disable_count.  If usb_disable_lpm()
fails, it will call usb_enable_lpm() in order to balance the
lpm_disable_count.

These two new functions must be called with the bandwidth_mutex locked.
If the bandwidth_mutex is not already held by the caller, it should
instead call usb_unlocked_disable_lpm() and usb_enable_lpm(), which take
the bandwidth_mutex before calling usb_disable_lpm() and
usb_enable_lpm(), respectively.

Introduce a new variable (timeout) in the usb3_lpm_params structure to
keep track of the currently enabled U1/U2 timeout values.  When
usb_disable_lpm() is called, and the USB device has the U1 or U2
timeouts set to a non-zero value (meaning either device-initiated or
hub-initiated LPM is enabled), attempt to disable LPM, regardless of the
state of the lpm_disable_count.  We want to ensure that all callers can
be guaranteed that LPM is disabled if usb_disable_lpm() returns zero.

Otherwise the following scenario could occur:

1. Driver A is being bound to interface 1.  usb_probe_interface()
disables LPM.  Driver A doesn't care if hub-initiated LPM is enabled, so
even though usb_disable_lpm() fails, the probe of the driver continues,
and the bandwidth mutex is dropped.

2. Meanwhile, Driver B is being bound to interface 2.
usb_probe_interface() grabs the bandwidth mutex and calls
usb_disable_lpm().  That call should attempt to disable LPM, even
though the lpm_disable_count is set to 1 by Driver A.

For usb_enable_lpm(), we attempt to enable LPM only when the
lpm_disable_count is zero.  If some step in enabling LPM fails, it will
only have a minimal impact on power consumption, and all USB device
drivers should still work properly.  Therefore don't bother to return
any error codes.

Don't enable device-initiated LPM if the device is unconfigured.  The
USB device will only accept the U1/U2_ENABLE control transfers in the
configured state.  Do enable hub-initiated LPM in that case, since
devices are allowed to accept the LGO_Ux link commands in any state.

Don't enable or disable LPM if the device is marked as not being LPM
capable.  This can happen if:
 - the USB device doesn't have a SS BOS descriptor,
 - the device's parent hub has a zeroed bHeaderDecodeLatency value, or
 - the xHCI host doesn't support LPM.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

USB 3.0 Link Power Management (LPM) is designed to allow individual
links in the bus to go into lower power states.  There are two ways a
link can enter a lower power state:

1. Device-initiated LPM.  When a USB device decides it can go into a
lower power link state, it sends a message to the parent hub, telling it
to go into either U1 or U2.  Device-initiated LPM is good for devices
that send data to the host, like communications devices.

2. Hub-initiated LPM.  After the link has been idle for a specific
amount of time, the parent hub will request that the child go into a
lower power state.  The child can refuse that request.  For example, a
USB modem may want to refuse the LPM request if it is in the middle of
receiving a text message.  Hub-initiated LPM is good for devices where
only the host initiates the data transfer, like USB printers or USB mass
storage devices.

Links will be automatically placed into higher power states by the USB
hubs and roothubs whenever the host starts a USB transmission.

Introduce a new usb_driver flag, disable_hub_initiated_lpm, that allows
drivers to disable hub-initiated LPM.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: Hansjoerg Lipp <hjlipp@web.de>
Cc: Tilman Schmidt <tilman@imap.cc>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Oliver Neukum <oliver@neukum.name>
Cc: Peter Korsgaard <jacmet@sunsite.dk>
Cc: Jan Dumon <j.dumon@option.com>
Cc: Petko Manolov <petkan@users.sourceforge.net>
Cc: Steve Glendinning <steve.glendinning@smsc.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
Cc: Jouni Malinen <jouni@qca.qualcomm.com>
Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: Brett Rudley <brudley@broadcom.com>
Cc: Roland Vossen <rvossen@broadcom.com>
Cc: Arend van Spriel <arend@broadcom.com>
Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
Cc: Kan Yan <kanyan@broadcom.com>
Cc: Dan Williams <dcbw@redhat.com>
Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Cc: Ivo van Doorn <IvDoorn@gmail.com>
Cc: Gertjan van Wingerde <gwingerde@gmail.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: Herton Ronaldo Krzesinski <herton@canonical.com>
Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Chaoming Li <chaoming_li@realsil.com.cn>
Cc: Daniel Drake <dsd@gentoo.org>
Cc: Ulrich Kunitz <kune@deine-taler.de>
Cc: linux-bluetooth@vger.kernel.org
Cc: gigaset307x-common@lists.sourceforge.net
Cc: netdev@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: ath9k-devel@lists.ath9k.org
Cc: libertas-dev@lists.infradead.org
Cc: users@rt2x00.serialmonkey.com

There are several different exit latencies associated with coming out of
the U1 or U2 lower power link state.

Device Exit Latency (DEL) is the maximum time it takes for the USB
device to bring its upstream link into U0.  That can be found in the
SuperSpeed Extended Capabilities BOS descriptor for the device.  The
time it takes for a particular link in the tree to exit to U0 is the
maximum of either the parent hub's U1/U2 DEL, or the child's U1/U2 DEL.

Hubs introduce a further delay that effects how long it takes a child
device to transition to U0.  When a USB 3.0 hub receives a header
packet, it takes some time to decode that header and figure out which
downstream port the packet was destined for.  If the port is not in U0,
this hub header decode latency will cause an additional delay for
bringing the child device to U0.  This Hub Header Decode Latency is
found in the USB 3.0 hub descriptor.

We can use DEL and the header decode latency, along with additional
latencies imposed by each additional hub tier, to figure out the exit
latencies for both host-initiated and device-initiated exit to U0.

The Max Exit Latency (MEL) is the worst-case time it will take for a
host-initiated exit to U0, based on whether U1 or U2 link states are
enabled.  The ping or packet must traverse the path to the device, and
each hub along the way incurs the hub header decode latency in order to
figure out which device the transfer was bound for.  We say worst-case,
because some hubs may not be in the lowest link state that is enabled.
See the examples in section C.2.2.1.

Note that "HSD" is a "host specific delay" that the power appendix
architect has not been able to tell me how to calculate.  There's no way
to get HSD from the xHCI registers either, so I'm simply ignoring it.

The Path Exit Latency (PEL) is the worst-case time it will take for a
device-initiate exit to U0 to place all the links from the device to the
host into U0.

The System Exit Latency (SEL) is another device-initiated exit latency.
SEL is useful for USB 3.0 devices that need to send data to the host at
specific intervals.  The device may send an NRDY to indicate it isn't
ready to send data, then put its link into a lower power state.  If it
needs to have that data transmitted at a specific time, it can use SEL
to back calculate when it will need to bring the link back into U0 to
meet its deadlines.

SEL is the worst-case time from the device-initiated exit to U0, to when
the device will receive a packet from the host controller.  It includes
PEL, the time it takes for an ERDY to get to the host, a host-specific
delay for the host to process that ERDY, and the time it takes for the
packet to traverse the path to the device.  See Figure C-2 in the USB
3.0 bus specification.

Note: I have not been able to get good answers about what the
host-specific delay to process the ERDY should be.  The Intel HW
developers say it will be specific to the platform the xHCI host is
integrated into, and they say it's negligible.  Ignore this too.

Separate from these four exit latencies are the U1/U2 timeout values we
program into the parent hubs.  These timeouts tell the hub to attempt to
place the device into a lower power link state after the link has been
idle for that amount of time.

Create two arrays (one for U1 and one for U2) to store mel, pel, sel,
and the timeout values.  Store the exit latency values in nanosecond
units, since that's the smallest units used (DEL is in us, but the Hub
Header Decode Latency is in ns).

If a USB 3.0 device doesn't have a SuperSpeed Extended Capabilities BOS
descriptor, it's highly unlikely it will be able to handle LPM requests
properly.  So it's best to disable LPM for devices that don't have this
descriptor, and any children beneath it, if it's a USB 3.0 hub.  Warn
users when that happens, since it means they have a non-compliant USB
3.0 device or hub.

This patch assumes a simplified design where links deep in the tree will
not have U1 or U2 enabled unless all their parent links have the
corresponding LPM state enabled.  Eventually, we might want to allow a
different policy, and we can revisit this patch when that happens.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>

Refactor the code that sets the usb_device flag to indicate the device
support link power management (lpm_capable).  The current code sets
lpm_capable unconditionally if the USB devices have a USB 2.0 Extended
Capabilities Descriptor.  USB 3.0 devices can also have that descriptor,
but the xHCI driver code that uses lpm_capable will not run the USB 2.0
LPM test for devices under the USB 3.0 roothub.  Therefore, it's fine
only set lpm_capable for high speed devices in this refactoring.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

The BOS descriptor is normally fetched and stored in the usb_device->bos
during enumeration.  USB 3.0 roothubs don't undergo enumeration, but we
need them to have a BOS descriptor, since each xHCI host has a different
U1 and U2 exit latency.  Make sure to fetch the BOS descriptor for USB
3.0 roothubs.  It will be freed when the roothub usb_device is released.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>

USB 3.0 hubs can be put into a mode where the hub can automatically
request that the link go into a deeper link power state after the link
has been idle for a specified amount of time.  Each of the new USB 3.0
link states (U1 and U2) have their own timeout that can be programmed
per port.

Change the xHCI roothub emulation code to handle the request to set the
U1 and U2 timeouts.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

When the xHCI driver needs to clean up memory (perhaps due to a failed
register restore on resume from S3 or resume from S4), it needs to reset
the number of reserved TRBs on the command ring to zero.  Otherwise,
several resume cycles (about 30) with a UAS device attached will
continually increment the number of reserved TRBs, until all command
submissions fail because there isn't enough room on the command ring.

This patch should be backported to kernels as old as 2.6.32,
that contain the commit 913a8a34
"USB: xhci: Change how xHCI commands are handled."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

Some more data structures must be freed and counters
reset if an XHCI controller has lost power. The failure
to do so renders some chips inoperative after a certain number
of S4 cycles.

This patch should be backported to kernels as old as 3.2,
that contain the commits c29eea62
"xhci: Implement HS/FS/LS bandwidth checking." and
commit 839c817c
"xhci: Implement HS/FS/LS bandwidth checking."
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

USB2 LPM is disabled when device begin to suspend and enabled after device
is resumed. That's because USB spec does not define the transition from
U1/U2 state to U3 state.

If usb_port_suspend() fails, usb_port_resume() is never called, and USB2 LPM
is disabled in this situation. Enable USB2 LPM if port suspend fails.

This patch should be backported to kernels as old as 3.2, that contain
the commit 65580b43 "xHCI: set USB2
hardware LPM".
Signed-off-by: Andiry Xu <andiry.xu@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

Sergio reported that when he recorded audio from a USB headset mic
plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
"robotic".  When plugged into the USB 2.0 port under EHCI on the same
laptop, the audio sounded fine.  The device is:

Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset

The problem was tracked down to the Fresco Logic xHCI host controller
not correctly reporting short transfers on isochronous IN endpoints.
The driver would submit a 96 byte transfer, the device would only send
88 or 90 bytes, and the xHCI host would report the transfer had a
"successful" completion code, with an untransferred buffer length of 8
or 6 bytes.

The successful completion code and non-zero untransferred length is a
contradiction.  The xHCI host is supposed to only mark a transfer as
successful if all the bytes are transferred.  Otherwise, the transfer
should be marked with a short packet completion code.  Without the EHCI
bus trace, we wouldn't know whether the xHCI driver should trust the
completion code or the untransferred length.  With it, we know to trust
the untransferred length.

Add a new xHCI quirk for the Fresco Logic host controller.  If a
transfer is reported as successful, but the untransferred length is
non-zero, print a warning.  For the Fresco Logic host, change the
completion code to COMP_SHORT_TX and process the transfer like a short
transfer.

This should be backported to stable kernels that contain the commit
f5182b41 "xhci: Disable MSI for some
Fresco Logic hosts."  That commit was marked for stable kernels as old
as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Sergio Correia <lists@uece.net>
Tested-by: Sergio Correia <lists@uece.net>
Cc: stable@vger.kernel.org
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

Fixed keyword related space issues found by
checkpatch.pl tool in drivers/usb/storage/usb.c
Signed-off-by: Jeffrin Jose <ahiliation@yahoo.co.in>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixed several trailing white spaces issues found
by checkpatch.pl tool in drivers/usb/storage/usb.c
Signed-off-by: Jeffrin Jose <ahiliation@yahoo.co.in>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixed C99 comment issue in drivers/usb/storage/usb.c
found using checkpatch.pl tool.
Signed-off-by: Jeffrin Jose <ahiliation@yahoo.co.in>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge branch 'v3.5-for-usb' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into usb-next

This reverts commit 6971113e.

As Alan pointed out, this really isn't needed as it doesn't handle this
properly.  Ideally this should be handled by the usb-serial core one
day.  So revert it.
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Johan Hovold <jhovold@gmail.com>
Cc: Anton Samokhvalov <pg83@yandex.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

If the usb-serial driver doesn't have a reset_resume callback, then we
need to tell the USB core that it doesn't, and it needs to rebind the
device.

Thanks to Alan for pointing out my mistake, and providing the fix.
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

I hooked up the wrong callback in my previous patch, this should fix it.
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Johan Hovold <jhovold@gmail.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds platform data for using S3C-HSOTG driver at
Universal_C210 target.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>

This patch adds hsotg device to the NURI board.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
[Rebased on the newest git/kgene/linux-samsung #for-next]
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>

This patch adds hsotg device to the GONI board.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>

This patch supports to control usb otg phy of EXYNOS4210.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
[Rebased on the newest git/kgene/linux-samsung #for-next]
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
[kgene.kim@samsung.com: squashed 2 patches together]
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>

Add FunctionFS support.
It allows certain USB functions to be provided from userspace, e.g. MTP,
PTP, adb.

The functions provided by the gadget itself are enumerated in
/sys/class/ccg0/functions. The functions which can be supplied
from userspace must be enumerated in /sys/class/ccg0/f_fs/user_functions.
No other userspace functions can be used than specified in the above mentioned
file, but just specifying them there is not enough to activate them.
The userspace functions in order to be activated need also be enumerated
in /sys/class/ccg0/functions.

An example sequence of operations can be as follows:

$ echo 0 > /sys/class/ccg_usb/ccg0/enable

$ echo -n 0x2d01 > /sys/module/g_ccg/parameters/idProduct
$ echo -n MyDevice > /sys/module/g_ccg/parameters/iSerialNumber
$ echo -n 0x1d6b > /sys/module/g_ccg/parameters/idVendor
$ echo -n Manufacturer > /sys/module/g_ccg/parameters/iManufacturer
$ echo -n Product > /sys/module/g_ccg/parameters/iProduct
$ echo -n bcdDevice > /sys/module/g_ccg/parameters/bcdDevice

$ echo adb,mtp,ptp > /sys/class/ccg_usb/ccg0/f_fs/user_functions
$ echo mass_storage,ptp > /sys/class/ccg_usb/ccg0/functions
$ echo /file.img > /sys/class/ccg_usb/ccg0/f_mass_storage/lun/file

$ mkdir -p /dev/usbgadget/ptp
$ mount -t functionfs ptp /dev/usbgadget/ptp
$ ./ptp &

$ echo 1 > /sys/class/ccg_usb/ccg0/enable

The above example declares that adb, mtp and ptp functions can be supplied
from userspace through FunctionFS. But of them all only ptp is actually
activated, together with mass_storage, the latter being implemented in
the gadget itself (in kernel, not in userspace). The list of functions
can be modified at runtime while the gadget is not enabled, that is,
after

$ echo 0 > /sys/class/ccg_usb/ccg0/enable

The FunctionFS function is implicitly handled by the gadget, that is,
if a userspace function name is provided in
/sys/class/ccg_usb/ccg0/functions, then the FunctionFS function
is activated.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The Configurable Gadget driver is a composite driver that allows
userspace to change at runtime the list of functions enabled in
its configuration and to configure these functions. It supports
multiple functions: acm, rndis, and mass storage.

It is usually controlled by a daemon that changes the configuration
based on user settings. For example, rndis is enabled when the user
enables sharing the phone data connection.

As an example on how to use it, the following shell commands will
make the gadget disconnect from the host and make it be re-enumerated
as a composite with 1 rndis and 2 acm interfaces, and a different
product id:

echo 0       > /sys/class/ccg_usb/ccg0/enable
echo rndis,acm > /sys/class/ccg_usb/ccg0/functions
echo 2       > /sys/class/ccg_usb/ccg0/f_acm/instances
echo -n 0x2d01 > /sys/module/g_ccg/parameters/idProduct
echo 1       > /sys/class/ccg_usb/ccg0/enable

The driver requires a gadget controller that supports software
control of the D+ pullup and the controller driver must support
disabling the pullup during composite_bind.
Signed-off-by: Mike Lockwood <lockwood@android.com>
Signed-off-by: Benoit Goby <benoit@android.com>
	[import from android.c, implement review comments, remove adb,mtp,ptp,accessory]
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Make some noise during probe to make sure the users
are aware of the intended purpose of this driver.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The patch 5a6506f0 (Update at91_udc to use usb_endpoint_descriptor inside the
struct usb_ep) removes the desc field of struct at91_ep. This convertion had
not been completed which leads to a compilation error.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit da0af6e7 ("usb: Bind devices to ACPI devices when possible") really
tries to force-bind devices even when impossible, unlike what it says in
the subject.

CONFIG_ACPI is not an indication that ACPI tables are actually present, nor
is an indication that any USB relevant information is present in them. There
is no reason to fail the creation of a USB bus if it can't bind it to
ACPI device during initialization.

On systems with CONFIG_ACPI set but without ACPI tables it would cause a
boot panic.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dbg() is a usb-serial specific macro.  This patch converts
the symbolserial.c driver to use dev_dbg() instead to tie into the
dynamic debug infrastructure.

CC: Rusty Russell <rusty@rustcorp.com.au>
CC: Johan Hovold <jhovold@gmail.com>
CC: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dbg() is a usb-serial specific macro.  This patch converts
the spcp8x5.c driver to use dev_dbg() instead to tie into the
dynamic debug infrastructure.

CC: Rusty Russell <rusty@rustcorp.com.au>
CC: Alan Stern <stern@rowland.harvard.edu>
CC: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dbg() is a usb-serial specific macro.  This patch converts
the qcserial.c driver to use dev_dbg() instead to tie into the
dynamic debug infrastructure.

CC: Thomas Tuttle <ttuttle@chromium.org>
CC: Alan Stern <stern@rowland.harvard.edu>
CC: Paul Gortmaker <paul.gortmaker@windriver.com>
CC: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dbg() is a usb-serial specific macro.  This patch converts
the navman.c driver to use dev_dbg() instead to tie into the
dynamic debug infrastructure.

CC: Rusty Russell <rusty@rustcorp.com.au>
CC: Alan Stern <stern@rowland.harvard.edu>
CC: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dbg() is a usb-serial specific macro.  This patch converts
the ir-usb.c driver to use dev_dbg() instead to tie into the
dynamic debug infrastructure.

CC: Rusty Russell <rusty@rustcorp.com.au>
CC: Johan Hovold <jhovold@gmail.com>
CC: Alan Stern <stern@rowland.harvard.edu>
CC: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dbg() is a usb-serial specific macro.  This patch converts
the ipaq.c driver to use dev_dbg() instead to tie into the
dynamic debug infrastructure.

CC: Rusty Russell <rusty@rustcorp.com.au>
CC: Johan Hovold <jhovold@gmail.com>
CC: Alan Stern <stern@rowland.harvard.edu>
CC: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dbg() is a usb-serial specific macro.  This patch converts
the generic.c driver to use dev_dbg() instead to tie into the
dynamic debug infrastructure.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dbg() is a usb-serial specific macro.  This patch converts
the f81232.c driver to use dev_dbg() instead to tie into the
dynamic debug infrastructure.

CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dbg() is a usb-serial specific macro.  This patch converts
the belkin_sa.c driver to use dev_dbg() instead to tie into the
dynamic debug infrastructure.

CC: William Greathouse <wgreathouse@smva.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dbg() is a usb-serial specific macro.  This patch converts
the ark3116.c driver to use dev_dbg() instead to tie into the
dynamic debug infrastructure.

CC: Rusty Russell <rusty@rustcorp.com.au>
CC: Alan Stern <stern@rowland.harvard.edu>
CC: Mauro Carvalho Chehab <mchehab@redhat.com>
CC: Bart Hartgers <bart.hartgers@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dbg() is a usb-serial specific macro.  This patch converts
the aircable.c driver to use dev_dbg() instead to tie into the
dynamic debug infrastructure.

CC: Paul Gortmaker <paul.gortmaker@windriver.com>
CC: Rusty Russell <rusty@rustcorp.com.au>
CC: Alan Stern <stern@rowland.harvard.edu>
CC: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

A few patches ago, I removed the reset_resume callback in this driver.
Now that the usb-serial core supports reset_resume, put this driver
callback back as well, so it should work identically to how it was
originally.

Now if this function really is doing what it should be doing, well,
that's a different story, but we are at least doing the identical thing
that we were before...

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Johan Hovold <jhovold@gmail.com>
Cc: Anton Samokhvalov <pg83@yandex.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

A few patches ago, I removed the reset_resume callback, changing it to
resume instead.  Now that the usb-serial core supports reset_resume, put
this driver callback back as well, so it should work identically to how
it was originally.

Now if this function really is doing what it should be doing, well,
that's a different story, but we are at least doing the identical thing
that we were before...

Cc: Johan Hovold <jhovold@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The callback is now hooked up for any USB to serial driver that wants
it.  We only register the callback if any of the usb-serial structures
want it, this keeps the USB core happy.

Thanks to Alan Stern for the ideas on how to do this.

Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>