This patch (as1657) decreases the timeout used by ehci-hcd for polling
the async and periodic schedule statuses.  The timeout is currently
set to 20 ms, which is much too high.  Controllers should always
update the schedule status within one or two ms of being told to do
so; if they don't then something is wrong.

Furthermore, bug reports have shown that sometimes controllers
(particularly those made by VIA) don't update the status bit at all,
even when the schedule does change state.  When this happens, polling
for 20 ms would cause an unnecessarily long delay.

The delay is reduced to somewhere between 2 and 4 ms, depending on the
slop allowed by the kernel's high-res timers.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

As it does almost nothing, get rid of omap_ehci_init()
and move the ehci->caps initialization part into probe().

Also remove the outdated TODO list from header.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move PHY initialization until after EHCI initialization is
complete, instead of initializing the PHYs first, shutting
them down again, and then initializing them a second time.

This fixes HSIC device detection.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Even when not in PHY mode, the USB device on the port (e.g. HUB)
might need resources like RESET which can be modelled as a PHY
device. So try to get the PHY device in any case.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Allows the OMAP EHCI controller to be specified via device tree.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Reviewed-by: NMark Rutland <mark.rutland@arm.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Allows the OHCI controller found in OMAP3 and later chips to
be specified via device tree.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Reviewed-by: NMark Rutland <mark.rutland@arm.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since there is only one resource per type we don't really need
to use resource name to obtain it. This also also makes it easier
for device tree adaptation.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since there is only one resource per type we don't really need
to use resource name to obtain it. This also also makes it easier
for device tree adaptation.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In PHY mode we need to have the nop-usb-xceiv transceiver
driver to operate, so select it in Kconfig.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

PHY regulator handling must be done in the PHY driver
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Reset GPIO handling for the PHY must be done in the PHY
driver. We use the PHY helpers instead to reset the PHY.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For each port that is in PHY mode we obtain a PHY device using the USB PHY
library and put it out of suspend.

It is up to platform code to associate the PHY to the controller's
port and it is up to the PHY driver to manage the PHY's resources.

Also remove weird spacing around declarations we come across.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make use of devm_ioremap_resource() and correct comment.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1645) converts ehci-omap over to the new "ehci-hcd is a
library" approach, so that it can coexist peacefully with other EHCI
platform drivers and can make use of the private area allocated at
the end of struct ehci_hcd.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A failed kzalloc() is reported with a dev_err that dereferences the null
sisusb, this will cause a NULL pointer deference error.

Instead, pass dev->dev to the dev_err() rather than &sisusb->sisusb_dev->dev

Smatch analysis:

drivers/usb/misc/sisusbvga/sisusb.c:3087 sisusb_probe() error: potential null
  dereference 'sisusb'.  (kzalloc returns null)
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

remove cast for kmalloc return value.
Signed-off-by: NZhang Yanfei <zhangyanfei@cn.fujitsu.com>
Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-usb@vger.kernel.org
Cc: usb-storage@lists.one-eyed-alien.net
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the module_i2c_driver() macro to make the code smaller
and a bit simpler.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NPaul Vlase <vlase.paul@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Modern speed handling has been introduced in 2009 by commit
9b80fee1 (cdc_acm: Fix to use modern
speed interfaces) and the acm_tty_speed array has been unused since.
Signed-off-by: NSamuel Tardieu <sam@rfc1149.net>
Acked-by: NOliver Neukum <oliver@neukum.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

kfree on NULL pointer is a no-op.
Signed-off-by: NSyam Sidhardhan <s.syam@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Smatch complains because we only allocate ONETOUCH_PKT_LEN (2) bytes
but later when we call usb_fill_int_urb() we assume maxp can be up
to 8 bytes.  I talked to the maintainer and maxp should be capped at
ONETOUCH_PKT_LEN.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The tty port ops shutdown() routine is not called for console ports;
remove extra check.
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Acked-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It is not very useful to indicate the the driver is about to be probed.

Quoting Alan Stern [1]:

"Plenty of drivers don't include any message like this at all.  You
might as well get rid of it entirely."

