Userspace can tell the kernel to power off any USB port, including ones
that are visible and connectible to users. When an attached USB device
goes into suspend, the port will be powered off if the
pm_qos_no_port_poweroff file for its port is set to 0, the device does
not have remote wakeup enabled, and the device is marked as persistent.
If the user disconnects the USB device while the port is powered off,
the current code does not handle that properly. If you disconnect a
device, and then run `lsusb -v -s` for the device, the device disconnect
does not get handled by the USB core. The runtime resume of the port
fails, because hub_port_debounce_be_connected() returns -ETIMEDOUT.
This means the port resume fails and khubd doesn't handle the USB device
disconnect. This leaves the device listed in lsusb, and the port's
runtime_status will be permanently marked as "error".
Fix this by ignoring the return value of hub_port_debounce_be_connected.
Users can disconnect USB devices while the ports are powered off, and we
must be able to handle that.
This patch should be backported to kernels as old as 3.9, that
contain the commit ad493e5e58 "usb: add
usb port auto power off mechanism"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Lan Tianyu <tianyu.lan@intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The pm qos NO_POWER_OFF flag is checked twice during usb device suspend
to see if the usb port power off condition is met. This is redundant and
also will prevent the port from being powered off if the NO_POWER_OFF
flag is changed to 1 from 0 after the device was already suspended.
More detail in the following link.
http://marc.info/?l=linux-usb&m=136543949130865&w=2
This patch should be backported to kernels as old as 3.7, that
contain the commit f7ac7787ad "usb/acpi:
Use ACPI methods to power off ports."
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.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.
Note: Sarah fixed this patch to apply against 3.11, since the original
commit (4fae6f0fa8 "USB: handle LPM errors
during device suspend correctly") called usb_disable_remote_wakeup,
which won't be added until 3.12.
This patch should be backported to kernels as old as 3.5, that
contain the commit 8306095fd2 "USB:
Disable USB 3.0 LPM in critical sections.". There will be merge
conflicts, since LTM wasn't added until 3.6.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
Make sure the USB control request is allocated separately from
containing structure to prevent potential memory corruption on
non-cache-coherent systems.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure serial DMA-buffers are allocated separately from containing
structure to prevent potential memory corruption on non-cache-coherent
systems.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure serial DMA-buffers are allocated separately from containing
structure to prevent potential memory corruption on non-cache-coherent
systems.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure port DMA-buffers are allocated separately from containing
structure to prevent potential memory corruption on non-cache-coherent
systems.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure serial DMA-buffers are allocated separately from containing
structure to prevent potential memory corruption on non-cache-coherent
systems.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure to fail properly if the device is not accepted during attach
in order to avoid null-pointer derefs (of missing interface private
data) at disconnect or release.
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The parallel-port code of the drivers used a stack allocated
control-request buffer for asynchronous (and possibly deferred) control
requests. This not only violates the no-DMA-from-stack requirement but
could also lead to corrupt control requests being submitted.
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The chipidea i.MX driver is split into two drivers. The ci_hdrc_imx driver
handles the chipidea cores and the usbmisc_imx driver handles the noncore
registers common to all chipidea cores (but SoC specific). Current flow is:
- usbmisc sets an ops pointer in the ci_hdrc_imx driver during probe
- ci_hdrc_imx checks if the pointer is valid during probe, if yes calls
the functions in the ops pointer.
- usbmisc_imx calls back into the ci_hdrc_imx driver to get additional
data
This is overly complicated and has problems if the drivers are compiled
as modules. In this case the usbmisc_imx driver can be unloaded even if
the ci_hdrc_imx driver still needs usbmisc functionality.
This patch changes this by letting the ci_hdrc_imx driver calling functions
from the usbmisc_imx driver. This way the symbol resolving during module
load makes sure the ci_hdrc_imx driver depends on the usbmisc_imx driver.
Also instead of letting the usbmisc_imx driver call back into the ci_hdrc_imx
driver, pass the needed data in the first place.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently, the controller only runs when the ci->vbus_active is true.
So the flag CI_HDRC_PULLUP_ON_VBUS is useless no longer.
If the user doesn't have otgsc, he/she needs to change ci_handle_vbus_change
to update ci->vbus_active.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CI_HDRC_REGS_SHARED stands for the controller registers is shared
with other USB drivers, if all USB drivers are at chipidea/, it doesn't
needed to be set.
CI_HDRC_PULLUP_ON_VBUS stands for pullup dp when the vbus is on. This
flag doesn't need to be set if the vbus is always on for gadget
since dp has always pulled up after the gadget has initialized.
So, the current code seems to misuse this two flags.
- When the gadget initializes, the controller doesn't need to run if
it depends on vbus (CI_HDRC_PULLUP_ON_VBUS), it does not relate to
shared register.
- When the gadget starts (load one gadget module), the controller
can run if vbus is on (CI_HDRC_PULLUP_ON_VBUS), it also does not
relate to shared register.
Tested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When the gadget role starts, we need to make sure the vbus is lower
than OTGSC_BSV, or there will be an vbus interrupt since we use
B_SESSION_VALID as vbus interrupt to indicate connect and disconnect.
When the host role starts, it may not be useful to wait vbus to lower
than OTGSC_BSV, but it can indicate some hardware problems like the
vbus is still higher than OTGSC_BSV after we disconnect to host some
time later (5000 milliseconds currently), which is obvious not correct.
Tested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We add vbus interrupt handler at ci_otg_work, it uses OTGSC_BSV(at otgsc)
to know it is connect or disconnet event.
Meanwhile, we introduce two flags id_event and b_sess_valid_event to
indicate it is an id interrupt or a vbus interrupt.
Tested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since we need otgsc to know vbus's status at some chipidea
controllers even it is peripheral-only mode. Besides, some
SoCs (eg, AR9331 SoC) don't have otgsc register even
the DCCPARAMS_DC and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS.
We inroduce flag CI_HDRC_DUAL_ROLE_NOT_OTG to indicate if the
controller is dual role, but not supports OTG. If this flag is
not set, we follow the rule that if DCCPARAMS_DC and DCCPARAMS_HC
are both 1 at CAP_DCCPARAMS, then this controller is otg capable.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- The role's init will be called at probe procedure.
- The role's destroy will be called at fail patch
at probe and driver's removal.
- The role's start/stop will be called when specific
role has started.
Tested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For boards which have board level vbus control (eg, through gpio), we
need to vbus operation according to below rules:
- For host, we need open vbus before start hcd, and close it
after remove hcd.
- For otg, the vbus needs to be on/off when usb role switches.
When the host roles begins, it opens vbus; when the host role
finishes, it closes vbus.
We put vbus operation to host as host is the only vbus user,
When we are at host mode, the vbus is on, when we are not at
host mode, vbus should be off.
Tested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 40dcd0e ("usb: chipidea: add PTW, PTS and STS handling") introduced
the following code to the ci_hdrc_probe() function:
+ if (!dev->of_node && dev->parent)
+ dev->of_node = dev->parent->of_node;
This inadvertently associates the ci_hdrc device with the ci_hdrc_imx
driver (which created the ci_hdrc device in the first place).
This results in ci_hdrc_imx_probe() being run for the ci_hdrc device
if ci_hdrc_probe() fails for some reason.
ci_hdrc_imx_probe() will happily create a new ci_hdrc platform_device
whose probing will likewise fail and trigger a new invocation of
ci_hdrc_imx_probe() ... ad nauseam.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Reviewed-and-tested-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch provides a cleaner solution to the problem described in
commit 20a677fd ("usb: chipidea: improve kconfig").
The goal to be achieved is to force USB_CHIPIDEA=m if either
USB_EHCI_HCD=m or USB_GADGET=m.
If both are 'y' USB_CHIPIDEA may be selected to be 'm' or 'y'.
The old patch had the drawback, that USB_CHIPIDEA could be chosen as
'y' though USB_EHCI_HCD or USB_GADGET (or both) were 'm' leading to a
situation where USB_CHIPIDEA_HOST or USB_CHIPIDEA_UDC vanished from
the config options producing a compilable but dysfunctional driver.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Reviewed-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently hw_phymode_configure() is located inside hw_device_reset(), which is
only called by chipidea udc driver.
When operating in host mode, we also need to call hw_phymode_configure() in
order to properly configure the PHY mode, so move this function into probe.
After this change, USB Host1 port on mx53qsb board is functional.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Tested-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Reviewed-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
if pdata is a NULL pointer we could cause a
kernel oops when probing the driver. Make sure
to cope with systems which won't pass pdata
to the driver.
Tested-by: Paul Zimmerman <paulz@synopsys.com>
Reported-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rh_call_control() contains a buffer, tbuf, which it uses to hold
USB descriptors. These discriptors are eventually copied into the
transfer_buffer in the URB. The buffer in the URB is dynamically
defined and is always large enough to hold the amount of data it
requests.
tbuf is currently statically allocated on the stack with a size
of 15 bytes, regardless of the size specified in the URB.
This patch dynamically allocates tbuf, and ensures that tbuf is
at least as big as the buffer in the URB.
If an hcd attempts to write a descriptor containing more than
15 bytes ( such as the Standard BOS Descriptor for hubs, defined
in the USB3.0 Spec, section 10.13.1 ) the write would overflow
the buffer and corrupt the stack. This patch addresses this
behavior.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sean O. Stalley <sean.stalley@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9841f37a1c ("usb: ehci: Add support for SINGLE_STEP_SET_FEATURE
test of EHSET") added additional code to the EHCI hub driver but it is
anticipated to only have a limited audience (e.g. embedded silicon
vendors and integrators). Avoid subjecting all EHCI (and in the future
maybe xHCI/OHCI, etc.) HCD users to code bloat by conditionally
compiling the EHSET-specific additions with a new Kconfig option,
CONFIG_USB_HCD_TEST_MODE.
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver currently knows about 3 different PL2303 chip types:
The two legacy chip types type_0 and type_1 (PL2303H ?) and the HX
type.
The device distinction is currently completely based on the examination
of the USB descriptors.
During the last years, Prolific has introduced further PL2303 chips,
such as the HXD (HX rev. D), TA (which replaced the X/HX chips), SA,
RA, EA and TB variants.
Unfortunately, all these new chips are currently detected as HX chips,
because they are all using the same bMaxPacketSize0 = 0x40 value in the
USB device descriptor.
At this point it is not clear if these chips are really working with
the driver, there are just some positive indicators (like device
manufacturers claiming Linux support for these devices or commit
8d48fdf689 "correctly handle baudrates above 115200" which should only
be necessary for newer devices, ...)
For a complete support of all devices, we need to distinguish between
them, because they differ in several functional aspects, such as the
maximum supported baud rate (HXD, TB, EA: 12Mbps, HX, TA: 6Mbps,
RA: 1Mbps, SA: 115.2kbps), handshaking line support, RS422/485 and
GPIO ports support (currently not supported by the driver).
And there might be further differences that we don't know yet.
This patch improves the chip type detection by evaluating the bcdDevice
value of the device descriptor. The values are taken from the
datasheets and are safe to use because manufacturers can't change them:
3.00: X/HX, TA
4.00: HXD, EA, RA, SA
5.00: TB
The rest of the device descriptors is completely identical, so no
further distinction is possible this way.
Anyway, Prolifics "checkChipVersion.exe"-tool is definitely able to
distinguish for example between the X/HX and the TA chips, so there
must be a possibility to improve the distinction further...
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The chip type distinction is getting more and more relevant and
complicating, so always print the chip type.
Printing a name string is also much better than just printing an
internal index number.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is no need for two else-if constructs for the type_1 chip
detection in pl2303_startup(), so merge them.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The function dma_set_mask() tests internally whether the dma_mask pointer
for the device is initialized and fails if the dma_mask pointer is NULL.
On pci platforms, the device dma_mask pointer is initialized, when pci
devices are enumerated, to point to the pci_dev->dma_mask which is 0xffffffff.
However, for non-pci platforms, the dma_mask pointer may not be initialized
and in that case dma_set_mask() will fail.
This patch initializes the dma_mask and the coherent_dma_mask to 32bits
in xhci_plat_probe(), before the call to usb_create_hcd() that sets the
"uses_dma" flag for the usb bus and the call to usb_add_hcd() that creates
coherent dma pools for the usb hcd.
Moreover, a call to dma_set_mask() does not set the device coherent_dma_mask.
Since the xhci-hcd driver calls dma_alloc_coherent() and dma_pool_alloc()
to allocate consistent DMA memory blocks, the coherent DMA address mask
has to be set explicitly.
This patch sets the coherent_dma_mask to 64bits in xhci_gen_setup() when
the xHC is capable for 64-bit DMA addressing.
If dma_set_mask() succeeds, for a given bitmask, it is guaranteed that
the given bitmask is also supported for consistent DMA mappings.
Other changes introduced in this patch are:
- The return value of dma_set_mask() is checked to ensure that the required
dma bitmask conforms with the host system's addressing capabilities.
- The dma_mask setup code for the non-primary hcd was removed since both
primary and non-primary hcd refer to the same generic device whose
dma_mask and coherent_dma_mask are already set during the setup of
the primary hcd.
- The code for reading the HCCPARAMS register to find out the addressing
capabilities of xHC was removed since its value is already cached in
xhci->hccparams.
- hcd->self.controller was replaced with the dev variable since it is
already available.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch defines a new trace event, which is called xhci_dbg_ring_expansion
and belongs to the event class xhci_log_msg, and adds tracepoints that trace
the debug messages associated with the expansion of endpoint ring when there
is not enough space allocated to hold all pending TRBs.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch defines a new trace event, which is called xhci_dbg_init
and belongs to the event class xhci_log_msg, and adds tracepoints that
trace the debug statements in the functions used to start and stop the
xhci-hcd driver.
Also, it removes an unnecessary cast of variable val to unsigned int
in xhci_mem_init(), since val is already declared as unsigned int.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch defines a new trace event, which is called xhci_dbg_cancel_urb
and belongs to the event class xhci_log_msg, and adds tracepoints that
trace the debug messages related to the removal of a cancelled URB from
the endpoint's transfer ring.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch creates a new event class, called xhci_log_event,
and defines the xhci_cmd_completion trace event used for
tracing the commands issued to xHC that generate a completion
event in the event ring.
This info can be used, later, to print, in a human readable
way, the completion status and flags as well as the command's
type and fields using the trace-cmd tool and the appropriate
plugin.
Also, a tracepoint is added in handle_cmd_completion().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch defines a new event class, called xhci_log_ctx,
that records in the ring buffer the context data, the
context type (input or output), the context dma and virtual
addresses, the context endpoint entries, the slot ID and
whether the xHC uses 64 byte context data structures.
This information can be used, later, to parse and display
the context data fields with the appropriate plugin using
the trace-cmd tool.
Also, this patch defines a trace event, called xhci_address_ctx,
to trace the contexts related to the Address Device command and
adds the associated tracepoints in xhci_address_device().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch defines a new trace event, which is called xhci_dbg_reset_ep
and belongs in the event class xhci_log_msg, and adds tracepoints that
trace the debug messages associated with resetting an endpoint after
the reception of a STALL packet.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch defines a new trace event, which is called xhci_dbg_quirks
and belongs in the event class xhci_log_msg, and adds tracepoints that
trace the debug messages associated with xHCs' quirks.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch defines a new trace event, which is called xhci_dbg_context_change
and belongs in the event class xhci_log_msg, and adds tracepoints for tracing
the debug messages related to context updates performed with Configure Endpoint
and Evaluate Context commands.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch declares an event class for trace events that
trace messages with variadic arguments, called xhci_log_msg,
and defines a trace event for tracing the debug messages in
xhci_address_device() function, called xhci_dbg_address.
In order to implement this type of trace events, a wrapper function,
called xhci_dbg_trace(), was created that records the format string
and variadic arguments into a va_format structure which is passed as
argument to the tracepoints of the class xhci_log_msg.
All the xhci_dbg() calls in xhci_address_device() are replaced
with calls to xhci_dbg_trace(). The functionality of xhci_dbg()
log messages was not removed though, but it is placed inside
xhci_dbg_trace().
This trace event aims to give the ability to the user or the
developper to isolate and trace the debug messages generated
when an Address Device Command is issued to xHC.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
CONFIG_USB_XHCI_HCD_DEBUGGING option is used to enable
verbose debugging output for the xHCI host controller
driver.
In the current version of the xhci-hcd driver, this
option must be turned on, in order for the debugging
log messages to be displayed, and users may need to
recompile the linux kernel to obtain debugging
information that will help them track down problems.
This patch removes the above debug option to enable
debugging log messages at all times.
The aim of this is to rely on the debugfs and the
dynamic debugging feature for fine-grained management
of debugging messages and to not force users to set
the debug config option and compile the linux kernel
in order to have access in that information.
This patch, also, removes the XHCI_DEBUG symbol and the
functions dma_to_stream_ring(), xhci_test_radix_tree()
and xhci_event_ring_work() that are not useful anymore.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
