In theory, an EHCI controller can turn off the PORT_RESUME or
PORT_RESET bits in a port status register all by itself (and some
controllers actually do this).  We shouldn't depend on these bits
being set correctly.

This patch rearranges the code in ehci-hcd that handles completion of
port resets and resumes.  We guarantee that ehci->reset_done[portnum]
is nonzero if a reset or resume is in progress, and that the portnum
bit is set in ehci->resuming_ports if the operation is a resume.  (To
help enforce this guarantee, the patch prevents suspended ports from
being reset.)  Therefore it's not necessary to look at the port status
bits to learn what's going on.

The patch looks bigger than it really is, because it changes the
indentation level of a sizeable region of code.  Most of what it
actually does is interchange some tests.  The only functional changes
are testing reset_done and resuming_ports rather than PORT_RESUME and
PORT_RESET, removing a now-unnecessary check for spontaneous
resets of the PORT_RESUME and PORT_RESET bits, and preventing a
suspended or resuming port from being reset.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The ehci-hcd driver isn't as careful as it should be about the way it
uses ehci->resuming_ports.  One of the omissions was fixed recently by
commit 47a64a13 (USB: EHCI: Fix resume signalling on remote
wakeup), but there are other places that need attention:

	When a port's suspend feature is explicitly cleared, the
	corresponding bit in resuming_ports should be set and the core
	should be notified about the port resume.

	We don't need to clear a resuming_ports bit when a reset
	completes.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It's not clear if the type_0 and type_1 chips support the divisor based baud
rate encoding method, so don't use it until anyone with such chip has tested it
to avoid regressions with the following patches.

Even if it has been working fine with these chips since the code has been added
2 years ago, this change will not cause any regressions, because the baud rates
currently supported/allowed with the divisor based method are supported with
the direct method, too.

The code for the divisor based method also isn't entirely correct (yet), so that the
direct encoding method actually works better (sets the baud rate more precisely).
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The hub driver's usb_port_suspend() routine doesn't handle errors
related to Link Power Management properly.  It always returns failure,
it doesn't try to clean up the wakeup setting, (in the case of system
sleep) it doesn't try to go ahead with the port suspend regardless,
and it doesn't try to apply the new power-off mechanism.

This patch fixes these problems.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The hub driver is inconsistent in its organization of code for
enabling and disabling remote wakeup.  There is a special routine to
disable wakeup for SuperSpeed devices but not for slower devices, and
there is no special routine to enable wakeup.

This patch refactors the code.  It renames and changes the existing
function to make it handle both SuperSpeed and non-SuperSpeed devices,
and it adds a corresponding routine to enable remote wakeup.  It also
changes the speed determination to look at the device's speed rather
than the speed of the parent hub -- this shouldn't make any difference
because a SuperSpeed device always has to be attached to a SuperSpeed
hub and conversely.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch simplifies the interface presented by usb_get_status().
Instead of forcing callers to check for the proper data length and
convert the status value to host byte order, the function will now
do these things itself.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The USB hub driver's event handler contains a check to catch SuperSpeed
devices that transitioned into the SS.Inactive state and tries to fix
them with a reset. It decides whether to do a plain hub port reset or
call the usb_reset_device() function based on whether there was a device
attached to the port.

However, there are device/hub combinations (found with a JetFlash
Transcend mass storage stick (8564:1000) on the root hub of an Intel
LynxPoint PCH) which can transition to the SS.Inactive state on
disconnect (and stay there long enough for the host to notice). In this
case, above-mentioned reset check will call usb_reset_device() on the
stale device data structure. The kernel will send pointless LPM control
messages to the no longer connected device address and can even cause
several 5 second khubd stalls on some (buggy?) host controllers, before
finally accepting the device's fate amongst a flurry of error messages.

This patch makes the choice of reset dependent on the port status that
has just been read from the hub in addition to the existence of an
in-kernel data structure for the device, and only proceeds with the more
extensive reset if both are valid.
Signed-off-by: NJulius Werner <jwerner@chromium.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

FOTG210 is an OTG controller which can be configured as an
USB2.0 host. FOTG210 host is an ehci-like controller with
some differences. First, register layout of FOTG210 is
incompatible with EHCI. Furthermore, FOTG210 is lack of
siTDs which means iTDs are used for both HS and FS ISO
transfer.
Signed-off-by: NFeng-Hsin Chiang <john453@faraday-tech.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixes the following regression that has been introduced recently with
commit b2d6d98f:
With type_0 and type_1 chips
- all baud rates < 1228800 baud are rounded up to 1228800 baud
- the device silently runs at 9600 baud for all baud rates > 1228800
  baud
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When ohci-hcd is shutting down, call ohci_usb_reset reset ohci-hcd, the
root hub generate an interrupt, but ohci->rh_state is OHCI_RH_HALTED,
and ohci_irq ignore the interrupt, the kernel trigger warning "irq
nobody cared". ehci-hcd is first disable interrupts, then reset ehci.