Remove such dev_info().

[1] http://marc.info/?l=linux-usb&m=136138896132433&w=2Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since commit c0304996 (USB: ehci-mxc: remove Efika MX-specific CHRGVBUS hack)
there is no need to include <asm/mach-types.h>, so remove it.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Staticize usbmisc_imx6q_drv_init/exit() to fix the following sparse warnings:

drivers/usb/chipidea/usbmisc_imx6q.c:147:12: warning: symbol 'usbmisc_imx6q_drv_init' was not declared. Should it be static?
drivers/usb/chipidea/usbmisc_imx6q.c:153:13: warning: symbol 'usbmisc_imx6q_drv_exit' was not declared. Should it be static?
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

USB uses the .find_bridge() callback from struct acpi_bus_type
incorrectly, because as a result of the way it is used by USB every
device in the system that doesn't have a bus type or parent is
passed to usb_acpi_find_device() for inspection.

What USB actually needs, though, is to call usb_acpi_find_device()
for USB ports that don't have a bus type defined, but have
usb_port_device_type as their device type, as well as for USB
devices.

To fix that replace the struct bus_type pointer in struct
acpi_bus_type used for matching devices to specific subsystems
with a .match() callback to be used for this purpose and update
the users of struct acpi_bus_type, including USB, accordingly.
Define the .match() callback routine for USB, usb_acpi_bus_match(),
in such a way that it will cover both USB devices and USB ports
and remove the now redundant .find_bridge() callback pointer from
usb_acpi_bus.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NYinghai Lu <yinghai@kernel.org>
Acked-by: NJeff Garzik <jgarzik@pobox.com>

Modify the request_module to prefix the file system type with "fs-"
and add aliases to all of the filesystems that can be built as modules
to match.

A common practice is to build all of the kernel code and leave code
that is not commonly needed as modules, with the result that many
users are exposed to any bug anywhere in the kernel.

Looking for filesystems with a fs- prefix limits the pool of possible
modules that can be loaded by mount to just filesystems trivially
making things safer with no real cost.

