Re: What to use for usb transfer from gadget to host?
On Fri, Mar 21, 2014 at 4:58 AM, Pratyush Anand wrote: > How is your image sensor driver implemented? > If it is in v4l2 framework, then you can send your data to USB host > using uvc framework. See: drivers/usb/gadget/webcam.c > > The above would be be the standard way of doing such application. > > Regards > Pratyush Actually I have developed my own kernel module since the application of the video sensor is very specific. I would just need a fast way for image data to be transfered to the host. regards, tzippy >> I am familiar with USB on the host side, but not the gadget side. >> What's the best/easiest way to implement a simple 2 endpoints >> communication with high data rates? >> During my search I came across functionfs, gadgetfs, configfs and >> libusbg. Can you recommend one of them that suits my needs? >> Thank you so much! >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-usb" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usbnet: driver_info->stop required to stop USB interrupts?
On Thu, 2014-03-20 at 16:53 -0700, Julius Werner wrote: > >> Can you please explain why we need to check if the waitqueue is active? > > > > and add a comment that answers the above question. > > Oh the braces!!! Well, that's just mean... Yes, I was unsure about this, but so it is. > I expect that we don't really need the waitqueue_active() check there > as long as we fix the patch to make sure the control flow in the rest > of the statements actually stays the same. (That's why I really like > to put comments for an else block next to or under the opening brace, > instead of above with another empty line...) We cannot. If the driver intends to shut down traffic then resubmission in the bottom half must not happen. The check for the intention to shut down is necessary. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usbnet: driver_info->stop required to stop USB interrupts?
On Thu, 2014-03-20 at 14:19 -0700, Grant Grundler wrote:
> On Thu, Mar 20, 2014 at 9:35 AM, Grant Grundler wrote:
> > On Thu, Mar 20, 2014 at 12:15 AM, Oliver Neukum wrote:
> > ...
> >> I have an idea. Could you test this patch?
> > ...
> >> - if (dev->wait) {
> > ..
> >> + if (waitqueue_active(&dev->wait)) {
> >
> > Yes - building new image now (and transfer to USB and boot from USB).
> > Should know in an hour or so (doing other things in parallel).
>
> Sorry...took a bit longer since my previous test method (bash
> /tmp/reload_asix) was abusing a security exploit that is now
> fixed...so had to move my script into a RO executable file system:
>
> for i in `seq 1`; do echo -n "RELOAD $i " ; ssh $T
> "/bin/reload_asix eth0 1000_full" ; J=$? ; if [ $J -eq 255 ] ; then
> echo; " SSH timeout" ; break ; fi ; ssh $T "cat
> /var/log/reload-asix.out" ; if [ $J -ne 0 ] ; then echo " ERROR $J" ;
> fi ; sleep 3 ; done | tee ~/reload-AX88178-leon-192.168.1.100-06.out
>
> This is running now and things look happy so far. :) This will take
> more than 30h to complete.
Very well. Thorough testing is good. I'll wait for the result. Could
you notify me of the final outcome?
And, Julius, I owe you an apology. The check is necessary.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 03/11] usb: chipidea: host: init otg port number.
On Wed, Mar 19, 2014 at 10:06:28PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 03/19/2014 01:01 PM, Li Jun wrote:
>
> >Init otg_port number of otg capable host to be 1 at host start.
>
> >Signed-off-by: Li Jun
> >---
> > drivers/usb/chipidea/host.c |7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
>
> >diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
> >index 4b609bc..5ec8ccd 100644
> >--- a/drivers/usb/chipidea/host.c
> >+++ b/drivers/usb/chipidea/host.c
> >@@ -80,8 +80,13 @@ static int host_start(struct ci_hdrc *ci)
> > ret = usb_add_hcd(hcd, 0, 0);
> > if (ret)
> > goto disable_reg;
> >-else
> >+else {
>
>All arms of the *if* statement should have {} if at least one arm
> has it -- see Documentation/CodingStyle.
>
Good catch, I will update.
> > ci->hcd = hcd;
> >+if (ci_host_is_otg(ci)) {
> >+ci->transceiver->otg->host = &hcd->self;
> >+ci->transceiver->otg->host->otg_port = 1;
>
>Might be worth declaring a variable equal to 'ci->transceiver->otg'
> first...
>
Might be better, I will update too, thanks!
Li Jun
> >+}
> >+}
>
> WBR, Sergei
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Query: Link Power management support for xhci platform driver
Hi Sarah, I have to implement dynamic U1/U2 initiation on a dwc3 based xhci platform. I can see that my host starts sending LGO_U1 (when idle) by enabling XHCI_LPM_SUPPORT & XHCI_INTEL_HOST quirk in xhci_plat_quirks and using xhci_enable/disable_usb3_lpm_timeout in xhci_plat_xhci_driver. But offcourse that is not going to be the final solution. Before I float a RFC patch for it, I wanted to understand few things: -- I see there there are three functions xhci_calculate_intel_u1/u2_timeout & xhci_check_intel_tier_policy specific to XHCI_INTEL_HOST in the whole path. Since I do not see similar specification (which have been used in above function) in dwc3 specs, so I wanted to understand that how did you decide in function xhci_calculate_intel_u1_timeout that SEL should be multiplied (on top of what has been defined by USB3 specs C.1.5.1) by 3 if control ep is present or by 5 if bulk and so on or even how many number of hub should be allowed to enable LPM for any device. --Slot Context Max Exit Latency(MEL) has been programmed using MAX(U1_mel, u2_mel). Just for my understanding, can there be any situation when u1_mel is greater that u2_mel. If not then code can be simplified a bit. --Do you see any scenario where params.pel could be greater than params.sel? If not then do we really need to remember pel and do calculation based on it in xhci_get_timeout_no_hub_lpm? Regards Pratyush -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v4 0/4] xhci: re-work command queue management
changes since v3: * Use GFP_ATOMIC in xhci_stop_device() because we hold a spinlock * Don't queue commands if host is dying. * Flush command queue when host is dying (delete all commands in queue, call pending completions/free commands). changes since v2: squash first 7 patches together that all just created commands and avoid some nasty mid-patch series memory leaking changes since v1: Fixing smatch warnings and errors. Check for null return from alloc_command, release lock in error path and don't dereference possible null pointer in error path. release lock in xhci_stop_dev() error path. This is the fourth attempt to re-work and solve the issues in xhci command queue management that Sarah has described earlier: Right now, the command management in the xHCI driver is rather ad-hock. Different parts of the driver all submit commands, including interrupt handling routines, functions called from the USB core (with or without the bus bandwidth mutex held). Some times they need to wait for the command to complete, and sometimes they just issue the command and don't care about the result of the command. The places that wait on a command all time the command for five seconds, and then attempt to cancel the command. Unfortunately, that means if several commands are issued at once, and one of them times out, all the commands timeout, even though the host hasn't gotten a chance to service them yet. This is apparent with some devices that take a long time to respond to the Set Address command during device enumeration (when the device is plugged in). If a driver for a different device attempts to change alternate interface settings at the same time (causing a Configure Endpoint command to be issued), both commands timeout. Instead of having each command timeout after five seconds, the driver should wait indefinitely in an uninterruptible sleep on the command completion. A global command queue manager should time whatever command is currently running, and cancel that command after five seconds. If the commands were in a list, like TDs currently are, it may be easier to keep track of where the command ring dequeue pointer is, and avoid racing with events. We may need to have parts of the driver that issue commands without waiting on them still put the commands in the command list. The Implementation: --- First step is to create a list of the commands submitted to the command queue. To accomplish this each command is required to be submitted with a properly filled command structure containing completion, status variable and a pointer to the command TRB that will be used. The first patch is all about creating these command structures and submitting them when we queue commands. The command structures are allocated on the fly, the commands that are submitted in interrupt context are allocated with GFP_ATOMIC. Next, the global command queue is introduced. Commands structures are added to the queue when trb's are queued, and removed when the command completes. Also switch to use the status variable and completion in the command struct. A new timer handles command timeout, the timer is kicked every time when a command finishes and there's a new command waiting in the queue, or when a new command is submitted to an _empty_ command queue. Timer is deleted when the the last command on the queue finishes (empty queue) The old cancel_cmd_list is removed. When the timer expires we simply tag the current command as "ABORTED" and start the ring abortion process. Functions waiting for an aborted command to finish are called after the command abortion is completed. Mathias Nyman (4): xhci: Use command structures when queuing commands on the command ring xhci: Add a global command queue xhci: Use completion and status in global command queue xhci: rework command timeout and cancellation, drivers/usb/host/xhci-hub.c | 43 ++-- drivers/usb/host/xhci-mem.c | 18 +- drivers/usb/host/xhci-ring.c | 545 +++--- drivers/usb/host/xhci.c | 264 +++-- drivers/usb/host/xhci.h | 44 ++-- 5 files changed, 385 insertions(+), 529 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v4 4/4] xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for
the command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the commands to us.
All the aborted commands are now turned into No-ops.
This allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-hub.c | 11 +-
drivers/usb/host/xhci-mem.c | 15 +-
drivers/usb/host/xhci-ring.c | 337 +--
drivers/usb/host/xhci.c | 78 --
drivers/usb/host/xhci.h | 8 +-
5 files changed, 140 insertions(+), 309 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 252441d..0373487 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -271,7 +271,6 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
struct xhci_virt_device *virt_dev;
struct xhci_command *cmd;
unsigned long flags;
- int timeleft;
int ret;
int i;
@@ -304,12 +303,10 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
spin_unlock_irqrestore(&xhci->lock, flags);
/* Wait for last stop endpoint command to finish */
- timeleft = wait_for_completion_interruptible_timeout(
- cmd->completion,
- XHCI_CMD_DEFAULT_TIMEOUT);
- if (timeleft <= 0) {
- xhci_warn(xhci, "%s while waiting for stop endpoint command\n",
- timeleft == 0 ? "Timeout" : "Signal");
+ wait_for_completion(cmd->completion);
+
+ if (cmd->status == COMP_CMD_ABORT || cmd->status == COMP_CMD_STOP) {
+ xhci_warn(xhci, "Timeout while waiting for stop endpoint
command\n");
ret = -ETIME;
}
xhci_free_command(xhci, cmd);
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 38dc721..fd26e5b 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1793,7 +1793,6 @@ void xhci_free_command(struct xhci_hcd *xhci,
void xhci_mem_cleanup(struct xhci_hcd *xhci)
{
struct device *dev = xhci_to_hcd(xhci)->self.controller;
- struct xhci_cd *cur_cd, *next_cd;
int size;
int i, j, num_ports;
@@ -1809,17 +1808,15 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
xhci->event_ring = NULL;
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Freed event ring");
+ del_timer_sync(&xhci->cmd_timer);
+
if (xhci->lpm_command)
xhci_free_command(xhci, xhci->lpm_command);
if (xhci->cmd_ring)
xhci_ring_free(xhci, xhci->cmd_ring);
xhci->cmd_ring = NULL;
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Freed command ring");
- list_for_each_entry_safe(cur_cd, next_cd,
- &xhci->cancel_cmd_list, cancel_cmd_list) {
- list_del(&cur_cd->cancel_cmd_list);
- kfree(cur_cd);
- }
+
xhci_cleanup_command_queue(xhci);
for (i = 1; i < MAX_HC_SLOTS; ++i)
@@ -2323,7 +2320,6 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
u32 page_size, temp;
int i;
- INIT_LIST_HEAD(&xhci->cancel_cmd_list);
INIT_LIST_HEAD(&xhci->cmd_list);
page_size = readl(&xhci->op_regs->page_size);
@@ -2510,6 +2506,11 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
"Wrote ERST address to ir_set 0.");
xhci_print_ir_set(xhci, 0);
+ /* init command timeout timer */
+ init_timer(&xhci->cmd_timer);
+ xhci->cmd_timer.data = (unsigned long) xhci;
+ xhci->cmd_timer.function = xhci_handle_command_timeout;
+
/*
* XXX: Might need to set the Interrupter Moderation Register to
* something other than the default (~1ms minimum between interrupts).
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-
[RFC v4 3/4] xhci: Use completion and status in global command queue
Remove the per-device command list and handle_cmd_in_cmd_wait_list()
and use the completion and status variables found in the
command structure in the global command list.
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-hub.c | 11 --
drivers/usb/host/xhci-mem.c | 1 -
drivers/usb/host/xhci-ring.c | 84
drivers/usb/host/xhci.c | 16 ++---
drivers/usb/host/xhci.h | 3 --
5 files changed, 17 insertions(+), 98 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index fca8061..252441d 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -299,7 +299,6 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
suspend);
}
}
- list_add_tail(&cmd->cmd_list, &virt_dev->cmd_list);
xhci_queue_stop_endpoint(xhci, cmd, slot_id, 0, suspend);
xhci_ring_cmd_db(xhci);
spin_unlock_irqrestore(&xhci->lock, flags);
@@ -311,18 +310,8 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
if (timeleft <= 0) {
xhci_warn(xhci, "%s while waiting for stop endpoint command\n",
timeleft == 0 ? "Timeout" : "Signal");
- spin_lock_irqsave(&xhci->lock, flags);
- /* The timeout might have raced with the event ring handler, so
-* only delete from the list if the item isn't poisoned.
-*/
- if (cmd->cmd_list.next != LIST_POISON1)
- list_del(&cmd->cmd_list);
- spin_unlock_irqrestore(&xhci->lock, flags);
ret = -ETIME;
- goto command_cleanup;
}
-
-command_cleanup:
xhci_free_command(xhci, cmd);
return ret;
}
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index b070a17..38dc721 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1020,7 +1020,6 @@ int xhci_alloc_virt_device(struct xhci_hcd *xhci, int
slot_id,
dev->num_rings_cached = 0;
init_completion(&dev->cmd_completion);
- INIT_LIST_HEAD(&dev->cmd_list);
dev->udev = udev;
/* Point to output device context in dcbaa. */
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 5ee07c5..ff6ea85 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -69,10 +69,6 @@
#include "xhci.h"
#include "xhci-trace.h"
-static int handle_cmd_in_cmd_wait_list(struct xhci_hcd *xhci,
- struct xhci_virt_device *virt_dev,
- struct xhci_event_cmd *event);
-
/*
* Returns zero if the TRB isn't in this segment, otherwise it returns the DMA
* address of the TRB.
@@ -763,7 +759,6 @@ static void xhci_handle_cmd_stop_ep(struct xhci_hcd *xhci,
int slot_id,
union xhci_trb *trb, struct xhci_event_cmd *event)
{
unsigned int ep_index;
- struct xhci_virt_device *virt_dev;
struct xhci_ring *ep_ring;
struct xhci_virt_ep *ep;
struct list_head *entry;
@@ -773,11 +768,7 @@ static void xhci_handle_cmd_stop_ep(struct xhci_hcd *xhci,
int slot_id,
struct xhci_dequeue_state deq_state;
if (unlikely(TRB_TO_SUSPEND_PORT(le32_to_cpu(trb->generic.field[3] {
- virt_dev = xhci->devs[slot_id];
- if (virt_dev)
- handle_cmd_in_cmd_wait_list(xhci, virt_dev,
- event);
- else
+ if (!xhci->devs[slot_id])
xhci_warn(xhci, "Stop endpoint command "
"completion for disabled slot %u\n",
slot_id);
@@ -1230,29 +1221,6 @@ static void xhci_complete_cmd_in_cmd_wait_list(struct
xhci_hcd *xhci,
}
-/* Check to see if a command in the device's command queue matches this one.
- * Signal the completion or free the command, and return 1. Return 0 if the
- * completed command isn't at the head of the command list.
- */
-static int handle_cmd_in_cmd_wait_list(struct xhci_hcd *xhci,
- struct xhci_virt_device *virt_dev,
- struct xhci_event_cmd *event)
-{
- struct xhci_command *command;
-
- if (list_empty(&virt_dev->cmd_list))
- return 0;
-
- command = list_entry(virt_dev->cmd_list.next,
- struct xhci_command, cmd_list);
- if (xhci->cmd_ring->dequeue != command->command_trb)
- return 0;
-
- xhci_complete_cmd_in_cmd_wait_list(xhci, command,
- GET_COMP_CODE(le32_to_cpu(event->status)));
- return 1;
-}
-
/*
* Finding the command trb need to be cancelled and modifying it to
* NO OP command. And if the command is in device's command wait
@@ -1404,7 +1372,6 @@ static void xhci_handle_cmd_enable_sl
[RFC v4 2/4] xhci: Add a global command queue
Create a list to store command structures, add a structure to it every time
a command is submitted, and remove it from the list once we get a
command completion event matching the command.
Callers that wait for completion will free their command structures themselves.
The other command structures are freed in the command completion event handler.
Also add a check that prevents queuing commands if host is dying
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-mem.c | 2 ++
drivers/usb/host/xhci-ring.c | 34 ++
drivers/usb/host/xhci.c | 2 --
drivers/usb/host/xhci.h | 2 ++
4 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index c089668..b070a17 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1821,6 +1821,7 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
list_del(&cur_cd->cancel_cmd_list);
kfree(cur_cd);
}
+ xhci_cleanup_command_queue(xhci);
for (i = 1; i < MAX_HC_SLOTS; ++i)
xhci_free_virt_device(xhci, i);
@@ -2324,6 +2325,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
int i;
INIT_LIST_HEAD(&xhci->cancel_cmd_list);
+ INIT_LIST_HEAD(&xhci->cmd_list);
page_size = readl(&xhci->op_regs->page_size);
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 8f0489a..5ee07c5 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1521,6 +1521,20 @@ static void xhci_handle_cmd_nec_get_fw(struct xhci_hcd
*xhci,
NEC_FW_MINOR(le32_to_cpu(event->status)));
}
+static void xhci_del_and_free_cmd(struct xhci_command *cmd)
+{
+ list_del(&cmd->cmd_list);
+ if (!cmd->completion)
+ kfree(cmd);
+}
+
+void xhci_cleanup_command_queue(struct xhci_hcd *xhci)
+{
+ struct xhci_command *cur_cmd, *tmp_cmd;
+ list_for_each_entry_safe(cur_cmd, tmp_cmd, &xhci->cmd_list, cmd_list)
+ xhci_del_and_free_cmd(cur_cmd);
+}
+
static void handle_cmd_completion(struct xhci_hcd *xhci,
struct xhci_event_cmd *event)
{
@@ -1529,6 +1543,7 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
dma_addr_t cmd_dequeue_dma;
u32 cmd_comp_code;
union xhci_trb *cmd_trb;
+ struct xhci_command *cmd;
u32 cmd_type;
cmd_dma = le64_to_cpu(event->cmd_trb);
@@ -1546,6 +1561,13 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
return;
}
+ cmd = list_entry(xhci->cmd_list.next, struct xhci_command, cmd_list);
+
+ if (cmd->command_trb != xhci->cmd_ring->dequeue) {
+ xhci_err(xhci,
+"Command completion event does not match command\n");
+ return;
+ }
trace_xhci_cmd_completion(cmd_trb, (struct xhci_generic_trb *) event);
cmd_comp_code = GET_COMP_CODE(le32_to_cpu(event->status));
@@ -1615,6 +1637,9 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
xhci->error_bitmask |= 1 << 6;
break;
}
+
+ xhci_del_and_free_cmd(cmd);
+
inc_deq(xhci, xhci->cmd_ring);
}
@@ -4002,6 +4027,8 @@ static int queue_command(struct xhci_hcd *xhci, struct
xhci_command *cmd,
{
int reserved_trbs = xhci->cmd_ring_reserved_trbs;
int ret;
+ if (xhci->xhc_state & XHCI_STATE_DYING)
+ return -ESHUTDOWN;
if (!command_must_succeed)
reserved_trbs++;
@@ -4015,10 +4042,9 @@ static int queue_command(struct xhci_hcd *xhci, struct
xhci_command *cmd,
"unfailable commands failed.\n");
return ret;
}
- if (cmd->completion)
- cmd->command_trb = xhci->cmd_ring->enqueue;
- else
- kfree(cmd);
+
+ cmd->command_trb = xhci->cmd_ring->enqueue;
+ list_add_tail(&cmd->cmd_list, &xhci->cmd_list);
queue_trb(xhci, xhci->cmd_ring, false, field1, field2, field3,
field4 | xhci->cmd_ring->cycle_state);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 942aa7a..a8d0c50 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3733,7 +3733,6 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device
*udev)
timeleft == 0 ? "Timeout" : "Signal");
/* cancel the enable slot request */
ret = xhci_cancel_cmd(xhci, NULL, command->command_trb);
- kfree(command);
return ret;
}
@@ -3889,7 +3888,6 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct
usb_device *udev,
timeleft == 0 ? "Timeout" : "Signal", act);
/* cancel the address device command */
[RFC v4 1/4] xhci: Use command structures when queuing commands on the command ring
To create a global command queue we require that each command put on the
command ring is submitted with a command structure.
Functions that queue commands and wait for completion need to allocate a command
before submitting it, and free it once completed. The following command queuing
functions need to be modified.
xhci_configure_endpoint()
xhci_address_device()
xhci_queue_slot_control()
xhci_queue_stop_endpoint()
xhci_queue_new_dequeue_state()
xhci_queue_reset_ep()
xhci_configure_endpoint()
xhci_configure_endpoint() could already be called with a command structure,
and only xhci_check_maxpacket and xhci_check_bandwidth did not do so. These
are changed and a command structure is now required. This change also simplifies
the configure endpoint command completion handling and the "goto
bandwidth_change"
handling code can be removed.
In some cases the command queuing function is called in interrupt context.
These commands needs to be allocated atomically, and they can't wait for
completion. These commands will in this patch be freed directly after queuing,
but freeing will be moved to the command completion event handler in a later
patch once we get the global command queue up.(Just so that we won't leak
memory in the middle of the patch set)
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-hub.c | 21 +++--
drivers/usb/host/xhci-ring.c | 106 ---
drivers/usb/host/xhci.c | 194 ---
drivers/usb/host/xhci.h | 31 +++
4 files changed, 215 insertions(+), 137 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 1ad6bc1..fca8061 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -20,7 +20,8 @@
* Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-#include
+
+#include
#include
#include "xhci.h"
@@ -284,12 +285,22 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
spin_lock_irqsave(&xhci->lock, flags);
for (i = LAST_EP_INDEX; i > 0; i--) {
- if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue)
- xhci_queue_stop_endpoint(xhci, slot_id, i, suspend);
+ if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue) {
+ struct xhci_command *command;
+ command = xhci_alloc_command(xhci, false, false,
+GFP_ATOMIC);
+ if (!command) {
+ spin_unlock_irqrestore(&xhci->lock, flags);
+ xhci_free_command(xhci, cmd);
+ return -ENOMEM;
+
+ }
+ xhci_queue_stop_endpoint(xhci, command, slot_id, i,
+suspend);
+ }
}
- cmd->command_trb = xhci_find_next_enqueue(xhci->cmd_ring);
list_add_tail(&cmd->cmd_list, &virt_dev->cmd_list);
- xhci_queue_stop_endpoint(xhci, slot_id, 0, suspend);
+ xhci_queue_stop_endpoint(xhci, cmd, slot_id, 0, suspend);
xhci_ring_cmd_db(xhci);
spin_unlock_irqrestore(&xhci->lock, flags);
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 5f926be..8f0489a 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -123,16 +123,6 @@ static int enqueue_is_link_trb(struct xhci_ring *ring)
return TRB_TYPE_LINK_LE32(link->control);
}
-union xhci_trb *xhci_find_next_enqueue(struct xhci_ring *ring)
-{
- /* Enqueue pointer can be left pointing to the link TRB,
-* we must handle that
-*/
- if (TRB_TYPE_LINK_LE32(ring->enqueue->link.control))
- return ring->enq_seg->next->trbs;
- return ring->enqueue;
-}
-
/* Updates trb to point to the next TRB in the ring, and updates seg if the
next
* TRB is in a new segment. This does not skip over link TRBs, and it does not
* effect the ring dequeue or enqueue pointers.
@@ -682,12 +672,14 @@ static void td_to_noop(struct xhci_hcd *xhci, struct
xhci_ring *ep_ring,
}
}
-static int queue_set_tr_deq(struct xhci_hcd *xhci, int slot_id,
+static int queue_set_tr_deq(struct xhci_hcd *xhci,
+ struct xhci_command *cmd, int slot_id,
unsigned int ep_index, unsigned int stream_id,
struct xhci_segment *deq_seg,
union xhci_trb *deq_ptr, u32 cycle_state);
void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
+ struct xhci_command *cmd,
unsigned int slot_id, unsigned int ep_index,
unsigned int stream_id,
struct xhci_dequeue_state *deq_state)
@@ -702,7 +694,7 @@ void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
deq_state->new_deq_ptr,
(unsigned long
long)xhci_trb_virt_to_dma(deq
[RESEND] [PATCH] xhci: Switch Intel Lynx Point ports to EHCI on shutdown.
The same issue like with Panther Point chipsets. If the USB ports are
switched to xHCI on shutdown, the xHCI host will send a spurious interrupt,
which will wake the system. Some BIOS have work around for this, but not all.
One example is Compulab's mini-desktop, the Intense-PC2.
The bug can be avoided if the USB ports are switched back to EHCI on
shutdown.
Signed-off-by: Denis Turischev
---
drivers/usb/host/xhci-pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 3c898c1..9233d12 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -134,6 +134,8 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
*/
if (pdev->subsystem_vendor == PCI_VENDOR_ID_HP)
xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
+
+ xhci->quirks |= XHCI_SPURIOUS_REBOOT;
}
if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
pdev->device == PCI_DEVICE_ID_ASROCK_P67) {
-- 1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Not enough host controller resources for new device state.
Hi, (ever so awesome and we are all super unworthy) - Kernel peoples! I have found this dmesg error message which appears to be written in the xHCI host controller. (or maybe it originated in EHCI, i don't know.) None the less the issue is: "Not enough host controller resources for new device state" I noticed from a few git repos. that this is in the xhci.c file that the code has below it: FIXME: can we allocate more resources for the HC? Anyway, the git has Sarah Sharp on it. Sarah, are you on this mailing list? So I would really like to know how to get some more of these pretty resources... if its possible at all? I am running Kernal 3.11.0-12-generic, but am happy to change if I have to. A very brief summary is that I'm trying to connect 16 CDC usb devices to one machine. ( I do engineering for artists and I build these: http://vimeo.com/60491636 ) I have a full description of my investigations on serverfault.com http://serverfault.com/questions/583528/not-enough-host-controller-resources-for-new-device-state I'm really at a loss here on where to go next with this and I have a major international airport coming up to Stockholm next week to see some of my work. best regards. David Cox -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: octeon-usb: prevent memory corruption
On Thu, 20 Mar 2014, Aaro Koskinen wrote:
> octeon-hcd will crash the kernel when SLOB is used. This usually happens
> after the 18-byte control transfer when a device descriptor is read.
> The DMA engine is always transfering full 32-bit words and if the
> transfer is shorter, some random garbage appears after the buffer.
> The problem is not visible with SLUB since it rounds up the allocations
> to word boundary, and the extra bytes will go undetected.
>
> Fix by providing quirk functions for DMA map/unmap that allocate a bigger
> temporary buffer when necessary. Tested by booting EdgeRouter Lite
> to USB stick root file system with SLAB, SLOB and SLUB kernels.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=72121
> Reported-by: Sergey Popov
> Signed-off-by: Aaro Koskinen
> ---
> drivers/staging/octeon-usb/octeon-hcd.c | 108
>
> 1 file changed, 108 insertions(+)
>
> diff --git a/drivers/staging/octeon-usb/octeon-hcd.c
> b/drivers/staging/octeon-usb/octeon-hcd.c
> index 5a001d9..9c152f9 100644
> --- a/drivers/staging/octeon-usb/octeon-hcd.c
> +++ b/drivers/staging/octeon-usb/octeon-hcd.c
> @@ -465,6 +465,112 @@ struct octeon_hcd {
> #define USB_FIFO_ADDRESS(channel, usb_index) (CVMX_USBCX_GOTGCTL(usb_index)
> + ((channel)+1)*0x1000)
>
> /**
> + * struct octeon_temp_buffer - a bounce buffer for USB transfers
> + * @temp_buffer: the newly allocated temporary buffer (including meta-data)
> + * @orig_buffer: the original buffer passed by the USB stack
> + * @data: the newly allocated temporary buffer (excluding meta-data)
> + *
> + * Both the DMA engine and FIFO mode will always transfer full 32-bit words.
> If
> + * the buffer is too short, we need to allocate a temporary one, and this
> struct
> + * represents it.
> + */
> +struct octeon_temp_buffer {
> + void *temp_buffer;
> + void *orig_buffer;
> + u8 data[0];
> +};
> +
> +/**
> + * octeon_alloc_temp_buffer - allocate a temporary buffer for USB transfer
> + *(if needed)
> + * @urb: URB.
> + * @mem_flags: Memory allocation flags.
> + *
> + * This function allocates a temporary bounce buffer whenever it's needed
> + * due to HW limitations.
> + */
> +static int octeon_alloc_temp_buffer(struct urb *urb, gfp_t mem_flags)
> +{
> + struct octeon_temp_buffer *temp;
> +
> + if (urb->num_sgs || urb->sg ||
> + (urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP) ||
> + !(urb->transfer_buffer_length % sizeof(u32)))
> + return 0;
> +
> + temp = kmalloc(ALIGN(urb->transfer_buffer_length, sizeof(u32)) +
> +sizeof(*temp), mem_flags);
> + if (!temp)
> + return -ENOMEM;
> +
> + temp->temp_buffer = temp;
> + temp->orig_buffer = urb->transfer_buffer;
> + if (usb_urb_dir_out(urb))
> + memcpy(temp->data, urb->transfer_buffer,
> +urb->transfer_buffer_length);
> + urb->transfer_buffer = temp->data;
> + urb->transfer_flags |= URB_ALIGNED_TEMP_BUFFER;
> +
> + return 0;
> +}
> +
>
I don't think you need the temp_buffer in struct octeon_temp_buffer.
Once you have temp in octeon_free_temp_buffer via container_of, just free
temp. There is no need to look at temp_buffer to get its address.
Thomas Pugliese
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Check if usb device is suspended
I want to resume the usb device on some event, so i want to check if it is suspended. I think by above method i can check if the device is already suspended, but may be i will miss to resume the device if it is suspending. Is there any way through which i can check if device is suspending? On Thu, Mar 13, 2014 at 7:50 PM, Alan Stern wrote: > On Thu, 13 Mar 2014, Jagdish Gedia wrote: > >> Hi, >> I want to check in my driver if usb device is suspended or not? > > Why do you need to check? Your driver gets told every time the device > suspends and every time it resumes. Therefore it should already know > the answer. > >> currently i am doing it like >> >> if(udev->state==USB_STATE_SUSPENDED) >> >> Is this the proper way? Is this enough? > > Aside from the fact that the device's state may change immediately > after you make this test, as Oliver pointed out, you also should > realize that this test might not give the correct answer if the device > is in the middle of suspending or resuming when the test runs. > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] [PATCH] xhci: Switch Intel Lynx Point ports to EHCI on shutdown.
On 03/21/2014 12:01 PM, Denis Turischev wrote: The same issue like with Panther Point chipsets. If the USB ports are switched to xHCI on shutdown, the xHCI host will send a spurious interrupt, which will wake the system. Some BIOS have work around for this, but not all. One example is Compulab's mini-desktop, the Intense-PC2. The bug can be avoided if the USB ports are switched back to EHCI on shutdown. I'll queue this up and send it forward to Greg once 3.15-rc1 is out -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Check if usb device is suspended
On Fri, 2014-03-21 at 17:17 +0530, Jagdish Gedia wrote: > I want to resume the usb device on some event, so i want to check if > it is suspended. I think by above method i can check if the device is > already suspended, but may be i will miss to resume the device if it > is suspending. Is there any way through which i can check if device is > suspending? Just don't do that. If a device needs to be awake for some operation, call usb_autopm_get(). If the device is already awake, it is a nop besides keeping the device awake. Checking is not a sensible strategy. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: status of the xHCI clear halt bug?
On 03/20/2014 11:10 PM, Sarah Sharp wrote: On Sun, Mar 16, 2014 at 07:52:30PM +0100, Martin Dauskardt wrote: Hi Sarah, I lost track on this issue. Is there a final patch? Is it ready for integration into the kernel? Is there any kernel version that includes a fix? Is there any timeline? Mathias was working on this fix, but wanted to address some issues in the global command queue patches before starting on this task. Mathias is taking over as xHCI maintainer after 3.15, so he can better provide a timeline for when it will get fixed. I'll started looking at it but put it on hold to get the command queue patches in shape. There are no patches yet. I'll continue on it once the command queue work is ready. Hopefully soon. -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Deadlock in usb-storage error handling
On Thu, 20 Mar 2014, James Bottomley wrote:
> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> index 771c16b..c52bfb2 100644
> --- a/drivers/scsi/scsi_error.c
> +++ b/drivers/scsi/scsi_error.c
> @@ -145,14 +145,14 @@ scmd_eh_abort_handler(struct work_struct *work)
> "scmd %p retry "
> "aborted command\n", scmd));
> scsi_queue_insert(scmd, SCSI_MLQUEUE_EH_RETRY);
> - return;
> + goto out;
> } else {
> SCSI_LOG_ERROR_RECOVERY(3,
> scmd_printk(KERN_WARNING, scmd,
> "scmd %p finish "
> "aborted command\n", scmd));
> scsi_finish_command(scmd);
> - return;
> + goto out;
> }
> } else {
> SCSI_LOG_ERROR_RECOVERY(3,
> @@ -162,6 +162,8 @@ scmd_eh_abort_handler(struct work_struct *work)
> }
> }
>
> + scmd->eh_eflags &= ~SCSI_EH_ABORT_SCHEDULED;
> +
> if (!scsi_eh_scmd_add(scmd, 0)) {
> SCSI_LOG_ERROR_RECOVERY(3,
> scmd_printk(KERN_WARNING, scmd,
> @@ -170,6 +172,10 @@ scmd_eh_abort_handler(struct work_struct *work)
> scmd->result |= DID_TIME_OUT << 16;
> scsi_finish_command(scmd);
> }
> + return;
> + out:
> + scmd->eh_eflags &= ~SCSI_EH_ABORT_SCHEDULED;
> + return;
> }
>
> /**
Andreas, I think this patch will go a long way toward fixing your
problem. Try it out. It won't eliminate the reset, but it should
prevent all those error messages you've been getting and it should
prevent your system from hanging.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] xhci: Maintainership change for 3.15.
On Fri, Mar 21, 2014 at 08:09:09AM -0700, Sarah Sharp wrote: > The following changes since commit 1d10255c1c496557a5674e651c4ebbe0f61279f2: > > USB: disable reset-resume when USB_QUIRK_RESET is set (2014-03-19 14:00:32 > -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git > tags/for-usb-next-adventure > > for you to fetch changes up to 03d85053b611b6611e027a54fd5a1f188844cae0: > > xhci: Transition maintainership to Mathias Nyman. (2014-03-21 07:52:17 > -0700) > > > xhci: Maintainership change for 3.15. > > I've been working on USB for seven years at Intel, and it's time for a > change of pace. I'm pleased to announce that I'll be joining the Intel > OTC ChromeOS team, where I'll get to learn and play with everything > across the entire Linux stack, from kernel to graphics to browser > technologies. (I'm a secret adventure/indie/casual gamer, so I'm super > excited to start working on graphics features for ChromeOS.) > > I'm leaving the xHCI driver in Mathias Nyman's capable hands. I'll > still be around to answer any architectural questions or triage really > tough bugs, but I expect to ramp down on xHCI driver work in the coming > weeks. > > I'll be available to answer xHCI questions until I start my 8-week > sabbatical on May 8th. I'll be doing a National Parks road trip, and > it's unlikely I'll have cell coverage. And, let's face it, people are > supposed to ignore work email on sabbaticals. :) > > After my sabbatical ends on July 7th, I'll be focusing my time fully on > ChromeOS. It's been great working with and learning from Greg, Alan, > Oliver, and Felipe, but it's time to move onto my next adventure. > > So long, and thanks for all the fishes! > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=eb44da0b3aa0105cb38d81c5747a8feae64834be I thas been a great time working with you, Sarah and you will certainly be missed in linux-usb. In any case, good luck playing with ChromeOS. "Excelsior!" ;-) -- balbi signature.asc Description: Digital signature
[PATCH 1/1] xhci: Transition maintainership to Mathias Nyman.
I'm transitioning maintainership of the xHCI driver to my colleague, Mathias Nyman. The xHCI driver is in good shape, and it's time for me to move on to the next shiny thing. :) There's a few known outstanding bugs that we have plans for how to fix: 1. Clear Halt issue that means some USB scanners fail after one scan 2. TD fragment issue that means USB ethernet scatter-gather doesn't work 3. xHCI command queue issues that cause the driver to die when a USB device doesn't respond to a Set Address control transfer when another command is outstanding. 4. USB port power off for Haswell-ULT is a complete disaster. Mathias is putting the finishing touches on a fix for #3, which will make it much easier to craft a solution for #1. Dan William has an ACKed RFC for #4 that may land in 3.16, after much testing. I'm working with Mathias to come up with an architectural solution for #2. I don't foresee very many big features coming down the pipe for USB (which is part of the reason it's a good time to change now). SSIC is mostly a hardware-level change (perhaps with some PHY drivers needed), USB 3.1 is again mostly a hardware-level change with some software engineering to communicate the speed increase to the device drivers, add new device descriptor parsing to lsusb, but definitely nothing as big as USB 3.0 was. Signed-off-by: Sarah Sharp Signed-off-by: Mathias Nyman --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index c00366ee178e..d3764cd2d330 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9299,7 +9299,7 @@ S:Maintained F: drivers/net/wireless/rndis_wlan.c USB XHCI DRIVER -M: Sarah Sharp +M: Mathias Nyman L: linux-usb@vger.kernel.org S: Supported F: drivers/usb/host/xhci* -- 1.8.5.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] xhci: Maintainership change for 3.15.
The following changes since commit 1d10255c1c496557a5674e651c4ebbe0f61279f2: USB: disable reset-resume when USB_QUIRK_RESET is set (2014-03-19 14:00:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-next-adventure for you to fetch changes up to 03d85053b611b6611e027a54fd5a1f188844cae0: xhci: Transition maintainership to Mathias Nyman. (2014-03-21 07:52:17 -0700) xhci: Maintainership change for 3.15. I've been working on USB for seven years at Intel, and it's time for a change of pace. I'm pleased to announce that I'll be joining the Intel OTC ChromeOS team, where I'll get to learn and play with everything across the entire Linux stack, from kernel to graphics to browser technologies. (I'm a secret adventure/indie/casual gamer, so I'm super excited to start working on graphics features for ChromeOS.) I'm leaving the xHCI driver in Mathias Nyman's capable hands. I'll still be around to answer any architectural questions or triage really tough bugs, but I expect to ramp down on xHCI driver work in the coming weeks. I'll be available to answer xHCI questions until I start my 8-week sabbatical on May 8th. I'll be doing a National Parks road trip, and it's unlikely I'll have cell coverage. And, let's face it, people are supposed to ignore work email on sabbaticals. :) After my sabbatical ends on July 7th, I'll be focusing my time fully on ChromeOS. It's been great working with and learning from Greg, Alan, Oliver, and Felipe, but it's time to move onto my next adventure. So long, and thanks for all the fishes! https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=eb44da0b3aa0105cb38d81c5747a8feae64834be Sarah Sharp (1): xhci: Transition maintainership to Mathias Nyman. MAINTAINERS |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: medtronic usb productId 0x8001: usbserial support, xhci enumeration
[ Adding Mathias Nyman as CC. ] On Thu, Mar 20, 2014 at 01:52:16PM -0700, Benjamin West wrote: > On Tue, Mar 18, 2014 at 1:10 AM, Johan Hovold wrote: > > On Mon, Mar 17, 2014 at 11:58:57PM -0700, Benjamin West wrote: > >> On Mon, Mar 17, 2014 at 11:40 AM, Johan Hovold wrote: > >> >> issues. It's included below > >> >> https://gist.github.com/bewest/6488955#file-lsusb > >> > >> > I'm responding to this mail with a patch for you to test. The patch is > >> > also available here: > >> > > >> > > >> > https://git.kernel.org/cgit/linux/kernel/git/johan/usb-serial.git/log/?h=carelink > >> > > >> > as a commit on top of usb-next. It's quite likely that the problem > >> > you've been having has already been fixed (in v3.14-rc) so I suggest > >> > just testing the carelink branch above. Remember to enable the > >> > usb-serial-simple driver. > > Just speculating, git log -SNEW_SCHEME yields > 48fc7dbd52c0559647291f33a10ccdc6cdbe4c72, it looks similar to the > other interesting patches. Yes, that is the commit I had in mind when I speculated that the problem might already have been fixed in v3.14-rc above. And indeed, without having looked to closely at this, it seems to at least have improved things as you no longer get the BABBLE error and actually manage to enumerate occasionally. > > Just to make sure this isn't a new regression in usb-next you're > > hitting, can you try applying the patch directly to v3.14-rc7? > Some mixed results: > I tested your carelink branch many more times. For some reason, it > started enumerating consistently for awhile, failed once, and then > enumerated consistently until I gave up. > > I cherry-picked your e2c7df19e2734f5d54d0d942a57d1018539e02c4 > on 3.14-rc7, which applied cleanly. Your changes work as expected here. > > The carelink usb stick did enumerate once or twice, here is a log: > https://gist.github.com/bewest/6488955#file-example-3-14-0-rc7-working-log > > I still often get failure to enumerate after inserting the usb stick: > I didn't keep an exact count, but this feels like a more consistent > failure somehow. > Recorded here: > https://gist.githubusercontent.com/bewest/6488955/raw/213a79af21735e8822e00d8afa05abd63ffd67ee/syslog.log > > Mar 20 00:22:34 patient logger: Linux patient > 3.14.0-rc7-bewest-test-3.14-rc7-carelink-01 #6 SMP Wed Mar 19 21:12:24 > PDT 2014 x86_64 x86_64 x86_64 GNU/Linux > Mar 20 00:22:40 patient kernel: [ 615.054659] usb 3-2: new full-speed > USB device number 41 using xhci_hcd > Mar 20 00:22:45 patient kernel: [ 620.167319] xhci_hcd :00:14.0: > Timeout while waiting for setup address command > Mar 20 00:22:50 patient kernel: [ 625.372047] xhci_hcd :00:14.0: > Timeout while waiting for setup address command > Mar 20 00:22:50 patient kernel: [ 625.576031] usb 3-2: device not > accepting address 41, error -62 > Mar 20 00:22:50 patient kernel: [ 625.688157] usb 3-2: new full-speed > USB device number 42 using xhci_hcd > Mar 20 00:23:06 patient kernel: [ 640.802272] usb 3-2: device > descriptor read/64, error -110 > Mar 20 00:23:06 patient kernel: [ 640.906255] xhci_hcd :00:14.0: > Setup ERROR: setup context command for slot 11. > Mar 20 00:23:06 patient kernel: [ 641.018244] usb 3-2: new full-speed > USB device number 43 using xhci_hcd > Mar 20 00:23:11 patient kernel: [ 646.01] xhci_hcd :00:14.0: > Timeout while waiting for setup address command > Mar 20 00:23:16 patient kernel: [ 651.223619] xhci_hcd :00:14.0: > Timeout while waiting for setup address command > Mar 20 00:23:16 patient kernel: [ 651.427649] usb 3-2: device not > accepting address 43, error -62 > Mar 20 00:23:16 patient kernel: [ 651.539702] usb 3-2: new full-speed > USB device number 44 using xhci_hcd > Mar 20 00:23:21 patient kernel: [ 656.540344] xhci_hcd :00:14.0: > Timeout while waiting for setup address command > Mar 20 00:23:27 patient kernel: [ 661.745070] xhci_hcd :00:14.0: > Timeout while waiting for setup address command > Mar 20 00:23:27 patient kernel: [ 661.949103] usb 3-2: device not > accepting address 44, error -62 > Mar 20 00:23:27 patient kernel: [ 661.949163] hub 3-0:1.0: unable to > enumerate USB device on port 2 > Mar 20 00:24:06 patient whoopsie[1220]: online Ok, looks like the same error as with usb-next. Could you provide a log with debugging enabled when enumeration fails on v3.14-rc7? Perhaps someone who knows more about xhci could be kind enough provide some further insight as to what might be going on then. > Something else interesting happened as well. > At some point, I got the following messages in the logs. After > receiving these messages, I tried several different usb devices, but > they all fail to enumerate after this. > > Sarah's branch seemed to enumerate consistently, but hard to quantify; > I'll bang on it a bit more, and try to keep track of error vs success > rates. > > -bewest > > P. S. I wasn't doing my usual log capture routine, but I believe I saw > th
Re: [PATCH] Add AsantePorter PID 0x7F38 to FTDI list
On Thu, Mar 20, 2014 at 02:24:30PM -0700, Benjamin West wrote:
> Johan and other usb-serial/ftdi maintainers,
Thanks for the patch! A couple of minor issues below.
> Here is a small patch for you which adds the PID for Asante Snap
> Pump's FTDI data cable to the device list. The Asante Snap pump is an
> insulin pump, this device is a usb cable which connects to their
> cradle.
> From 82bf3dcd649af33d8f41aa2098bd61bfa94cbc04 Mon Sep 17 00:00:00 2001
> From: Ben West
> Date: Wed, 19 Mar 2014 20:34:33 -0700
> Subject: [PATCH] Add AsantePorter PID 0x7F38 to FTDI list
Please use
"[PATCH] USB: ftdi_sio: add AsantePorter PID 0x7F38"
or similar as subject (i.e. with a "USB: ftdi_sio: "-prefix).
> This patch allows the ftdi usb serial module to create a device when
> an Asante Porter usb data cable is plugged in.
>
> Signed-off-by: Ben West
> ---
> drivers/usb/serial/ftdi_sio.c | 1 +
> drivers/usb/serial/ftdi_sio_ids.h | 5 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> index 44ab129..7f26fa1 100644
> --- a/drivers/usb/serial/ftdi_sio.c
> +++ b/drivers/usb/serial/ftdi_sio.c
> @@ -688,6 +688,7 @@ static const struct usb_device_id id_table_combined[] = {
> { USB_DEVICE(EVOLUTION_VID, EVO_HYBRID_PID) },
> { USB_DEVICE(EVOLUTION_VID, EVO_RCM4_PID) },
> { USB_DEVICE(FTDI_VID, FTDI_ARTEMIS_PID) },
> + { USB_DEVICE(FTDI_VID, FTDI_ASANTE_PORTER_PID) },
scripts/checkpatch.pl (a useful tool you should run your patches through
before submitting) complains:
WARNING: please, no spaces at the start of a line
#107: FILE: drivers/usb/serial/ftdi_sio.c:691:
+ { USB_DEVICE(FTDI_VID, FTDI_ASANTE_PORTER_PID) },$
> { USB_DEVICE(FTDI_VID, FTDI_ATIK_ATK16_PID) },
> { USB_DEVICE(FTDI_VID, FTDI_ATIK_ATK16C_PID) },
> { USB_DEVICE(FTDI_VID, FTDI_ATIK_ATK16HR_PID) },
> diff --git a/drivers/usb/serial/ftdi_sio_ids.h
> b/drivers/usb/serial/ftdi_sio_ids.h
> index e599fbf..0602fd6 100644
> --- a/drivers/usb/serial/ftdi_sio_ids.h
> +++ b/drivers/usb/serial/ftdi_sio_ids.h
> @@ -194,6 +194,11 @@
> #define FTDI_ARTEMIS_PID 0xDF28 /* All Artemis Cameras */
>
> /*
> + * Definitions for Asante Porter, data cable for insulin pump.
> + */
> +#define FTDI_ASANTE_PORTER_PID 0x7F38 /* Asante Porter */
I'd use a tab to indent the comment after the define here.
> +
> +/*
> * Definitions for ATIK Instruments astronomical USB based cameras
> * Check it at http://www.atik-instruments.com/
> */
Care to fix that up and resubmit (then you should also add "v2" to your
subject line, as in, "[PATCH v2] USB: ...")?
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v4 4/4] xhci: rework command timeout and cancellation,
On 03/21/2014 11:35 AM, Mathias Nyman wrote:
+void xhci_handle_command_timeout(unsigned long data)
+{
+ struct xhci_hcd *xhci;
+ int ret;
+ unsigned long flags;
+ xhci = (struct xhci_hcd *) data;
+ /* mark this command to be cancelled */
+ spin_lock_irqsave(&xhci->lock, flags);
+ if (xhci->current_cmd)
+ xhci->current_cmd->status = COMP_CMD_ABORT;
+ spin_unlock_irqrestore(&xhci->lock, flags);
+
+ ret = xhci_abort_cmd_ring(xhci);
+
+ if (ret) {
+ xhci_err(xhci, "Abort command ring failed\n");
+ if (unlikely(ret == -ESHUTDOWN)) {
+ xhci_cleanup_command_queue(xhci);
+ usb_hc_died(xhci_to_hcd(xhci)->primary_hcd);
+ xhci_dbg(xhci, "xHCI host controller is dead.\n");
+ }
+ }
+ return;
+}
+
After some more testing and fault injection it turns out that
xhci_abort_cmd_ring() returns 0 if command ring is already stopped. In
this case the command submitter will still be left hanging, and khubd
wait forever.
So one more round to fix this is still needed.
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Query: Link Power management support for xhci platform driver
Cc-ing Mathias Nyman, who is taking over as xHCI driver maintainer. On Fri, Mar 21, 2014 at 02:37:22PM +0530, Pratyush Anand wrote: > Hi Sarah, > > I have to implement dynamic U1/U2 initiation on a dwc3 based xhci > platform. I can see that my host starts sending LGO_U1 (when idle) by > enabling XHCI_LPM_SUPPORT & XHCI_INTEL_HOST quirk in xhci_plat_quirks > and using xhci_enable/disable_usb3_lpm_timeout in > xhci_plat_xhci_driver. But offcourse that is not going to be the final > solution. > > Before I float a RFC patch for it, I wanted to understand few things: Ok, I wrote the code two years ago and haven't really looked at it since, so I'll have to refresh my memory on the mouthful of acronyms. :) > -- I see there there are three functions > xhci_calculate_intel_u1/u2_timeout & xhci_check_intel_tier_policy > specific to XHCI_INTEL_HOST in the whole path. > Since I do not see similar specification (which have been used > in above function) in dwc3 specs, so I wanted to understand that how did > you decide in function xhci_calculate_intel_u1_timeout that SEL should > be multiplied (on top of what has been defined by USB3 specs C.1.5.1) by > 3 if control ep is present or by 5 if bulk and so on or even how > many number of hub should be allowed to enable LPM for any device. This was based on information given to me by the Intel chipset folks. Without knowledge of the constraints of the host and its internal scheduler, you can't really know how to calculate the timeouts. I do suspect the rule about the number of hubs that are allowed to enable LPM is an Intel-specific thing. Basically, you're going to have to work with Synopsys and TI to figure out if there's any hardware constraints for dw3. That's why we didn't enable LPM across the board for all xHCI 1.0 hosts. I wish the USB 3.0 spec and xHCI spec had exposed information that software could use to calculate U1/U2 timeouts, but like all power management features, it was shoved in late and not well-documented. > --Slot Context Max Exit Latency(MEL) has been programmed using MAX(U1_mel, > u2_mel). Just for my understanding, can there be any situation when > u1_mel is greater that u2_mel. If not then code can be simplified a bit. There's nothing in the spec that requires U1 MEL <= U2 MEL. In practice, I've never seen it happen, but you never know what USB device vendors will do. :) > --Do you see any scenario where params.pel could be greater than > params.sel? If not then do we really need to remember pel and do > calculation based on it in xhci_get_timeout_no_hub_lpm? So, looking at the log for commit 51e0a012066, it seems that SEL = PEL + some delay. I guess SEL will always be equal to or greater than PEL. I believe that I stored those variables mostly in case we ran into issues with USB 3.0 devices, so that we could (potentially) expose those values through sysfs, which might help with debugging. We haven't needed that, so you can probably safely not track PEL. ...and you do know that most USB 3.0 devices simply refuse to go into U1 and U2, right? I put in a lot of effort into enabling this feature, and found that most devices simply NAK the request to go into U1 or U2. You have to use a bus analyzer and be sure you're actually going into low power states when you're testing the dw3 code. There are a few devices out there that support USB 3.0 LPM (Western Digital My Passport, for example). Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usbnet: driver_info->stop required to stop USB interrupts?
On Fri, Mar 21, 2014 at 1:33 AM, Oliver Neukum wrote: ... > Very well. Thorough testing is good. I'll wait for the result. Could > you notify me of the final outcome? Ceratinly. Bad news is I had to restart my workstation that was driving the test due to completely different issue (loopbacks hung - known bug). reload_asix ran about 2000 iterations with no problems on AX88178 part. It's running again now on the same target machine. > And, Julius, I owe you an apology. The check is necessary. ++oliver Sorry to harp on this more, but I still think a comment is warranted: e.g. "Don't resend packets during shutdown of this USB net device." And instead of naming the queue "wait", call the field "shutdown queue". cheers, grant -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB host controller disabled after starting capture of webcam
Cc-ing Mathias Nyman, who is taking over as xHCI maintainer. On Fri, Mar 21, 2014 at 11:22:07AM +0800, Rick Chen wrote: > Hi Sarah, > > I use linux 3.13.6 to test Logitech C310 web cam but encounter the > following message and usb controller is disabled and all usb device freeze. > > [51237.045088] xhci_hcd :00:14.0: @f5ee903c (virt) @35ee903c (dma) > 0x00 - rsvd[2] > [51237.045099] xhci_hcd :00:14.0: OUT Endpoint 01 Context (ep_index 01): > [51237.045111] xhci_hcd :00:14.0: @f5ee9040 (virt) @35ee9040 (dma) > 0x00 - ep_info > [51237.045122] xhci_hcd :00:14.0: @f5ee9044 (virt) @35ee9044 (dma) > 0x00 - ep_info2 > [51237.045133] xhci_hcd :00:14.0: @f5ee9048 (virt) @35ee9048 (dma) > 0x00 - deq > [51237.045145] xhci_hcd :00:14.0: @f5ee9050 (virt) @35ee9050 (dma) > 0x00 - tx_info > [51237.045157] xhci_hcd :00:14.0: @f5ee9054 (virt) @35ee9054 (dma) > 0x00 - rsvd[0] > [51237.045174] xhci_hcd :00:14.0: @f5ee9058 (virt) @35ee9058 (dma) > 0x00 - rsvd[1] > [51237.045186] xhci_hcd :00:14.0: @f5ee905c (virt) @35ee905c (dma) > 0x00 - rsvd[2] > [51237.045197] xhci_hcd :00:14.0: IN Endpoint 01 Context (ep_index 02): > [51237.045209] xhci_hcd :00:14.0: @f5ee9060 (virt) @35ee9060 (dma) > 0x01 - ep_info > [51237.045220] xhci_hcd :00:14.0: @f5ee9064 (virt) @35ee9064 (dma) > 0x1800028 - ep_info2 > [51237.045232] xhci_hcd :00:14.0: @f5ee9068 (virt) @35ee9068 (dma) > 0x2ee7d001 - deq > [51237.045243] xhci_hcd :00:14.0: @f5ee9070 (virt) @35ee9070 (dma) > 0x1800180 - tx_info > [51237.045261] xhci_hcd :00:14.0: @f5ee9074 (virt) @35ee9074 (dma) > 0x00 - rsvd[0] > [51237.045273] xhci_hcd :00:14.0: @f5ee9078 (virt) @35ee9078 (dma) > 0x00 - rsvd[1] > [51237.045285] xhci_hcd :00:14.0: @f5ee907c (virt) @35ee907c (dma) > 0x00 - rsvd[2] > [51237.045371] xhci_hcd :00:14.0: Endpoint 0x81 not halted, refusing to > reset. > [51237.059334] xhci_hcd :00:14.0: ERROR no room on ep ring, try ring > expansion > [51237.059379] xhci_hcd :00:14.0: ring expansion succeed, now has 4 > segments > [51237.356238] xhci_hcd :00:14.0: ERROR no room on ep ring, try ring > expansion > [51237.356284] xhci_hcd :00:14.0: ring expansion succeed, now has 8 > segments > [51237.358047] xhci_hcd :00:14.0: ERROR no room on ep ring, try ring > expansion > [51237.358099] xhci_hcd :00:14.0: ring expansion succeed, now has 16 > segments > [51237.374744] xhci_hcd :00:14.0: ERROR no room on ep ring, try ring > expansion > [51237.374825] xhci_hcd :00:14.0: ring expansion succeed, now has 32 > segments > [51239.061291] xhci_hcd :00:14.0: Cancel URB f5ef9800, dev 3.3, ep > 0x81, starting at offset 0x2ee7d560 > [51239.061324] xhci_hcd :00:14.0: // Ding dong! > [51244.075493] xhci_hcd :00:14.0: xHCI host not responding to stop > endpoint command. > [51244.075519] xhci_hcd :00:14.0: Assuming host is dying, halting host. > [51244.075560] xhci_hcd :00:14.0: // Halt the HC > [51244.075582] xhci_hcd :00:14.0: Killing URBs for slot ID 1, ep index 0 > [51244.075599] xhci_hcd :00:14.0: Killing URBs for slot ID 1, ep index 2 > [51244.075627] xhci_hcd :00:14.0: Killing URBs for slot ID 2, ep index 0 > [51244.075644] xhci_hcd :00:14.0: Killing URBs for slot ID 2, ep index 2 > [51244.075666] xhci_hcd :00:14.0: Killing URBs for slot ID 3, ep index 0 > [51244.075693] xhci_hcd :00:14.0: Killing URBs for slot ID 3, ep index 2 > [51244.075879] xhci_hcd :00:14.0: Killing URBs for slot ID 3, ep index > 14 > [51244.075900] xhci_hcd :00:14.0: Killing URBs for slot ID 4, ep index 0 > [51244.075917] xhci_hcd :00:14.0: Killing URBs for slot ID 4, ep index 2 > [51244.075937] xhci_hcd :00:14.0: Killing URBs for slot ID 4, ep index 4 > [51244.075957] xhci_hcd :00:14.0: Killing URBs for slot ID 4, ep index 6 > [51244.075979] xhci_hcd :00:14.0: Calling usb_hc_died() > [51244.075994] xhci_hcd :00:14.0: HC died; cleaning up > [51244.076032] xhci_hcd :00:14.0: xHCI host controller is dead. > [51244.076445] hub 1-0:1.0: state 0 ports 6 chg evt > [51244.076480] usb 1-3: USB disconnect, device number 2 > [51244.076499] usb 1-3.1: USB disconnect, device number 3 > [51244.076515] usb 1-3.1.1: USB disconnect, device number 5 > [51244.076530] usb 1-3.1.1: unregistering device > [51244.076546] usb 1-3.1.1: unregistering interface 1-3.1.1:1.0 > [51244.154617] usb 1-3.1.1: unregistering interface 1-3.1.1:1.1 > [51244.208993] usb 1-3.1.1: unregistering interface 1-3.1.1:1.2 > [51244.248229] usb 1-3.1.1: usb_disable_device nuking all URBs > [51244.263954] usb 1-3.1: unregistering device > [51244.263963] usb 1-3.1: unregistering interface 1-3.1:1.0 > [51244.264235] usb 1-3.1: usb_disable_device nuking all URBs > [51244.268803] usb 1-3.3: USB disconnect, device number 4 > [51244.268810] usb 1-3.3: unregistering device > [51244.268816] usb 1-3.3: unregistering interface 1-3.3:1.0 > [51244.270
Re: xHCI oops in 3.13
On Sat, Mar 08, 2014 at 04:42:24PM +0100, Steinar H. Gunderson wrote: > I'm using a Sundtek DVB-C USB stick (with their userspace driver which works > over usbfs, as I understand it), and when I w_scan, after ~10 minutes or so > this happens: Hi, Did anyone have a chance to look at this? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] xhci: Maintainership change for 3.15.
On Fri, Mar 21, 2014 at 08:09:09AM -0700, Sarah Sharp wrote: > The following changes since commit 1d10255c1c496557a5674e651c4ebbe0f61279f2: > > USB: disable reset-resume when USB_QUIRK_RESET is set (2014-03-19 14:00:32 > -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git > tags/for-usb-next-adventure > > for you to fetch changes up to 03d85053b611b6611e027a54fd5a1f188844cae0: > > xhci: Transition maintainership to Mathias Nyman. (2014-03-21 07:52:17 > -0700) > > > xhci: Maintainership change for 3.15. > > I've been working on USB for seven years at Intel, and it's time for a > change of pace. I'm pleased to announce that I'll be joining the Intel > OTC ChromeOS team, where I'll get to learn and play with everything > across the entire Linux stack, from kernel to graphics to browser > technologies. (I'm a secret adventure/indie/casual gamer, so I'm super > excited to start working on graphics features for ChromeOS.) > > I'm leaving the xHCI driver in Mathias Nyman's capable hands. I'll > still be around to answer any architectural questions or triage really > tough bugs, but I expect to ramp down on xHCI driver work in the coming > weeks. > > I'll be available to answer xHCI questions until I start my 8-week > sabbatical on May 8th. I'll be doing a National Parks road trip, and > it's unlikely I'll have cell coverage. And, let's face it, people are > supposed to ignore work email on sabbaticals. :) > > After my sabbatical ends on July 7th, I'll be focusing my time fully on > ChromeOS. It's been great working with and learning from Greg, Alan, > Oliver, and Felipe, but it's time to move onto my next adventure. > > So long, and thanks for all the fishes! > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=eb44da0b3aa0105cb38d81c5747a8feae64834be Wow, almost 7 years. Thanks so much for what you've contributed to Linux, it's been invaluable, and much appreciated. Best of luck on your new position, and feel free to come back and send patches when you can, we need all the help we can get. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add quirk HID_QUIRK_NO_INIT_REPORTS for RNDPLUS touchscreen
There is timeout error during initialization:
kernel: [ 14.167086] hid-multitouch 0003:2512:5003.0001: usb_submit_urb(ctrl)
failed: -1
kernel: [ 14.167135] hid-multitouch 0003:2512:5003.0001: timeout initializing
reports
kernel: [ 14.167407] input: RNDPLUS Co., LTD PULSEIR TSR4601 as
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/input/input14
kernel: [ 14.167975] cpufreq_interactive: monitoring input on RNDPLUS Co.,
LTD PULSEIR TSR4601
kernel: [ 14.168266] hid-multitouch 0003:2512:5003.0001:
input,hiddev0,hidraw1: USB HID v1.10 Mouse [RNDPLUS Co., LTD PULSEIR TSR4601]
on usb-:00:1d.0-1.3/input0
Adding quirk HID_QUIRK_NO_INIT_REPORTS can solve the problem.
Signed-off-by: Yufeng Shen
---
drivers/hid/hid-ids.h | 5 +
drivers/hid/usbhid/hid-quirks.c | 3 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index f9304cb..772f937 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -442,6 +442,11 @@
#define USB_DEVICE_ID_IDEACOM_IDC6650 0x6650
#define USB_DEVICE_ID_IDEACOM_IDC6651 0x6651
+#define USB_VENDOR_ID_IDSPULSE 0x2512
+#define USB_DEVICE_ID_IDSPULSE_EVIR10x5003
+#define USB_DEVICE_ID_IDSPULSE_EVIR20x5004
+#define USB_DEVICE_ID_IDSPULSE_EVIR30x5005
+
#define USB_VENDOR_ID_ILITEK 0x222a
#define USB_DEVICE_ID_ILITEK_MULTITOUCH0x0001
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 0db9a67..e59ad07 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -72,6 +72,9 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_TS2700, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_FORMOSA, USB_DEVICE_ID_FORMOSA_IR_RECEIVER,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28,
HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_IDSPULSE, USB_DEVICE_ID_IDSPULSE_EVIR1,
HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_IDSPULSE, USB_DEVICE_ID_IDSPULSE_EVIR2,
HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_IDSPULSE, USB_DEVICE_ID_IDSPULSE_EVIR3,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GX680R_LED_PANEL,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_NOVATEK, USB_DEVICE_ID_NOVATEK_MOUSE,
HID_QUIRK_NO_INIT_REPORTS },
--
1.9.1.423.g4596e3a
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
oops with 3.13.6 also
$ uname -a Linux hellcat 3.13.6-gentoo #1 SMP PREEMPT Tue Mar 18 15:37:31 MDT 2014 x86_64 Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz GenuineIntel GNU/Linux $ dmesg [90294.076903] usb 4-4.3.3: new SuperSpeed USB device number 19 using xhci_hcd [90294.199632] usb-storage 4-4.3.3:1.0: USB Mass Storage device detected [90294.199822] scsi18 : usb-storage 4-4.3.3:1.0 [90295.210442] scsi 18:0:0:0: Direct-Access Generic- SD/MMC/MS/MSPRO 1.00 PQ: 0 ANSI: 6 [90295.210599] sd 18:0:0:0: Attached scsi generic sg3 type 0 [90295.221118] sd 18:0:0:0: [sdc] Attached SCSI removable disk [90336.357357] usb 4-4.3.3: reset SuperSpeed USB device number 19 using xhci_hcd [90336.410750] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e680 [90336.410752] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e6c0 [90418.315061] usb 4-4.3.3: reset SuperSpeed USB device number 19 using xhci_hcd [90418.367233] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e680 [90418.367237] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e6c0 [90709.265142] usb 4-4.3.3: reset SuperSpeed USB device number 19 using xhci_hcd [90709.317222] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e680 [90709.317224] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e6c0 [90803.516622] usb 4-4.3.3: reset SuperSpeed USB device number 19 using xhci_hcd [90803.568669] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e680 [90803.568673] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e6c0 [90918.257416] usb 4-4.3.3: reset SuperSpeed USB device number 19 using xhci_hcd [90918.309769] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e680 [90918.309772] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e6c0 [91078.075065] usb 4-4.3.3: reset SuperSpeed USB device number 19 using xhci_hcd [91078.127241] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e680 [91078.127244] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e6c0 [91270.676075] usb 4-4.3.3: reset SuperSpeed USB device number 19 using xhci_hcd [91270.728051] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e680 [91270.728055] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e6c0 [91614.898658] usb 4-4.3.3: reset SuperSpeed USB device number 19 using xhci_hcd [91614.950491] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e680 [91614.950493] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e6c0 [91770.618320] usb 4-4.3.3: reset SuperSpeed USB device number 19 using xhci_hcd [91770.670632] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e680 [91770.670636] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e6c0 [92166.300735] usb 4-4.3.3: reset SuperSpeed USB device number 19 using xhci_hcd [92166.352945] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e680 [92166.352946] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e6c0 [92176.339488] usb 4-4.3.3: reset SuperSpeed USB device number 19 using xhci_hcd [92176.391133] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e680 [92176.391136] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e6c0 [92645.517649] usb 4-4.3.3: reset SuperSpeed USB device number 19 using xhci_hcd [92645.569769] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e680 [92645.569773] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e6c0 [92663.958326] usb 4-4.3.3: reset SuperSpeed USB device number 19 using xhci_hcd [92664.010164] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e680 [92664.010168] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e6c0 [92733.621357] usb 4-4.3.3: reset SuperSpeed USB device number 19 using xhci_hcd [92733.673228] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e680 [92733.673231] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8804c153e6c0 [92878.077807] usb 1-1.4: USB disconnect, device number 11 [92878.798733] usb 1-1.4: new low-speed USB device number 13 using ehci-pci [92878.898719] input: USB USB Keykoard as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input26 [92878.898786] hid-generic 0003:1A2C:0002.000E: input: USB HID v1.10 Keyboard [USB USB Keykoard] on usb-:00:1a.0-1.4
Re: [PATCH] Add quirk HID_QUIRK_NO_INIT_REPORTS for RNDPLUS touchscreen
On Fri, Mar 21, 2014 at 3:39 PM, Yufeng Shen wrote:
> There is timeout error during initialization:
> kernel: [ 14.167086] hid-multitouch 0003:2512:5003.0001:
> usb_submit_urb(ctrl) failed: -1
> kernel: [ 14.167135] hid-multitouch 0003:2512:5003.0001: timeout
> initializing reports
> kernel: [ 14.167407] input: RNDPLUS Co., LTD PULSEIR TSR4601 as
> /devices/pci:00/:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/input/input14
> kernel: [ 14.167975] cpufreq_interactive: monitoring input on RNDPLUS Co.,
> LTD PULSEIR TSR4601
> kernel: [ 14.168266] hid-multitouch 0003:2512:5003.0001:
> input,hiddev0,hidraw1: USB HID v1.10 Mouse [RNDPLUS Co., LTD PULSEIR
> TSR4601] on usb-:00:1d.0-1.3/input0
>
> Adding quirk HID_QUIRK_NO_INIT_REPORTS can solve the problem.
I already asked you to test if HID_QUIRK_NO_INIT_INPUT_REPORTS was
working for the same same kind of timeout
(https://patchwork.kernel.org/patch/3544281/).
So I am asking again: please test HID_QUIRK_NO_INIT_INPUT_REPORTS and
if it works, use this quirk instead the one in this patch.
This *really* matters because the quirk HID_QUIRK_NO_INIT_REPORTS does
not initialize feature reports which contains important information
regarding hid-multitouch.
Cheers,
Benjamin
>
> Signed-off-by: Yufeng Shen
> ---
> drivers/hid/hid-ids.h | 5 +
> drivers/hid/usbhid/hid-quirks.c | 3 +++
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index f9304cb..772f937 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -442,6 +442,11 @@
> #define USB_DEVICE_ID_IDEACOM_IDC6650 0x6650
> #define USB_DEVICE_ID_IDEACOM_IDC6651 0x6651
>
> +#define USB_VENDOR_ID_IDSPULSE 0x2512
> +#define USB_DEVICE_ID_IDSPULSE_EVIR10x5003
> +#define USB_DEVICE_ID_IDSPULSE_EVIR20x5004
> +#define USB_DEVICE_ID_IDSPULSE_EVIR30x5005
> +
> #define USB_VENDOR_ID_ILITEK 0x222a
> #define USB_DEVICE_ID_ILITEK_MULTITOUCH0x0001
>
> diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
> index 0db9a67..e59ad07 100644
> --- a/drivers/hid/usbhid/hid-quirks.c
> +++ b/drivers/hid/usbhid/hid-quirks.c
> @@ -72,6 +72,9 @@ static const struct hid_blacklist {
> { USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_TS2700, HID_QUIRK_NOGET },
> { USB_VENDOR_ID_FORMOSA, USB_DEVICE_ID_FORMOSA_IR_RECEIVER,
> HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28,
> HID_QUIRK_NOGET },
> + { USB_VENDOR_ID_IDSPULSE, USB_DEVICE_ID_IDSPULSE_EVIR1,
> HID_QUIRK_NO_INIT_REPORTS },
> + { USB_VENDOR_ID_IDSPULSE, USB_DEVICE_ID_IDSPULSE_EVIR2,
> HID_QUIRK_NO_INIT_REPORTS },
> + { USB_VENDOR_ID_IDSPULSE, USB_DEVICE_ID_IDSPULSE_EVIR3,
> HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
> { USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GX680R_LED_PANEL,
> HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_NOVATEK, USB_DEVICE_ID_NOVATEK_MOUSE,
> HID_QUIRK_NO_INIT_REPORTS },
> --
> 1.9.1.423.g4596e3a
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM
Hi Mathias,
On Tue, Feb 18, 2014 at 11:04:12AM -0800, David Cohen wrote:
> On Tue, Feb 18, 2014 at 12:47:41PM -0600, Felipe Balbi wrote:
> > On Tue, Feb 18, 2014 at 10:00:30AM -0800, David Cohen wrote:
> > > Hi Sarah,
> > >
> > > On Mon, Jan 06, 2014 at 07:02:19PM -0800, David Cohen wrote:
> > > > When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
> > > > warning:
> > > > drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
> > > > but not used [-Wunused-function]
> > > >
> > > > It happens due to lack of __maybe_unused flag on xhci_msix_sync_irqs()
> > > > function in case of !CONFIG_PCI.
> > > >
> > > > Signed-off-by: David Cohen
> > > > ---
> > >
> > > Ping :)
> > > Any comments here?
> > >
> > > Br, David
> > >
> > > >
> > > > Change v1 -> v2:
> > > > - xhci_msix_sync_irqs() already uses __maybe_unused flag when
> > > > CONFIG_PCI is
> > > >set. Proper solution is to add same flag when !CONFIG_PCI instead of
> > > > define
> > > >function as inline.
> > > >
> > > > drivers/usb/host/xhci.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> > > > index 4265b48856f6..ed6b717b8ee1 100644
> > > > --- a/drivers/usb/host/xhci.c
> > > > +++ b/drivers/usb/host/xhci.c
> > > > @@ -406,7 +406,7 @@ static void xhci_cleanup_msix(struct xhci_hcd *xhci)
> > > > {
> > > > }
> > > >
> > > > -static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
> > > > +static void __maybe_unused xhci_msix_sync_irqs(struct xhci_hcd *xhci)
> >
> > bellow is likely a better fix. Usually stubs are marked inline, rather
> > than getting an unused attribute:
>
> Thanks for commenting. That would be actually the v1 of my patch :)
> I changed after I see the proper function has __maybe_unused flag.
>
> But I'm fine with Sarah picking any of the patch's versions.
Guess you're handling the review of this trivial patch now :)
Comments are very welcome.
Br, David
>
> Br, David
>
> >
> > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> > index 3712359..8f1a6d5 100644
> > --- a/drivers/usb/host/xhci.c
> > +++ b/drivers/usb/host/xhci.c
> > @@ -404,16 +404,16 @@ static int xhci_try_enable_msi(struct usb_hcd *hcd)
> >
> > #else
> >
> > -static int xhci_try_enable_msi(struct usb_hcd *hcd)
> > +static inline int xhci_try_enable_msi(struct usb_hcd *hcd)
> > {
> > return 0;
> > }
> >
> > -static void xhci_cleanup_msix(struct xhci_hcd *xhci)
> > +static inline void xhci_cleanup_msix(struct xhci_hcd *xhci)
> > {
> > }
> >
> > -static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
> > +static inline void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
> > {
> > }
> >
> >
> > --
> > balbi
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: host: Add MAX3421E HCD support.
Sorry, I keep forgetting how bad gmail is in handling patches... Here is a retransmit in plain-text format (really). The patch is relative to linux-next. The Maxim MAX3421E is a USB-over-SPI chip that can operate either in peripheral or host mode. This driver adds support for the host-mode only. The chip is USB 2.0 compliant with support for low- and full-speed devices. --- drivers/usb/Makefile |1 + drivers/usb/host/Kconfig | 10 + drivers/usb/host/Makefile |2 + drivers/usb/host/max3421.c | 1990 4 files changed, 2003 insertions(+) create mode 100644 drivers/usb/host/max3421.c diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index 1ae2bf3..c83c406 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -12,6 +12,7 @@ obj-$(CONFIG_USB_DWC2)+= dwc2/ obj-$(CONFIG_USB_MON) += mon/ obj-$(CONFIG_PCI) += host/ +obj-$(CONFIG_USB_MAX3421_HCD) += host/ obj-$(CONFIG_USB_EHCI_HCD) += host/ obj-$(CONFIG_USB_ISP116X_HCD) += host/ obj-$(CONFIG_USB_OHCI_HCD) += host/ diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 3d9e540..98fe7f3 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -3,6 +3,16 @@ # comment "USB Host Controller Drivers" +config USB_MAX3421_HCD + tristate "MAX3421 HCD (USB-over-SPI) support" + depends on USB + help + The Maxim MAX3421E Host Controller Interface supports +standard USB 2.0-compliant full-speed devices. + + To compile this driver as a module, choose M here: the module will +be called max3421. + config USB_C67X00_HCD tristate "Cypress C67x00 HCD support" help diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index 7530468..afcef27 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -25,6 +25,8 @@ obj-$(CONFIG_USB_WHCI_HCD)+= whci/ obj-$(CONFIG_PCI) += pci-quirks.o +obj-$(CONFIG_USB_MAX3421_HCD) += max3421.o + obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)+= ehci-platform.o diff --git a/drivers/usb/host/max3421.c b/drivers/usb/host/max3421.c new file mode 100644 index 000..46e2b10 --- /dev/null +++ b/drivers/usb/host/max3421.c @@ -0,0 +1,1990 @@ +/* + * MAX3421 Host Controller driver for USB. + * + * Maintainer: David Mosberger-Tang + * + * (C) Copyright 2014 David Mosberger-Tang + * + * MAX3421 is a chip implementing a USB 2.0 Full-/Low-Speed host + * controller on a SPI bus. + * + * Based on: + * o MAX3421E datasheet + * http://datasheets.maximintegrated.com/en/ds/MAX3421E.pdf + * o MAX3421E Programming Guide + * http://www.hdl.co.jp/ftpdata/utl-001/AN3785.pdf + * o gadget/dummy_hcd.c + * For USB HCD implementation. + * o Arduino MAX3421 driver + * https://github.com/felis/USB_Host_Shield_2.0/blob/master/Usb.cpp + * + * This file is licenced under the GPL. + * + * Important note on worst-case (full-speed) packet size constraints + * (See USB 2.0 Section 5.6.3 and following): + * + * - control:64 bytes + * - isochronous: 1023 bytes + * - interrupt: 64 bytes + * - bulk: 64 bytes + * + * Since the MAX3421 FIFO size is 64 bytes, we do not have to work about + * multi-FIFO writes/reads for a single USB packet *except* for isochronous + * transfers. We don't support isochronous transfers at this time, so we + * just assume that a USB packet always fits into a single FIFO buffer. + * + * NOTE: The June 2006 version of "MAX3421E Programming Guide" + * (AN3785) has conflicting info for the RCVDAVIRQ bit: + * + * The description of RCVDAVIRQ says "The CPU *must* clear + * this IRQ bit (by writing a 1 to it) before reading the + * RCVFIFO data. + * + * However, the earlier section on "Programming BULK-IN + * Transfers" says * that: + * + * After the CPU retrieves the data, it clears the + * RCVDAVIRQ bit. + * + * The December 2006 version has been corrected and it consistently + * states the second behavior is the correct one. + * + * Synchronous SPI transactions sleep so we can't perform any such + * transactions while holding a spin-lock (and/or while interrupts are + * masked). To achieve this, all SPI transactions are issued from a + * single thread (max3421_spi_thread). + */ + +#define TRACE 0 + +#include +#include +#include +#include + +#define DRIVER_DESC"MAX3421 USB Host-Controller Driver" +#define DRIVER_VERSION "0.4" + +/* 11-bit counter that wraps around (USB 2.0 Section 8.3.3): */ +#define USB_MAX_FRAME_NUMBER 0x7ff +#define USB_MAX_RETRIES3 /* # of retries before error is reported */ + +/* + * Max. # of times we're willing to retransmit a request immediately in + * resposne to a NAK. Afterwards, we fall back on trying once a frame. + */ +#
Re: [PATCH] Add quirk HID_QUIRK_NO_INIT_REPORTS for RNDPLUS touchscreen
On Fri, Mar 21, 2014 at 6:08 PM, Yufeng Shen wrote: > > > On Fri, Mar 21, 2014 at 4:58 PM, Benjamin Tissoires > wrote: >> >> On Fri, Mar 21, 2014 at 3:39 PM, Yufeng Shen wrote: >> > There is timeout error during initialization: >> > kernel: [ 14.167086] hid-multitouch 0003:2512:5003.0001: >> > usb_submit_urb(ctrl) failed: -1 >> > kernel: [ 14.167135] hid-multitouch 0003:2512:5003.0001: timeout >> > initializing reports >> > kernel: [ 14.167407] input: RNDPLUS Co., LTD PULSEIR TSR4601 as >> > /devices/pci:00/:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/input/input14 >> > kernel: [ 14.167975] cpufreq_interactive: monitoring input on RNDPLUS >> > Co., LTD PULSEIR TSR4601 >> > kernel: [ 14.168266] hid-multitouch 0003:2512:5003.0001: >> > input,hiddev0,hidraw1: USB HID v1.10 Mouse [RNDPLUS Co., LTD PULSEIR >> > TSR4601] on usb-:00:1d.0-1.3/input0 >> > >> > Adding quirk HID_QUIRK_NO_INIT_REPORTS can solve the problem. >> >> I already asked you to test if HID_QUIRK_NO_INIT_INPUT_REPORTS was >> working for the same same kind of timeout >> (https://patchwork.kernel.org/patch/3544281/). > > > The reason I didn't test HID_QUIRK_NO_INIT_INPUT_REPORTS was that I am > mainly > working with kernel 3.8/3.10. And HID_QUIRK_NO_INIT_INPUT_REPORTS was not > present You should consider working with an upstream kernel when sending patches. > in the kernel source. Do you have the patch set that I can port to 3.8/3.10 > kernel for testing ? git blames gives 595e9276ce68791317484ec7f0f9f2e0457c3b34, which is Linus' tree since 3.12. Cheers, Benjamin > > >> >> >> So I am asking again: please test HID_QUIRK_NO_INIT_INPUT_REPORTS and >> if it works, use this quirk instead the one in this patch. >> This *really* matters because the quirk HID_QUIRK_NO_INIT_REPORTS does >> not initialize feature reports which contains important information >> regarding hid-multitouch. >> >> Cheers, >> Benjamin >> >> > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: Fix obex in g_nokia.ko causing kernel panic
2014-02-06 20:25 GMT+01:00 Ivaylo Dimitrov :
> From: Felipe Balbi
This patch, which is present in 3.14-rc4 as 30a70b026 ("usb: musb: fix
obex in g_nokia.ko causing kernel panic"), breaks USB gadget support
on my Pandaboard. Bisecting points to this commit, reverting it makes
USB gadget support work again. The problem is that this patch deletes
the call which turns on the PHY.
Config is attached.
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index 2a408cd..8aa59a2 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -659,7 +659,6 @@ static int omap2430_runtime_suspend(struct device *dev)
> OTG_INTERFSEL);
>
> omap2430_low_level_exit(musb);
> - phy_power_off(musb->phy);
> }
>
> return 0;
> @@ -674,7 +673,6 @@ static int omap2430_runtime_resume(struct device *dev)
> omap2430_low_level_init(musb);
> musb_writel(musb->mregs, OTG_INTERFSEL,
> musb->context.otg_interfsel);
> - phy_power_on(musb->phy);
> }
>
> return 0;
panda-usb-config.gz
Description: GNU Zip compressed data
USB3.0 is not getting detected sometimes
Hi, In my linux kernel USB 3.0 pendrive is not getting detected some time.For the same usb port usb2.0 works perfectly. Here is the error message i am getting [ 161.808889] usb 2-1: new SuperSpeed USB device number 4 using xhci_hcd [ 161.87] usb 2-1: New USB device found, idVendor=0951, idProduct=168f [ 161.822288] usb 2-1: New USB device strings: Mfr=4, Product=5, SerialNumber=6 [ 161.822340] usb 2-1: Product: DT Workspace [ 161.822387] usb 2-1: Manufacturer: Kingston [ 161.822436] usb 2-1: SerialNumber: 0018F30C9F55010E0022 [ 161.825196] usb-storage 2-1:1.0: USB Mass Storage device detected [ 161.825493] scsi2 : usb-storage 2-1:1.0 [ 161.827469] find_i2c_adapter_num: i2c adapter i2c-designware-pci-0 not found on system. [ 161.827537] find_i2c_adapter_num: i2c adapter i2c-designware-pci-0 not found on system. [ 161.827596] find_i2c_adapter_num: i2c adapter i2c-designware-pci-5 not found on system. [ 161.827653] find_i2c_adapter_num: i2c adapter i2c-designware-pci-1 not found on system. [ 188.955719] usb 2-1: Disable of device-initiated U1 failed. [ 193.959530] usb 2-1: Disable of device-initiated U2 failed. [ 199.065489] xhci_hcd :00:14.0: Timeout while waiting for Address Device [ 204.271133] xhci_hcd :00:14.0: Timeout while waiting for Address Device [ 204.471822] usb 2-1: device not accepting address 4, error -62 [ 204.626803] usb 2-1: reset SuperSpeed USB device number 4 using xhci_hcd [ 204.638364] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88006dfd4500 [ 204.638401] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88006dfd4540 [ 219.652519] usb 2-1: Disable of device-initiated U1 failed. [ 224.656871] usb 2-1: Disable of device-initiated U2 failed. [ 229.762425] xhci_hcd :00:14.0: Timeout while waiting for Address Device [ 234.967629] xhci_hcd :00:14.0: Timeout while waiting for Address Device [ 235.169041] usb 2-1: device not accepting address 4, error -62 [ 235.323588] usb 2-1: reset SuperSpeed USB device number 4 using xhci_hcd [ 235.335404] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88006dfd4500 [ 235.335441] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88006dfd4540 [ 256.353129] usb 2-1: Disable of device-initiated U1 failed. [ 261.357636] usb 2-1: Disable of device-initiated U2 failed. [ 266.463482] xhci_hcd :00:14.0: Timeout while waiting for Address Device Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: host: Add MAX3421E HCD support.
Felipe, Thanks for your feedback, I'll take that into consideration. On Fri, Mar 21, 2014 at 9:44 PM, Felipe Balbi wrote: >> + max3421_hcd->spi_thread = kthread_run(max3421_spi_thread, hcd, >> + "max3421_spi_thread"); > > why do you need this kthread ? For IRQ handling ? use threaded IRQs > instead. Is there a clean way to wakeup a threaded IRQ handler without an interrupt? Unless I'm missing something, there is not. I started out with a threaded handler in fact, but there are other reasons (e.g., URB enqueue) which need to wake up the thread. --david -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: host: Add HCD for MAX3421E chip. (rev2)
This revision incorporates virtually all of Felipe's feedback. David Mosberger (1): usb: host: Add HCD for MAX3421E chip. drivers/usb/Makefile |1 + drivers/usb/host/Kconfig | 11 + drivers/usb/host/Makefile |1 + drivers/usb/host/max3421-hcd.c | 1857 4 files changed, 1870 insertions(+) create mode 100644 drivers/usb/host/max3421-hcd.c -- 1.7.9.5 >From b567d881406007457ab30c310a705e66a87c9967 Mon Sep 17 00:00:00 2001 From: David Mosberger Date: Fri, 21 Mar 2014 22:39:15 -0600 Subject: [PATCH] usb: host: Add HCD for MAX3421E chip. Signed-off-by: David Mosberger --- drivers/usb/Makefile |1 + drivers/usb/host/Kconfig | 11 + drivers/usb/host/Makefile |1 + drivers/usb/host/max3421-hcd.c | 1857 4 files changed, 1870 insertions(+) create mode 100644 drivers/usb/host/max3421-hcd.c diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index 1ae2bf3..9bb6721 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -28,6 +28,7 @@ obj-$(CONFIG_USB_IMX21_HCD) += host/ obj-$(CONFIG_USB_FSL_MPH_DR_OF)+= host/ obj-$(CONFIG_USB_FUSBH200_HCD) += host/ obj-$(CONFIG_USB_FOTG210_HCD) += host/ +obj-$(CONFIG_USB_MAX3421_HCD) += host/ obj-$(CONFIG_USB_C67X00_HCD) += c67x00/ diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 3d9e540..e9cd7d8 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -343,6 +343,17 @@ config USB_FOTG210_HCD To compile this driver as a module, choose M here: the module will be called fotg210-hcd. +config USB_MAX3421_HCD + tristate "MAX3421 HCD (USB-over-SPI) support" + depends on USB + ---help--- + The Maxim MAX3421E chip supports standard USB 2.0-compliant + full-speed devices either in host or peripheral mode. This + driver supports the host-mode of the MAX3421E only. + + To compile this driver as a module, choose M here: the module will + be called max3421-hcd. + config USB_OHCI_HCD tristate "OHCI HCD (USB 1.1) support" select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index 7530468..ea2bec5 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -70,3 +70,4 @@ obj-$(CONFIG_USB_HCD_BCMA)+= bcma-hcd.o obj-$(CONFIG_USB_HCD_SSB) += ssb-hcd.o obj-$(CONFIG_USB_FUSBH200_HCD) += fusbh200-hcd.o obj-$(CONFIG_USB_FOTG210_HCD) += fotg210-hcd.o +obj-$(CONFIG_USB_MAX3421_HCD) += max3421-hcd.o diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c new file mode 100644 index 000..d63a042 --- /dev/null +++ b/drivers/usb/host/max3421-hcd.c @@ -0,0 +1,1857 @@ +/* + * MAX3421 Host Controller driver for USB. + * + * Author: David Mosberger-Tang + * + * (C) Copyright 2014 David Mosberger-Tang + * + * MAX3421 is a chip implementing a USB 2.0 Full-/Low-Speed host + * controller on a SPI bus. + * + * Based on: + * o MAX3421E datasheet + * http://datasheets.maximintegrated.com/en/ds/MAX3421E.pdf + * o MAX3421E Programming Guide + * http://www.hdl.co.jp/ftpdata/utl-001/AN3785.pdf + * o gadget/dummy_hcd.c + * For USB HCD implementation. + * o Arduino MAX3421 driver + * https://github.com/felis/USB_Host_Shield_2.0/blob/master/Usb.cpp + * + * This file is licenced under the GPL v2. + * + * Important note on worst-case (full-speed) packet size constraints + * (See USB 2.0 Section 5.6.3 and following): + * + * - control:64 bytes + * - isochronous: 1023 bytes + * - interrupt: 64 bytes + * - bulk: 64 bytes + * + * Since the MAX3421 FIFO size is 64 bytes, we do not have to work about + * multi-FIFO writes/reads for a single USB packet *except* for isochronous + * transfers. We don't support isochronous transfers at this time, so we + * just assume that a USB packet always fits into a single FIFO buffer. + * + * NOTE: The June 2006 version of "MAX3421E Programming Guide" + * (AN3785) has conflicting info for the RCVDAVIRQ bit: + * + * The description of RCVDAVIRQ says "The CPU *must* clear + * this IRQ bit (by writing a 1 to it) before reading the + * RCVFIFO data. + * + * However, the earlier section on "Programming BULK-IN + * Transfers" says * that: + * + * After the CPU retrieves the data, it clears the + * RCVDAVIRQ bit. + * + * The December 2006 version has been corrected and it consistently + * states the second behavior is the correct one. + * + * Synchronous SPI transactions sleep so we can't perform any such + * transactions while holding a spin-lock (and/or while interrupts are + * masked). To achieve this, all SPI transactions are issued from a + * single thread (max3421_spi_thread). + */ + +#include +#include +#include +#include + +#define DRIVER