This patch disable ohci interrupt before reset ohci.

The patch is tested at the arm cortex-a9 demo board.
Signed-off-by: Ncaizhiyong <caizhiyong@huawei.com>
Reviewed-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57f6ce07 ("usb: phy:
add a new driver for usb3 phy") added the new Kconfig option
OMAP_USB3, but it had no dependencies whatsoever, and hence
became available across all arch/platforms.

Which presumably caused this to show up in x86 randconfig:

    warning: (USB_MUSB_HDRC && OMAP_USB3) selects \
        OMAP_CONTROL_USB which has unmet direct \
        dependencies (USB_SUPPORT && ARCH_OMAP2PLUS)

Then commit 6992819f ("usb: phy:
fix Kconfig warning") was added.  However, this just deleted the
ARCH_OMAP2PLUS dependency from OMAP_CONTROL_USB, further
compounding the problem by opening up OMAP_CONTROL_USB to
all arch/platforms as well.

Earlier it was suggested[1] that we revert the change of 6992819f
to restore the dependency, and add a same ARCH_OMAP2PLUS dependency
to the new OMAP_USB3 entry.  However that was discouraged on the
grounds of people wanting the extra sanity compile testing on x86,
even though the driver could probably never be used there.

Now we have CONFIG_COMPILE_TEST, so developers who value the ability
to compile drivers on an architecture that it never can be used for
can have that, and people who want dependencies to shield them from
seeing options that aren't relevant to their platform get what they
want too.

Here we restore the dependency but couple it with COMPILE_TEST, in
order to achieve both of the above goals.

[1] https://patchwork.kernel.org/patch/2194511/Acked-by: NFelipe Balbi <balbi@ti.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Moiz Sonasath <m-sonasath@ti.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge the usb_hcd_ep93xx_probe() into ohci_hcd_ep93xx_drv_probe() and
the usb_hcd_ep93xx_remove() into ohci_hcd_ep93xx_drv_remove(). As Alan
Stern pointed out, there is no reason for them to be separate.

Also, as Alan Stern suggested, eliminate the ep93xx_start_hc() and
ep93xx_stop_hc() routines and simply call clk_enable() and clk_disable()
directly. The extra level of redirection does not add any clarity.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: Lennert Buytenhek <kernel@wantstofly.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use devm_clk_get() to make the code a bit cleaner and simpler.

This also fixes a bug where a clk_put() is not done if usb_add_hcd()
fails.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: Lennert Buytenhek <kernel@wantstofly.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use platform_get_irq() instead of accessing the platform_device
resources directly.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: Lennert Buytenhek <kernel@wantstofly.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use devm_ioremap_resource() to make the code a bit cleaner and
simpler.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: Lennert Buytenhek <kernel@wantstofly.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We attempted to address a regression introduced by commit a57f7f91
(ACPICA: Add Windows8/Server2012 string for _OSI method.) after which
ACPI video backlight support doesn't work on a number of systems,
because the relevant AML methods in the ACPI tables in their BIOSes
become useless after the BIOS has been told that the OS is compatible
with Windows 8.  That problem is tracked by the bug entry at:

https://bugzilla.kernel.org/show_bug.cgi?id=51231

Commit 8c5bd7ad (ACPI / video / i915: No ACPI backlight if firmware
expects Windows 8) introduced for this purpose essentially prevented
the ACPI backlight support from being used if the BIOS had been told
that the OS was compatible with Windows 8 and the i915 driver was
loaded, in which case the backlight would always be handled by i915.
Unfortunately, however, that turned out to cause problems with
backlight to appear on multiple systems with symptoms indicating that
i915 was unable to control the backlight on those systems as
expected.

For this reason, revert commit 8c5bd7ad, but leave the function
acpi_video_backlight_quirks() introduced by it, because another
commit on top of it uses that function.

References: https://lkml.org/lkml/2013/7/21/119
References: https://lkml.org/lkml/2013/7/22/261
References: https://lkml.org/lkml/2013/7/23/429
References: https://lkml.org/lkml/2013/7/23/459
References: https://lkml.org/lkml/2013/7/23/81
References: https://lkml.org/lkml/2013/7/24/27Reported-and-tested-by: NJames Hogan <james@albanarts.com>
Reported-and-tested-by: NKamal Mostafa <kamal@canonical.com>
Reported-and-tested-by: NJörg Otte <jrg.otte@gmail.com>
Reported-and-tested-by: NSteven Newbury <steve@snewbury.org.uk>
Reported-by: NMartin Steigerwald <Martin@lichtvoll.de>
Reported-by: NKalle Valo <kvalo@adurom.com>
Tested-by: NJoerg Platte <jplatte@naasa.net>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ahci_imx makes use of regmap but the dependency wasn't specified in
Kconfig leading build failures if CONFIG_AHCI_IMX is enabled but
CONFIG_MFD_SYSCON is not.  Add the Kconfig dependency.
Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>

Actually program the correct register to enable
engine clock scaling control.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Allows you to limit the selected power levels via sysfs.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The device-tree enablement for max8925 has several problems, but besides
the bindings being wrong (and not having seen review) there's also some
bad coding practices on how to fill in the platform_data from device tree.

I came across this since it causes a warning when compiling
mmp2_defconfig, and instead of doing the minimal fix to silence the
warning, I restructured the code a bit.

This silences the warning:
drivers/video/backlight/max8925_bl.c: In function 'max8925_backlight_probe':
drivers/video/backlight/max8925_bl.c:177:3: warning: statement with no effect [-Wunused-value]

Note that the bindings themselves need to be revisited too, but that will
affect more than just the backlight driver and is best done separately;
this just fixes the bad code for the backlight driver.
Acked-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Need to use the driver state rather than the register
state since the displays may not be enabled when the
power state is programmed.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Need to set high for the last two entries.  Looks
like a copy and paste typo.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Updated skel_read() in usb-skeleton.c. When there is no data in the
buffer, we would allow retry for both blocking and nonblocking cases.
Original logic give retry only for blocking case. Actually we can also
allow retry for nonblocking case. This will reuse the existing retry
logic and handle the return of -EAGAIN in one place. Also if the data to
be read is short and can be retrieved in quick time, we can also give a
chance for nonblocking case and may catch the data and copy it back to
userspace in one read() call too.
Signed-off-by: NChen Wang <unicornxx.wang@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

kfree(data) will be called implicitly.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a few cases where braces are not needed. This patch removes
unnecessary '& 255' pieces as well when lvalue type is u8.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Additionally remove useless label.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Recent patch series introduces few trailing spaces. This patch removes them.
No functional change.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For certain (HP) printers the printer device_id does not only contain a
static part identifying the printer, but it also contains a dynamic part
giving printer status, ink level, etc.

To get to this info various userspace utilities need to be able to make a
printer class 'get_device_id' request without first claiming the interface
(as that is in use for the actual printer driver).

Since the printer class 'get_device_id' request does not change interface
settings in anyway, allowing this without claiming the interface should not
cause any issues.

CC: Sanjay Kumar <sanjay.kumar14@hp.com>
CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Most HCD drivers are doing the same thing in their ".shutdown" callback
so it makes sense to use the generic usb_hcd_platform_shutdown()
handler there.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch removes a redundant nested "#ifdef CONFIG_PM" from the hub
driver.  It also adds a label to the "#endif" line corresponding to
the outer "#ifdef CONFIG_PM".
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

An Embedded Host High-Speed Electrical Test (EHSET) test fixture is
used to initiate test modes on a host controller in order to perform
the high speed electrical testing procedure for USB-IF compliance.
When this test fixture is connected to a host, it can enumerate as
one of several selectable VID/PID pairs, each corresponding to one
of the following test modes:

* TEST_SE0_NAK
* TEST_J
* TEST_K
* TEST_PACKET
* HS_HOST_PORT_SUSPEND_RESUME
* SINGLE_STEP_GET_DEV_DESC
* SINGLE_STEP_SET_FEATURE

The USB EHSET procedure can be found here:
http://www.usb.org/developers/onthego/EHSET_v1.01.pdfSigned-off-by: NManu Gautam <mgautam@codeaurora.org>
[jackp@codeaurora.org: imported from commit 073c9409 on codeaurora.org;
 minor cleanup and updated author email]
Signed-off-by: NJack Pham <jackp@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

bInterval must be on the range 1 - 16, if we
want to pass the maximum allowed, we should
be passing 16.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

bInterval must be on the range 1 - 16, if we
want to pass the maximum allowed, we should
be passing 16
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Control transfers have both IN and OUT (or SETUP) packets, so when
clearing TT buffers for a control transfer it's necessary to send
two HUB_CLEAR_TT_BUFFER requests to the hub.
Signed-off-by: NWilliam Gulland <wgulland@google.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix memory leaks introduced in commits:

40d133d7
usb: gadget: f_ncm: convert to new function interface with backward compatibility

fee562a6
usb: gadget: f_ecm: convert to new function interface with backward compatibility

fcbdf12e
usb: gadget: f_phonet: convert to new function interface with backward compatibility

b29002a1
usb: gadget: f_eem: convert to new function interface with backward compatibility

8cedba7c
usb: gadget: f_subset: convert to new function interface with backward compatibility

f466c635
usb: gadget: f_rndis: convert to new function interface with backward compatibility
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Allocated urbs and buffers were never freed on errors in open.

Cc: stable@vger.kernel.org
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>