Call try_to_freeze() in sleep_thread() only when it's safe to sleep.
do_read() and do_write() calls sleep_thread with lock held.
Make sure these won't call try_to_freeze() by passing can_freeze flag
to sleep_thread.

Calling try_to_freeze() with a lock hold was done since day one in
f_mass_storage but since commit 0f9548ca1 ("lockdep: check that no
locks held at freeze time") lockdep complains about it.

Signed-off-by: George Cherian <george.cherian@ti.com>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>

that symbol is only used inside this function driver,
we should mark it static. Fixes sparse's:

drivers/usb/gadget/tcm_usb_gadget.c:373:6: warning: symbol \
	'bot_cleanup_old_alt' was not declared. Should it \
	be static?

Signed-off-by: Felipe Balbi <balbi@ti.com>

use NULL instead of 0 as pointer.

Signed-off-by: Felipe Balbi <balbi@ti.com>

g_zero's module parameters can, and should, be
static. This fixes sparse warnings.

Cc: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

fsg_common_set_inquiry_string() expects pointers
as second and third argument. Let's fix that by
passing NULL instead of plain 0 just so we silence
sparse's:

drivers/usb/gadget/f_mass_storage.c:3114:60: warning: \
	Using plain integer as NULL pointer
drivers/usb/gadget/f_mass_storage.c:3114:63: warning: \
	Using plain integer as NULL pointer

Signed-off-by: Felipe Balbi <balbi@ti.com>

Mass storage gadget returns DELAYED_STATUS in stead of
USB_GADGET_DELAYED_STATUS while handling bulk reset request. Since
peripheral driver uses USB_GADGET_DELAYED_STATUS for delayed status
handling, therefore replace DELAYED_STATUS by USB_GADGET_DELAYED_STATUS
in mass storage driver.

Since, DELAYED_STATUS and hence EP0_BUFSIZE will no longer be used now,
so remove them.

Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Cc: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Legacy gadgets supporting mass storage (g_mass_storage, g_acm_ms, g_multi)
all depend on BLOCK.

Make the standalone compilation of f_mass_storage (without any legacy
gadget) dependent no BLOCK, too.

Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

The delayed_status value is used to keep track of status response
packets on ep0. It needs to be reset or the set_config function would
still delay the answer, if the usb device got unplugged while waiting
for setup_continue to be called.

Cc: stable@vger.kernel.org
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>

In commit
88f718e3fa4d67f3a8dbe79a2f97d722323e4051
"ARM: pxa: delete the custom GPIO header"
we removed the implicit inclusion of <mach/gpio.h>
from <linux/gpio.h>.

The pxa25x_udc was not using that, but it was relying
on <linux/gpio.h> to implictly include <mach/gpio.h>
which in turn implicitly included <mach/hardware.h>,
which was needed for the driver to compile.

Fix this up by explicitly including the necessary
<mach/hardware.h> header.

Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>

This patch moves s3c_hsotg_disconnect function call from USBSusp interrupt
handler to SET_ADDRESS request handler.

It's because disconnected state can't be detected directly, because this
hardware doesn't support Disconnected interrupt for device mode. For both
Suspend and Disconnect events there is one interrupt USBSusp, but calling
s3c_hsotg_disconnect from this interrupt handler causes config reset in
composite layer, which is not undesirable for Suspended state.

For this reason s3c_hsotg_disconnect is called from SET_ADDRESS request
handler, which occurs always after disconnection, so we do disconnect
immediately before we are connected again. It's probably only way we
can do handle disconnection correctly.

Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>