commit 08a3b3b1c2e622e378d9086aee9e2e42ce37591d upstream.

The iounmap(ehci->ohci_hcctrl_reg); should be the first thing we do
because the ioremap() was the last thing we did.  Also if we hit any of
the goto statements in the original code then it would have led to a
NULL dereference of "ehci".  This bug was introduced in: 796bcae7361c
"USB: powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3]"

I modified the few lines in front a little so that my code didn't
obscure the return success code path.

Signed-off-by: Dan Carpenter <error27@gmail.com>
Reviewed-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit a1669b2c64a9c8b031e0ac5cbf2692337a577f7c upstream.

The code to increment the TRB pointer has a slight ambiguity that could
lead to a bug on different compilers.  The ANSI C specification does not
specify the precedence of the assignment operator over the postfix
operator.  gcc 4.4 produced the correct code (increment the pointer and
assign the value), but a MIPS compiler that one of John's clients used
assigned the old (unincremented) value.

Remove the unnecessary assignment to make all compilers produce the
correct assembly.

Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 2d62f3eea98354d61f90d6b115eecf9be5f4bdfe upstream.

After software resets an xHCI host controller, it must wait for the
"Controller Not Ready" (CNR) bit in the status register to be cleared.
Software is not supposed to ring any doorbells or write to any registers
except the status register until this bit is cleared.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit ed07453fd356025cc25272629e982f5e4607632c upstream.

When the run bit is set in the xHCI command register, it may take a few
microseconds for the host to start running.  We cannot ring any doorbells
until the host is actually running, so wait until the status register says
the host is running.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Shinya Saito <shinya.saito.sx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 54b5acf3acb7a1f83ec281d111d3e2812cd7ad9d upstream.

Macro TRB_TYPE is misused in some places. Fix the wrong usage.


Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 44ebd037c54f80db3121ac9f5fe6e677b76e11d5 upstream.

The length of the scatter gather list a driver can enqueue is limited by
the bus' sg_tablesize to 62 entries.  Each entry will be described by at
least one transfer request block (TRB).  If the entry's buffer crosses a
64KB boundary, then that entry will have to be described by two or more
TRBs.  So even if the USB device driver respects sg_tablesize, the whole
scatter list may take more than 62 TRBs to describe, and won't fit on
the ring.

Don't assume that an empty ring means there is enough room on the
transfer ring.  The old code would unconditionally queue this too-large
transfer, and over write the beginning of the transfer.  This would mean
the cycle bit was unchanged in those overwritten transfers, causing the
hardware to think it didn't own the TRBs, and the host would seem to
hang.

Now drivers may see submit_urb() fail with -ENOMEM if the transfers are
too big to fit on the ring.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 1624ae1c19e227096ba85bfc389d9b99cb6f7dde upstream.

When the USB core installs a new interface, it unconditionally clears the
halts on all the endpoints on the new interface.  Usually the xHCI host
needs to know when an endpoint is reset, so it can change its internal
endpoint state.  In this case, it doesn't care, because the endpoints were
never halted in the first place.

To avoid issuing a redundant Reset Endpoint command, the xHCI driver looks
at xhci_virt_ep->stopped_td to determine if the endpoint was actually
halted.  However, the functions that handle the stall never set that
variable to NULL after it dealt with the stall.  So if an endpoint stalled
and a Reset Endpoint command completed, and then the class driver tried to
install a new alternate setting, the xHCI driver would access the old
xhci_virt_ep->stopped_td pointer.  A similar problem occurs if the
endpoint has been stopped to cancel a transfer.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit eab80de01cb398419ef3305f35abcb367c647c8b upstream.

This is a bug fix for PHCD (phy clock disable) low power feature:
After PHCD is set, any write to PORTSC register is illegal, so when
resume ports, clear PHCD bit first.

Signed-off-by: Alek Du <alek.du@intel.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 9238f25d5d32a435277eb234ec82bacdd5daed41 upstream.

For periodic endpoints, we must let the xHCI hardware know the maximum
payload an endpoint can transfer in one service interval.  The xHCI
specification refers to this as the Maximum Endpoint Service Interval Time
Payload (Max ESIT Payload).  This is used by the hardware for bandwidth
management and scheduling of packets.

For SuperSpeed endpoints, the maximum is calculated by multiplying the max
packet size by the number of bursts and the number of opportunities to
transfer within a service interval (the Mult field of the SuperSpeed
Endpoint companion descriptor).  Devices advertise this in the
wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor.

For high speed devices, this is taken by multiplying the max packet size by the
"number of additional transaction opportunities per microframe" (the high
bits of the wMaxPacketSize field in the endpoint descriptor).

For FS/LS devices, this is just the max packet size.

The other thing we must set in the endpoint context is the Average TRB
Length.  This is supposed to be the average of the total bytes in the
transfer descriptor (TD), divided by the number of transfer request blocks
(TRBs) it takes to describe the TD.  This gives the host controller an
indication of whether the driver will be enqueuing a scatter gather list
with many entries comprised of small buffers, or one contiguous buffer.

It also takes into account the number of extra TRBs you need for every TD.
This includes No-op TRBs and Link TRBs used to link ring segments
together.  Some drivers may choose to chain an Event Data TRB on the end
of every TD, thus increasing the average number of TRBs per TD.  The Linux
xHCI driver does not use Event Data TRBs.

In theory, if there was an API to allow drivers to state what their
bandwidth requirements are, we could set this field accurately.  For now,
we set it to the same number as the Max ESIT payload.

The Average TRB Length should also be set for bulk and control endpoints,
but I have no idea how to guess what it should be.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 1cf62246c0e394021e494e0a8f1013e80db1a1a9 upstream.

A SuperSpeed interrupt or isochronous endpoint can define the number of
"burst transactions" it can handle in a service interval.  This is
indicated by the "Mult" bits in the bmAttributes of the SuperSpeed
Endpoint Companion Descriptor.  For example, if it has a max packet size
of 1024, a max burst of 11, and a mult of 3, the host may send 33
1024-byte packets in one service interval.

We must tell the xHCI host controller the number of multiple service
opportunities (mults) the device can handle when the endpoint is
installed.  We do that by setting the Mult field of the Endpoint Context
before a configure endpoint command is sent down.  The Mult field is
invalid for control or bulk SuperSpeed endpoints.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>