disable wakeup irq during shutdown, otherwise kexec fails for
kernels that setup irq handlers before resetting the hardware
Signed-off-by: Andreas Fenkart <andreas.fenkart@dev.digitalstrom.org>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Since this configuration option has deleted, cleans up all
its references.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Reported-by: Valentin Rothberg <valentinrothberg@gmail.com>
Since we need to mount debugfs to show/store the things we
want to debug, it is duplicated to add another configuration
to enable it. Meanwhile, with CONFIG_USB_CHIPIDEA_DEBUG,
we can't support chipidea debugfs at runtime.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Cc: Jun Li <jun.li@freescale.com>
_hardware_enqueue() didn't check for errors when using
add_td_to_list() which can fail if dma_pool_alloc fails, thus
causing a kernel panic when lastnode->ptr is NULL.
Signed-off-by: Felipe F. Tonello <eu@felipetonello.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Update comments to reflect current state of functions.
Signed-off-by: Felipe F. Tonello <eu@felipetonello.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
We want the USB and PHY fixes in here as well to make things easier for
testing and development.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 8520f38099 ("USB: change hub initialization sleeps to
delayed_work") changed the hub_activate() routine to make part of it
run in a workqueue. However, the commit failed to take a reference to
the usb_hub structure or to lock the hub interface while doing so. As
a result, if a hub is plugged in and quickly unplugged before the work
routine can run, the routine will try to access memory that has been
deallocated. Or, if the hub is unplugged while the routine is
running, the memory may be deallocated while it is in active use.
This patch fixes the problem by taking a reference to the usb_hub at
the start of hub_activate() and releasing it at the end (when the work
is finished), and by locking the hub interface while the work routine
is running. It also adds a check at the start of the routine to see
if the hub has already been disconnected, in which nothing should be
done.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Alexandru Cornea <alexandru.cornea@intel.com>
Tested-by: Alexandru Cornea <alexandru.cornea@intel.com>
Fixes: 8520f38099 ("USB: change hub initialization sleeps to delayed_work")
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The code expects the loop to end with "retries" set to zero but, because
it is a post-op, it will end set to -1. I have fixed this by moving the
decrement inside the loop.
Fixes: 014aa2a3c3 ('USB: ipaq: minor ipaq_open() cleanup.')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some USB device / host controller combinations seem to have problems
with Link Power Management. For example, Steinar found that his xHCI
controller wouldn't handle bandwidth calculations correctly for two
video cards simultaneously when LPM was enabled, even though the bus
had plenty of bandwidth available.
This patch introduces a new quirk flag for devices that should remain
disabled for LPM, and creates quirk entries for Steinar's devices.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Steinar H. Gunderson <sgunderson@bigfoot.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
According to USB 2 specs ports need to signal resume for at least 20ms,
in practice even longer, before moving to U0 state.
Both host and devices can initiate resume.
On device initiated resume, a port status interrupt with the port in resume
state in issued. The interrupt handler tags a resume_done[port]
timestamp with current time + USB_RESUME_TIMEOUT, and kick roothub timer.
Root hub timer requests for port status, finds the port in resume state,
checks if resume_done[port] timestamp passed, and set port to U0 state.
On host initiated resume, current code sets the port to resume state,
sleep 20ms, and finally sets the port to U0 state. This should also
be changed to work in a similar way as the device initiated resume, with
timestamp tagging, but that is not yet tested and will be a separate
fix later.
There are a few issues with this approach
1. A host initiated resume will also generate a resume event. The event
handler will find the port in resume state, believe it's a device
initiated resume, and act accordingly.
2. A port status request might cut the resume signalling short if a
get_port_status request is handled during the host resume signalling.
The port will be found in resume state. The timestamp is not set leading
to time_after_eq(jiffies, timestamp) returning true, as timestamp = 0.
get_port_status will proceed with moving the port to U0.
3. If an error, or anything else happens to the port during device
initiated resume signalling it will leave all the device resume
parameters hanging uncleared, preventing further suspend, returning
-EBUSY, and cause the pm thread to busyloop trying to enter suspend.
Fix this by using the existing resuming_ports bitfield to indicate that
resume signalling timing is taken care of.
Check if the resume_done[port] is set before using it for timestamp
comparison, and also clear out any resume signalling related variables
if port is not in U0 or Resume state
This issue was discovered when a PM thread busylooped, trying to runtime
suspend the xhci USB 2 roothub on a Dell XPS
Cc: stable <stable@vger.kernel.org>
Reported-by: Daniel J Blueman <daniel@quora.org>
Tested-by: Daniel J Blueman <daniel@quora.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hopefully final set of fixes for v4.4 release cycle.
There's a fix for a regression on dwc3 caused by recent changes to how
transfers are started. We're not pre-starting interrupt endpoints
anymore.
A NULL pointer dereference fix for the MSM phy driver.
The UVC gadget got a minor fix for permissions to its configfs
attributes and, finally, two fixes for MUSB. A fix for PM runtime when
MUSB returns EPROBE_DEFER and a fix to actually return an error in case
we can't initialize a DMA engine.
Signed-off-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWaEy5AAoJEIaOsuA1yqRELFcP/jQxtHM4Yxyqg9Os1aER7biu
L99DVENwhTYbbiQw89irl0xobMCorQOc6l+p4cW1zpZ1binxFIdtriuBBsdlt1OS
lev3uieHvo6QALxFS6+/31YCFXVi2MKqmU/LGAbJ6nBYLMivyllfCThFwPkkEP3w
6nfHKPQHGXR9S3qmvWRZ4hhrfstPtzLuUYQg4PkT4TvTg+p586iOfdZukNkgSx44
AmOInfaf990JvMJKYHFBpCCmxrfimrUkxd4soV69Fz8HORl2ZzQ9OuEMoOPwiWDp
ALzKyd7gx2TED5mC8zJDz1JKKDhnJGiqDL9dgdZbTaLQVdbJdMS2g2zm/LU2wBIB
c9VniI4Tr6J3xpoZkBbo5BqpQedx9S5m9fsmRL5ZRd4XGiSkB0uSqQElgy+p+nR2
7zwhLuj5LuCPyi1yBSTSkI6/ExysNi4oSDTJWx2urU7LmMmZkD6V0GtoydSNBka3
ACKZQHHDu9virLABWJWxilcckxrajfDQUZ6jzk3DQPQqJjN1XuLTixbclBHHtyuv
CFq21kRMExqbLkon/KcD+NfAe6PTxONrZjmpOqPrOUN5bdnJQrpU5SAVvPIsg2an
hwfX7JdViu1SADxUehYaXMjPSq1Guyh31722HabtiueqFN4SgS4mqlR60SVasqgB
yNhBmVFPNsV8xiJW/wBo
=o5zI
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
usb: fixes for-v4.4-rc5
Hopefully final set of fixes for v4.4 release cycle.
There's a fix for a regression on dwc3 caused by recent changes to how
transfers are started. We're not pre-starting interrupt endpoints
anymore.
A NULL pointer dereference fix for the MSM phy driver.
The UVC gadget got a minor fix for permissions to its configfs
attributes and, finally, two fixes for MUSB. A fix for PM runtime when
MUSB returns EPROBE_DEFER and a fix to actually return an error in case
we can't initialize a DMA engine.
Signed-off-by: Felipe Balbi <balbi@ti.com>
76e0da3 "usb-gadget/uvc: use per-attribute show and store methods"
removed write permission for writeable attributes. Correct attribute
permissions.
Fixes: 76e0da3 "usb-gadget/uvc: use per-attribute show and store methods"
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
If musb_init_controller fails at musb_platform_init, we have already
called pm_runtime_irq_safe for musb and that causes the pm runtime count
to be enabled for parent before the parent has completed initialization.
This causes pm to stop working as on unload nothing gets idled.
This issue can be reproduced at least with:
# modprobe omap2430
HS USB OTG: no transceiver configured
musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
# modprobe phy-twl4030-usb
# rmmod omap2430
And after the steps above omap2430 will block deeper idle states on
omap3.
To fix this, let's not enable pm runtime until we need to and the
parent has been initialized. Note that this does not fix the issue of
PM being broken for musb during runtime.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
of_match_device could return NULL, and so cause a NULL pointer
dereference later.
Even if the probability of this case is very low, fixing it made
static analyzers happy.
Solving this with of_device_get_match_data made also code simplier.
Reported-by: coverity (CID 1324133)
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
When assigning bool use true instead of 1. If declaring it as static and
it's false there's no need to initialize it, since static variables are
zeroed by default.
Caught by coccinelle.
Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The module should fail to load.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
CC: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It shouldn't matter how usbcore is compiled. As it is a subsystem,
the correct way to use nousb should be usbcore.nousb
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace BUG() with BUG_ON().
Caught by coccinelle.
Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Get rid of bool explicit comparisons.
Caught by Coccinelle.
Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently usb_port_resume waits for up to 2 seconds for CONNECT
status for SS devices only. This change will do the same thing for
non-SS devices even though the reason is a little different. This
will fix an issue where VBUS is turned off during system wide
"suspend to ram" and some 2.0 devices take greater than the current
max of 100ms to show connected after VBUS is enabled. This is most
commonly seen on hard drive based devices and USB3.0 devices plugged
into a 2.0 only port.
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The interrupt handler, ohci_hcd_at91_overcurrent_irq may be called right
after registration. At that time, pdev->dev.platform_data is not yet set,
leading to a NULL pointer dereference.
Fixes: e4df92279f (USB: host: ohci-at91: merge loops in ohci_hcd_at91_drv_probe)
Reported-by: Peter Rosin <peda@axentia.se>
Tested-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: stable@vger.kernel.org # 4.3+
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
My recent Intel box is spewing these messages:
xhci_hcd 0000:00:14.0: xHCI Host Controller
xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2
usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: xHCI Host Controller
usb usb2: Manufacturer: Linux 4.3.0+ xhci-hcd
usb usb2: SerialNumber: 0000:00:14.0
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 6 ports detected
usb: failed to peer usb2-port2 and usb1-port1 by location (usb2-port2:none) (usb1-port1:usb2-port1)
usb usb2-port2: failed to peer to usb1-port1 (-16)
usb: port power management may be unreliable
usb: failed to peer usb2-port3 and usb1-port1 by location (usb2-port3:none) (usb1-port1:usb2-port1)
usb usb2-port3: failed to peer to usb1-port1 (-16)
usb: failed to peer usb2-port5 and usb1-port1 by location (usb2-port5:none) (usb1-port1:usb2-port1)
usb usb2-port5: failed to peer to usb1-port1 (-16)
usb: failed to peer usb2-port6 and usb1-port1 by location (usb2-port6:none) (usb1-port1:usb2-port1)
usb usb2-port6: failed to peer to usb1-port1 (-16)
Diving into the acpi tables, I noticed the EHCI hub has 12 ports while the XHCI
hub has 8 ports. Most of those ports are of connect type USB_PORT_NOT_USED
(including port 1 of the EHCI hub).
Further the unused ports have location data initialized to 0x80000000.
Now each unused port on the xhci hub walks the port list and finds a matching
peer with port1 of the EHCI hub because the zero'd out group id bits falsely match.
After port1 of the XHCI hub, each following matching peer will generate the
above warning.
These warnings seem to be harmless for this scenario as I don't think it
matters that unused ports could not create a peer link.
The attached patch utilizes that assumption and just turns the pr_warn into
pr_debug to quiet things down.
Tested on my Intel box.
Signed-off-by: Don Zickus <dzickus@redhat.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
if a full speed hub connects to a high speed hub which
supports MTT, the MTT field of its slot context will be set
to 1 when xHCI driver setups an xHCI virtual device in
xhci_setup_addressable_virt_dev(); once usb core fetch its
hub descriptor, and need to update the xHC's internal data
structures for the device, the HUB field of its slot context
will be set to 1 too, meanwhile MTT is also set before,
this will cause configure endpoint command fail, so in the
case, we should clear MTT to 0 for full speed hub according
to section 6.2.2
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is a memory leak because acpi_evaluate_dsm() actually returns an
object which the caller is supposed to release. Fix this by calling
ACPI_FREE() for the returned object (this expands to kfree() so passing
NULL there is fine as well).
While there correct indentation in !CONFIG_ACPI case.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: stable <stable@vger.kernel.org> # v4.2
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB3 LPM is default on in Linux kernel if both xHCI host controller
and the USB devices declare to be LPM-capable. Unfortunately, some
devices are known to work well with LPM disabled, but to be broken
if LPM is enabled, although it declares the LPM capability. Users
won't be able to use this kind of devices, until someone puts them
in the kernel blacklist and gets the kernel upgraded.
This patch adds a sysfs node to permit or forbit USB3 LPM U1 or U2
entry for a port. The settings apply to both before and after device
enumeration. Supported values are "0" - neither u1 nor u2 permitted,
"u1" - only u1 is permitted, "u2" - only u2 is permitted, "u1_u2" -
both u1 and u2 are permitted. With this interface, users can use an
LPM-unfriendly USB device on a released Linux kernel.
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 655fe4effe ("usbcore: add sysfs support to xHCI usb3
hardware LPM") introduced usb3_hardware_lpm sysfs node. This
doesn't show the correct status of USB3 U1 and U2 LPM status.
This patch fixes this by replacing usb3_hardware_lpm with two
nodes, usb3_hardware_lpm_u1 (for U1) and usb3_hardware_lpm_u2
(for U2), and recording the U1/U2 LPM status in right places.
This patch should be back-ported to kernels as old as 4.3,
that contains Commit 655fe4effe ("usbcore: add sysfs support
to xHCI usb3 hardware LPM").
Cc: stable@vger.kernel.org
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch sets the AHBMODE to allow for posted data writes. This
results in higher performance.
Signed-off-by: Andy Gross <agross@codeaurora.org>
Tested-by: Georgi Djakov <georgi.djakov@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch sets the AHBMODE to allow for posted data writes. This
results in higher performance.
Signed-off-by: Andy Gross <agross@codeaurora.org>
Acked-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
struct mon_bin_hdr allows for a 64-bit seconds timestamp. The code
currently uses 'struct timeval' to populate the timestamp in mon_bin_hdr,
which has a 32-bit seconds field and will overflow in year 2038 and beyond.
This patch replaces 'struct timeval' with 'struct timespec64' which is
y2038 safe. This patch is part of a larger attempt to remove instances
of struct timeval and other 32-bit timekeeping (time_t, struct timespec)
from the kernel.
Signed-off-by: Tina Ruchandani <ruchandani.tina@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
timeval is deprecated and not y2038 safe. Its size also changes according
to 32 bit/ 64 bit compilation. Replace it with 32 and 64 bit versions of
its individual fields, giving two ioctls with different code values.
The two ioctls are necessary to maintain the 32 bit and 64 bit userspace
compatibility with a 64/32 bit kernel.
Change unsigned to __u32 types for a definitive userspace interface.
This is in accordance with the psABI that the unsigned type is always
32 bits.
Also use motonic timer instead of real time to ensure positive delta
values.
Refactor usbtest_ioctl for readability to isolate the handling of the
testing timing measurement.
The official testusb userspace tool can be changed in a separate patch
to reflect the __u32 changes as well. It can use the usbtest_param_32
struct, since 32 bit seconds is long enough for test durations.
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
struct timeval' uses 32-bits for its seconds field and will overflow in
the year 2038 and beyond. This patch replaces the usage of 'struct timeval'
in mon_get_timestamp() with timespec64 which uses a 64-bit seconds field
and is y2038-safe. mon_get_timestamp() truncates the timestamp at 4096 seconds,
so the correctness of the code is not affected. This patch is part of a larger
attempt to remove instances of struct timeval and other 32-bit timekeeping
(time_t, struct timespec) from the kernel.
Signed-off-by: Tina Ruchandani <ruchandani.tina@gmail.com>
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
So far we were using simple (legacy) GPIO functions & some poor logic to
control power. It got many drawbacks: we were ignoring OF flags
(GPIO_ACTIVE_LOW), we were not setting direction to output and we were
assuming gpio_request success all the time.
Fix it by switching to gpiod functions and adding appropriate checks.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb_parse_ss_endpoint_companion() now decodes the burst multiplier
correctly in order to check that it's <= 3, but still uses the wrong
expression if warning that it's > 3.
Fixes: ff30cbc8da ("usb: Use the USB_SS_MULT() macro to get the ...")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
qset_fill_page_list() do not check for dma mapping errors.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When a USB 3.0 mass storage device is disconnected in transporting
state, storage device driver may handle it as a transport error and
reset the device by invoking usb_reset_and_verify_device()
and following could happen:
in usb_reset_and_verify_device():
udev->bos = NULL;
For U1/U2 enabled devices, driver will disable LPM, and in some
conditions:
from usb_unlocked_disable_lpm()
--> usb_disable_lpm()
--> usb_enable_lpm()
udev->bos->ss_cap->bU1devExitLat;
And it causes 'NULL pointer' and 'kernel panic':
[ 157.976257] Unable to handle kernel NULL pointer dereference
at virtual address 00000010
...
[ 158.026400] PC is at usb_enable_link_state+0x34/0x2e0
[ 158.031442] LR is at usb_enable_lpm+0x98/0xac
...
[ 158.137368] [<ffffffc0006a1cac>] usb_enable_link_state+0x34/0x2e0
[ 158.143451] [<ffffffc0006a1fec>] usb_enable_lpm+0x94/0xac
[ 158.148840] [<ffffffc0006a20e8>] usb_disable_lpm+0xa8/0xb4
...
[ 158.214954] Kernel panic - not syncing: Fatal exception
This commit moves 'udev->bos = NULL' behind usb_unlocked_disable_lpm()
to prevent from NULL pointer access.
Issue can be reproduced by following setup:
1) A SS pen drive behind a SS hub connected to the host.
2) Transporting data between the pen drive and the host.
3) Abruptly disconnect hub and pen drive from host.
4) With a chance it crashes.
Signed-off-by: Hans Yang <hansy@nvidia.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usb_mon_operations structure is never modified, so declare it as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now the function of complicated_callback is not only used for iso
transfer, improve the error message to reflect it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
for checking if a property is present or not,
of_property_read_bool is more appropriate than of_get_property()
Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This function must be called with a spinlock held.
Memory can be allocated only with GFP_ATOMIC. Passing
a gfp_t argument is a waste.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use this macro to make the driver more readable.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The dma_pool_destroy() function tests whether its argument is NULL
and then returns immediately. Thus the test around the calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
replace dma_pool_alloc and memset with a single call to dma_pool_zalloc
Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com>
Acked-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace the existing two extended capability parsing helper functions with
one called xhci_find_next_ext_cap().
The extended capabilities are read both in pci-quirks before xhci driver is
loaded, and inside the xhci driver when adding ports. The existing helpers
did not suit well for these cases and a lot of custom parsing code was
needed.
The new helper function simplifies these two cases a lot.
The motivation for this rework was that code to support xhci debug
capability needed to parse extended capabilities, and it included
yet another capability parsing helper specific for its needs. With
this solution it debug capability code can use this new helper as well
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Don't use dev_warn() for intened behaviour, use dev_dbg()
Rounding down the interval to the nearest power of 2 is required
by xhci specs.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There some vendor quirks for MTK xhci host controller:
1. It defines some extra SW scheduling parameters for HW
to minimize the scheduling effort for synchronous and
interrupt endpoints. The parameters are put into reseved
DWs of slot context and endpoint context.
2. Its IMODI unit for Interrupter Moderation register is
8 times as much as that defined in xHCI spec.
3. Its TDS in Normal TRB defines a number of packets that
remains to be transferred for a TD after processing all
Max packets in all previous TRBs.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Tested-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The R-Car H3 has two xHCI controllers. This SoC is compatible with
R-Car Gen2 SoCs, however this SoC doesn't need some specific registers
setting, and need a new firmware.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds support for R-Car M2-N (r8a7793) xHCI controller.
This SoC is compatible with R-Car H2 (r8a7790) and R-Car M2-W (r8a7791).
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
