Remove bogus (and unnecessary) test for serial->dev being NULL in close.
The device is never cleared, and close is never called after a completed
disconnect anyway.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove bogus (and unnecessary) test for serial->dev being NULL in close.
The device is never cleared, and close is never called after a completed
disconnect anyway.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove bogus (and unnecessary) test for serial->dev being NULL in close.
The device is never cleared, and close is never called after a completed
disconnect anyway.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove redundant port number from debug output (already printed as part
of device name).
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Failed allocations already get an OOM message and a stack dump.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove redundant port number from debug output (already printed as part
of device name).
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove redundant comments and fix some minor coding style issues.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rename the tty-port callbacks using a common prefix to more clearly
separate them from the tty and usb driver callbacks.
Rename serial_down to serial_port_shutdown to match the callback name.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pass usb-serial port rather than usb device to set_control_lines, and
make sure port device is used for all port related debugging.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use interface rather than usb-serial device for debugging interface
related operations. This gives more descriptive messages, such as
[ 905.669436] pl2303 1-4.1:1.0: 0x40:0x1:0x8:0x0 0
rather than
[ 341.943535] usb 1-4.1: 0x40:0x1:0x8:0x0 0
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove kill of interrupt-in urb on close as it has never been submitted.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove kill of interrupt-in urb on close as it has never been submitted.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove the port data refcounting and release the private data
explicitly at port remove.
The port data refcounting was used to make sure the port data was not
freed until the last tty reference was closed. Since moving over to tty
ports, the underlying assumptions are no longer valid as close is now
called as part of tty port shutdown, which can occur before the final
tty reference is dropped on device disconnect.
This means that the private port data refcounting is now completely
useless, as the last reference will always be dropped on port_remove.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1669) removes the check_unlinks_later flag in ehci-hcd's
unlink_empty_async(). It wasn't being used for anything and should
have been removed in an earlier patch, but I forgot about it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1665) changes the way ehci-hcd's end_unlink_async()
routine works in order to avoid recursive execution and to be more
efficient:
Now when an IAA cycle ends, a new one gets started up right
away (if it is needed) instead of waiting until the
just-unlinked QH has been processed.
The async_iaa list is renamed to async_idle, which better
expresses its new purpose: It is now the list of QHs which are
now completely idle and are waiting to be processed by
end_unlink_async().
A new flag is added to track whether an IAA cycle is in
progress, because the list formerly known as async_iaa no
longer stores the QHs waiting for the IAA to finish.
The decision about how many QHs to process when an IAA cycle
ends is now made at the end of the cycle, when we know the
current state of the hardware, rather than at the beginning.
This means a bunch of logic got moved from start_iaa_cycle()
to end_unlink_async().
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1664) converts ehci-hcd's async_unlink, async_iaa, and
intr_unlink from singly-linked lists to standard doubly-linked
list_heads. Originally it didn't seem necessary to use list_heads,
because items are always added to and removed from these lists in FIFO
order. But now with more list processing going on, it's easier to use
the standard routines than continue with a roll-your-own approach.
I don't know if the code ends up being notably shorter, but the
patterns will be more familiar to any kernel hacker.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1668) consolidates two nearly identical code paths in
ehci_urb_dequeue(). The test for !qh can be removed because it will
never succeed; the fact that usb_hcd_check_unlink_urb() returned 0
means that urb must be queued and therefore urb->hcpriv must point to
a QH.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1662) does some more QH-related cleanup in ehci-hcd.
The qh->needs_rescan flag is currently used for two different
purposes; the patch replaces it with two separate flags for greater
clarity: qh->dequeue_during_giveback indicates that a completion
handler dequeued an URB (implying that a rescan is needed), and
qh->exception indicates that the QH is in an exceptional state
requiring an unlink (either it encountered an I/O error or an unlink
was requested).
The new flags get set where the dequeue, exception, or unlink request
occurred, rather than where the unlink is started. This is so that in
the future, if we need to, we will be able to tell apart unlinks that
truly were required from those that were carried out merely because
the QH wasn't being used.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1658) cleans up the usage of qh_completions() in
ehci-hcd. Currently the function's return value indicates whether any
URBs were given back; the idea was that the caller can scan the QH
over again to handle any URBs that were dequeued by a completion
handler. This is not necessary; when qh_completions() is ready to
give back dequeued URBs, it does its own rescanning.
Therefore the new return value will be a flag indicating whether the
caller needs to unlink the QH. This is more convenient than forcing
the caller to check qh->needs_rescan, and it makes a lot more sense --
why should "needs_rescan" imply that an unlink is needed? The callers
are also changed to remove the unneeded rescans.
Lastly, the check for whether qh->qtd_list is non-empty is removed
from the start of qh_completions(). Two of the callers have to make
this test anyway, so the same test can simply be added to the other
two callers.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1638) makes several changes to the ehci-hcd driver, all
related to the qh_refresh() function. This function must be called
whenever an idle QH gets linked back into either the async or the
periodic schedule.
Change a BUG_ON() in the qh_update routine to a WARN_ON().
Since this code runs in atomic context, a BUG_ON() would
immediately freeze the whole system.
Remove two unneeded calls to qh_refresh(), one when a QH is
initialized and one when a QH becomes idle. Adjust the
adjacent comments accordingly.
Move the qh_refresh() and qh_link_periodic() calls for new
interrupt URBs to after the new TDs have been added.
As a result of the previous two changes, qh_refresh() is never
called when the qtd_list is empty. The corresponding check in
qh_refresh() can be removed, along with an indentation level.
These changes should not cause any alteration of behavior.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In skel_read,the reader blocked in wait_for_completion before submit
bulk in urb.
Using processed_urb is for retaining the completion in the case that
previous interruptible wait in skel_read was interrupted and complete
before next skel_read. Replacing completion with waitqueue can avoid
working around the counting nature of completions
and fix the bug.
Signed-off-by: Du Xing duxing2007@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Userspace applications need to know the maximum supported message
size.
The cdc-wdm driver translates between a character device stream
and a message based protocol. Each message is transported as a
usb control message with no further encapsulation or syncronization.
Each read or write on the character device should translate to
exactly one usb control message to ensure that message boundaries
are kept intact. That means that the userspace application must
know the maximum message size supported by the device and driver,
making this size a vital part of the cdc-wdm character device API.
CDC WDM and CDC MBIM functions export the maximum supported
message size through CDC functional descriptors. The cdc-wdm and
cdc_mbim drivers will parse these descriptors and use the value
chosen by the device. The only current way for a userspace
application to retrive the value is by duplicating the descriptor
parsing. This is an unnecessary complex task, and application
writers are likely to postpone it, using a fixed value and adding
a "todo" item.
QMI functions have no way to tell the host what message size they
support. The qmi_wwan driver use a fixed value based on protocol
recommendations and observed device behaviour. Userspace
applications must know and hard code the same value. This scheme
will break if we ever encounter a QMI device needing a device
specific message size quirk. We are currently unable to support
such a device because using a non default size would break the
implicit userspace API.
The message size is currently a hidden attribute of the cdc-wdm
userspace API. Retrieving it is unnecessarily complex, increasing
the possibility of drivers and applications using different limits.
The resulting errors are hard to debug, and can only be replicated
on identical hardware.
Exporting the maximum message size from the driver simplifies the
task for the userspace application, and creates a unified
information source independent of device and function class. It also
serves to document that the message size is part of the cdc-wdm
userspace API.
This proposed API extension has been presented for the authors of
userspace applications and libraries using the current API: libmbim,
libqmi, uqmi, oFono and ModemManager. The replies were:
Aleksander Morgado:
"We do really need max message size for MBIM; and as you say, it may be
good to have the max message size info also for QMI, so the new ioctl
seems a good addition. So +1 from my side, for what it's worth."
Dan Williams:
"Yeah, +1 here. I'd prefer the sysfs file, but the fact that that
doesn't work for fd passing pretty much kills it."
No negative replies are so far received.
Cc: Aleksander Morgado <aleksander@lanedo.com>
Cc: Dan Williams <dcbw@redhat.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Acked-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Return an error if hub->descriptor->bNbrPorts==0. Without this additional
check, we can end up doing a "hub->ports = kzalloc(0, GFP_KERNEL)".
This hub->ports pointer will therefore be non-NULL and will be used.
Example of dmesg:
INIT: usb 1-1: New USB device found, idVendor=0424, idProduct=2512
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 1-1:1.0: USB hub found
version 2.86 bootinghub 1-1:1.0: 0 ports detected
Unable to handle kernel NULL pointer dereference at virtual address 00000010
Signed-off-by: David Linares <dlinares.linux@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch comments on the case and requires that serial->type->suspend()
MUST return 0 in system sleep context.
Acked-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds comments on interface driver suspend callback
to emphasize that the failure return value is ignored by
USB core in system sleep context, so do not try to recover
device for this case and let resume/reset_resume callback
handle the suspend failure if needed.
Also kerneldoc for usb_suspend_both() is updated with the
fact.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When a device attached to the roothub is suspended, the endpoint rings
are stopped. The host may generate a completion event with the
completion code set to 'Stopped' or 'Stopped Invalid' when the ring is
halted. The current xHCI code prints a warning in that case, which can
be really annoying if the USB device is coming into and out of suspend.
Remove the unnecessary warning.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Stephen Hemminger <stephen@networkplumber.org>
Use proper macro while extracting TRB transfer length from
Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23)
for the same, and use it instead of TRB_LEN (bits 0:16) in
case of event TRBs.
This patch should be backported to kernels as old as 2.6.31, that
contain the commit b10de14211 "USB: xhci:
Bulk transfer support". This patch will have issues applying to older
kernels.
Signed-off-by: Vivek gautam <gautam.vivek@samsung.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
This patch is to bind xhci root hub usb port with its acpi node.
The port num in the acpi table matches with the sequence in the xhci
extended capabilities table. So call usb_hcd_find_raw_port_number() to
transfer hub port num into raw port number which associates with
the sequence in the xhci extended capabilities table before binding.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
xhci driver divides the root hub into two logical hubs which work
respectively for usb 2.0 and usb 3.0 devices. They are independent
devices in the usb core. But in the ACPI table, it's one device node
and all usb2.0 and usb3.0 ports are under it. Binding usb port with
its acpi node needs the raw port number which is reflected in the xhci
extended capabilities table. This patch is to add find_raw_port_number
callback to struct hc_driver(), fill it with xhci_find_raw_port_number()
which will return raw port number and add a wrap usb_hcd_find_raw_port_number().
Otherwise, refactor xhci_find_real_port_number(). Using
xhci_find_raw_port_number() to get real index in the HW port status
registers instead of scanning through the xHCI roothub port array.
This can help to speed up.
All addresses in xhci->usb2_ports and xhci->usb3_ports array are
kown good ports and don't include following bad ports in the extended
capabilities talbe.
(1) root port that doesn't have an entry
(2) root port with unknown speed
(3) root port that is listed twice and with different speeds.
So xhci_find_raw_port_number() will only return port num of good ones
and never touch bad ports above.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
/home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c: In function ‘handle_port_status’:
/home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c:1580: warning: ‘hcd’ may be used uninitialized in this function
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Fix the following sparse warnings:
drivers/usb/gadget/mv_u3d_core.c: In function ‘mv_u3d_ep_queue’:
drivers/usb/gadget/mv_u3d_core.c:812:2: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
drivers/usb/gadget/mv_u3d_core.c:822:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
drivers/usb/gadget/mv_u3d_core.c:823:4: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
drivers/usb/gadget/mv_u3d_core.c:823:28: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
drivers/usb/gadget/mv_u3d_core.c: In function ‘mv_u3d_ep_dequeue’:
drivers/usb/gadget/mv_u3d_core.c:905:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
drivers/usb/gadget/mv_u3d_core.c: In function ‘mv_u3d_probe’:
drivers/usb/gadget/mv_u3d_core.c:1840:3: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
drivers/usb/gadget/mv_u3d_core.c:1855:51: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
drivers/usb/gadget/mv_u3d_core.c:1855:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/usb/gadget/mv_u3d_core.c:1858:53: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
drivers/usb/gadget/mv_u3d_core.c:1858:18: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/usb/gadget/mv_u3d_core.c: In function ‘mv_u3d_irq_process_tr_complete’:
drivers/usb/gadget/mv_u3d_core.c:163:21: warning: ‘remaining_length’ may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/usb/gadget/mv_u3d_core.c:125:28: note: ‘remaining_length’ was declared here
Signed-off-by: Felipe Balbi <balbi@ti.com>
USB_GADGET_{DUAL,SUPER}SPEED symbols have
been removed by commit 85b8614 (usb: gadget:
get rid of USB_GADGET_{DUAL,SUPER}SPEED), for
some reason mv_u3d_core was lost.
Remove those selects now.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Make mv_u3d_pm_ops static because mv_u3d_pm_ops is not exported.
Also, CONFIG_PM_SLEEP is used to remove unnecessary ifdefs.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
VBUS_ERROR is a serious error that the driver often doesn't recover from
in my tests, so we should at least inform the user about it.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Some musb glue drivers use gadget_driver pointer to know if any gadget
drivers are loaded at some moment and base further decisions on it,
like to do runtime suspend/resume or not. Right now the pointer is
left alone on stop and OMAP musb glue later does wrong runtime_pm
decisions because of it.
Clear the gadget_driver pointer on remove, it's invalid after stop
anyway.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
As the usb transceiver driver usually starts first, it should already
have default_a variable set according to ID pin state, so don't
override it. In case default_a was not changed by trasceiver, it will
default to 0 and this code will work as before.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This reverts commit 27b351c554. It caused
problems with the build.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Bill Pemberton <wfp5p@viridian.itc.virginia.edu>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure waiting processes are woken on modem-status changes.
Currently processes are only woken on termios changes regardless of
whether the modem status has changed.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