Using aliases means user space can control the policy of which
filesystem modules are auto-loaded by editing /etc/modprobe.d/*.conf
with blacklist and alias directives.  Allowing simple, safe,
well understood work-arounds to known problematic software.

This also addresses a rare but unfortunate problem where the filesystem
name is not the same as it's module name and module auto-loading
would not work.  While writing this patch I saw a handful of such
cases.  The most significant being autofs that lives in the module
autofs4.

This is relevant to user namespaces because we can reach the request
module in get_fs_type() without having any special permissions, and
people get uncomfortable when a user specified string (in this case
the filesystem type) goes all of the way to request_module.

After having looked at this issue I don't think there is any
particular reason to perform any filtering or permission checks beyond
making it clear in the module request that we want a filesystem
module.  The common pattern in the kernel is to call request_module()
without regards to the users permissions.  In general all a filesystem
module does once loaded is call register_filesystem() and go to sleep.
Which means there is not much attack surface exposed by loading a
filesytem module unless the filesystem is mounted.  In a user
namespace filesystems are not mounted unless .fs_flags = FS_USERNS_MOUNT,
which most filesystems do not set today.
Acked-by: NSerge Hallyn <serge.hallyn@canonical.com>
Acked-by: NKees Cook <keescook@chromium.org>
Reported-by: NKees Cook <keescook@google.com>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

This patch (as1649) reverts commit
55bcdce8 (USB: EHCI: remove ASS/PSS
polling timeout).  That commit was written under the assumption that
some controllers may take a very long time to turn off their async and
periodic schedules.  It now appears that in fact the schedules do get
turned off reasonably quickly, but some controllers occasionally leave
the schedules' status bits turned on and consequently ehci-hcd can't
tell that the schedules are off.

VIA controllers in particular have this problem.  ehci-hcd tells the
hardware to turn off the async schedule, the schedule does get turned
off, but the status bit remains on.  Since the EHCI spec requires that
the schedules not be re-enabled until the previous disable has taken
effect, with an unlimited timeout the async schedule never gets turned
back on.  The resulting symptom is that the system is unable to
communicate with USB devices.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: NRonald <ronald645@gmail.com>
Reported-and-tested-by: NPaul Hartman <paul.hartman@gmail.com>
Reported-and-tested-by: NDieter Nützel <dieter@nuetzel-hh.de>
Reported-and-tested-by: NJean Delvare <khali@linux-fr.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If one storage interface or usb network interface(iSCSI case) exists in
current configuration, memory allocation with GFP_KERNEL during
usb_device_reset() might trigger I/O transfer on the storage interface
itself and cause deadlock because the 'us->dev_mutex' is held in
.pre_reset() and the storage interface can't do I/O transfer when the
reset is triggered by other interface, or the error handling can't be
completed if the reset is triggered by the storage itself (error
handling path).
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Decotigny <david.decotigny@google.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.de>
Reviewed-by: NJiri Kosina <jkosina@suse.cz>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

This reverts commit d57ada0c.

All of these are wrong and need to be reverted for now.

Cc: Manjunath Goudar <manjunath.goudar@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Tony Prisk <linux@prisktech.co.nz>
Cc: Alexey Charkov <alchark@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 6ed3c43d.

All of these are wrong, and need to be reverted for now.

Cc: Manjunath Goudar <manjunath.goudar@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit e2ced166.

All of these are wrong, and need to be removed for now until they can
get reworked properly.

Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The static lock initializers want to be fed the proper name of the
lock and not some random string. In mainline random strings are
obfuscating the readability of debug output, but for RT they prevent
the spinlock substitution. Fix it up.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

The recent patches from Manjunath Goudar introduced two small
mistakes in the Kconfig help text for the new options. Let's
fix those and the other entries that have become stale over time.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

With the multiplatform changes in arm-soc tree, it becomes
possible to enable the mvebu platform (which uses
ehci-orion) at the same time as other platforms that require
a conflicting EHCI bus glue. At the moment, this results
in a warning like

drivers/usb/host/ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the previous definition
drivers/usb/host/ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but not used [-Wunused-variable]

and an ehci driver that only works on one of them.

With the infrastructure added by Alan Stern in patch 3e023203
"USB: EHCI: prepare to make ehci-hcd a library module", we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the orion bus glue.
Signed-off-by: NManjunath Goudar <manjunath.goudar@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

With the multiplatform changes in arm-soc tree, it becomes
possible to enable the vt8500 platform at the same time
as other platforms that require a conflicting EHCI bus
glue. At the moment, this results in a warning like

drivers/usb/host/ehci-hcd.c:1277:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
drivers/usb/host/ehci-hcd.c:1257:0: note: this is the location of the previous definition
drivers/usb/host/ehci-omap.c:319:31: warning: 'ehci_hcd_omap_driver' defined but not used [-Wunused-variable]

and an ehci driver that only works on one of them.

With the infrastructure added by Alan Stern in patch 3e023203
"USB: EHCI: prepare to make ehci-hcd a library module", we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the vt8500 bus glue.
Signed-off-by: NManjunath Goudar <manjunath.goudar@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NTony Prisk <linux@prisktech.co.nz>
Cc: Alexey Charkov <alchark@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The current entry in unusual_cypress.h for the Super TOP SATA bridge devices
seems to be causing corruption on newer revisions of this device.  This has
been reported in Arch Linux and Fedora.  The original patch was tested on
devices with bcdDevice of 1.60, whereas the newer devices report bcdDevice
as 2.20.  Limit the UNUSUAL_DEV entry to devices less than 2.20.

This fixes https://bugzilla.redhat.com/show_bug.cgi?id=909591

The Arch Forum post on this is here:
	https://bbs.archlinux.org/viewtopic.php?id=152011Reported-by: NCarsten S. <carsteniq@yahoo.com>
Tested-by: NCarsten S. <carsteniq@yahoo.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJosh Boyer <jwboyer@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The module alias should be "ehci-omap" and not
"omap-ehci" to match the platform device name.
The omap-ehci module should now autoload correctly.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>