Re: [PATCH v3 05/13] usb: chipidea: udc: driver update for OTG HNP.
On Wed, Mar 12, 2014 at 04:21:28PM +0800, Peter Chen wrote:
> On Wed, Mar 12, 2014 at 03:12:48PM +0800, Li Jun wrote:
> > On Wed, Mar 12, 2014 at 03:01:15PM +0800, Peter Chen wrote:
> > > On Thu, Feb 27, 2014 at 07:38:23AM +0800, Li Jun wrote:
> > > > Add b_hnp_enable request handling and enable gadget->is_otg
> > > >
> > > > Signed-off-by: Li Jun
> > > > ---
> > > > drivers/usb/chipidea/udc.c | 11 ++-
> > > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > > > index fe30dcc..602bbf3 100644
> > > > --- a/drivers/usb/chipidea/udc.c
> > > > +++ b/drivers/usb/chipidea/udc.c
> > > > @@ -20,6 +20,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > #include
> > > >
> > > > #include "ci.h"
> > > > @@ -1098,6 +1099,14 @@ __acquires(ci->lock)
> > > > default:
> > > > break;
> > > > }
> > > > + break;
> > >
> > > This break is needed?
> > >
> >
> > Yes, needed.
>
> Why, the case USB_DEVICE_TEST_MODE should alway break, isn't it?
>
yes, I don't think the case USB_DEVICE_TEST_MODE should always fall through to
enable HNP here.
> >
> > > > + case USB_DEVICE_B_HNP_ENABLE:
> > > > + if (gadget_is_otg(&ci->gadget))
> > > > {
> > > > + ci->gadget.b_hnp_enable
> > > > = 1;
> > > > + err =
> > > > isr_setup_status_phase(
> > > > + ci);
> > > > + }
> > > > + break;
> > > > default:
> > > > goto delegate;
> > > > }
> > > > @@ -1765,7 +1774,7 @@ static int udc_start(struct ci_hdrc *ci)
> > > > ci->gadget.ops = &usb_gadget_ops;
> > > > ci->gadget.speed= USB_SPEED_UNKNOWN;
> > > > ci->gadget.max_speed= USB_SPEED_HIGH;
> > > > - ci->gadget.is_otg = 0;
> > > > + ci->gadget.is_otg = ci->is_otg ? 1 : 0;
> > > > ci->gadget.name = ci->platdata->name;
> > > >
> > > > INIT_LIST_HEAD(&ci->gadget.ep_list);
> > > > --
> > > > 1.7.9.5
> > > >
> > > >
> > >
> > > --
> > >
> > > Best Regards,
> > > Peter Chen
> > >
> >
>
> --
>
> Best Regards,
> Peter Chen
>
--
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 net-next v3 1/2] r8152:addRTL8152_EARLY_AGG_TIMEOUT_SUPER
From: Francois Romieu [mailto:rom...@fr.zoreil.com] > Sent: Saturday, March 15, 2014 7:43 AM [...] > > Besides, I don't wish to modify the setting by ethtool when re-loading > > the driver or rebooting every time. > > Why ? > > The recipe is different but there isn't much setup difference > between a module param and an ethtool command that is run through udev. > The latter is more versatile though. Thanks for your suggestion. I think I have to understand how to use them first. Best Regards, Hayes -- 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 net-next v3 1/2]r8152:addRTL8152_EARLY_AGG_TIMEOUT_SUPER
From: David Miller [mailto:da...@davemloft.net] > Sent: Saturday, March 15, 2014 2:43 AM [...] > > Besides, I don't wish to modify the setting by ethtool when re-loading > > the driver or rebooting every time. > > You have code to reset the driver, you can do it when the user asks > for the setting to be changed via ethtool. I do not see this as > a problem. > > The ethtool change can occur while the driver is already up, you'll > just need to reset the chip and make the new configuration, this is > not a problem. Thanks for your answer. I would study how to set it by ethtool. Best Regards, Hayes -- 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] hid: fix bug destroying hidraw device files after parent
Hi Jiri, On 02/26/2014 07:02 PM, Jiri Kosina wrote: [...] Applied, thanks. I have slightly modified the patch title to make sure that it's obvious that what it fixes is actually a WARN_ON() splat. Thank you. Any chance we can get this to Linus before 3.14 comes out? According to Linus, rc7 may be the last rc. - Fernando -- 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: Panic during booting Octeon-based router
Hi, On Sun, Mar 16, 2014 at 11:53:08AM -0400, Alan Stern wrote: > On Sun, 16 Mar 2014, Sergey Popov wrote: > > Hi. I have tried to update kernel on my Ubiquiti ERLITE-3 from 3.11.1 to > > 3.13.6 and hit that kernel panic(see attachment). It would be glad if > > someone can help me with this. > > > > I attach my kernel config as well. > > > > Apropriate bugreport on - https://bugzilla.kernel.org/show_bug.cgi?id=72121 > > You should report this to the person responsible for the OcteonUSB > driver, Aaro Koskinen (CC'ed). I'm looking into this. As a quick workaround, try switching CONFIG_SLOB -> SLUB. Thanks for the report, A. -- 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 HID problem
On Sun, 16 Mar 2014, Peter Fassberg wrote: > On Sat, 15 Mar 2014, Alan Stern wrote: > > > You may be able to get it to work by doing > > > > echo 0x 0x0002 >/sys/bus/usb/drivers/usbhid/new_id > > As I wroter earlier it did solve the problem. > > However, the Report Descriptors is "unavailable" now. > > lsusb output: > > Report Descriptors: > ** UNAVAILABLE ** The descriptors are unavailable because the usbhid driver is now in charge of the device, so lsusb is not allowed access. > How can I find the Report Descriptors again? Run lsusb before doing the "echo" command. :-) 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: USB HID problem
On Sat, 15 Mar 2014, Alan Stern wrote: You may be able to get it to work by doing echo 0x 0x0002 >/sys/bus/usb/drivers/usbhid/new_id As I wroter earlier it did solve the problem. However, the Report Descriptors is "unavailable" now. lsusb output: Report Descriptors: ** UNAVAILABLE ** How can I find the Report Descriptors again? -- Peter -- 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: [xhci_hcd] reset SuperSpeed, xhci_drop_endpoint called with disabled ep, Error in queuecommand_lck: task blocked
I finally managed to get an usbmon trace. It's available on the kernel bugzilla page. Andreas Reis On 19.02.2014 18:10, Alan Stern wrote:> On Wed, 19 Feb 2014, Andreas Reis wrote: > >> Hi, >> >> this is an updated copy of my report at: >> https://bugzilla.kernel.org/show_bug.cgi?id=70781 >> >> The two dmesg reports can be found there. >> >> Regards, >> Andreas Reis >> >> --- >> >> [xhci_hcd] reset SuperSpeed, xhci_drop_endpoint called with disabled ep, >> Error in queuecommand_lck: task blocked >> >> Corsair Voyager GT 3.0 32GB on an Intel Z87. I'm using it mostly to >> store source code and as ccache directory, ie. lots of small reads & >> writes. That's also when the bug happened so far. >> >> Currently on 3.14-rc3 (self-compiled on Arch), ie. with the other xhci >> revert-fixes already applied. >> >> Happens since 3.14 development started. Can't remember ever having >> anything like it occur on 3.13. >> >> The error always follows the same sequence � with apparently varying >> addresses � though I cannot (or don't know how to) trigger it manually: >> 1. usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd >> 2. xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled >> ep 880428207900 >> 3. usb-storage: Error in queuecommand_lck: us->srb = 8804283d0d80 >> >> Then the task that called the IO hangs, and afterwards the entire >> system, at the latest when I try to shutdown/restart. >> >> It also often happens that if I restart leaving the stick plugged in, it >> either won't show after boot or immediately triggers some other file >> system related bug, as seen in the attachment. >> >> [I've tried ext4, f2fs and btrfs � the first always seems able to >> recover at some point, the second sometimes (at least if one manages to >> avoid any corrupted files henceforth), the third never.] >> >> The first dmesg attachment shows the bug with "module xhci_hcd =p" set. >> The other shows the dmesg after the first restart with the stick plugged >> in after the boot had finished. fsck.f2fs was able to repair the >> partition, and no follow-up bug triggered. > > Can you collect a usbmon trace showing the bug? See > Documentation/usb/usbmon.txt for instructions. > > 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: Panic during booting Octeon-based router
On Sun, 16 Mar 2014, Sergey Popov wrote: > Hi. I have tried to update kernel on my Ubiquiti ERLITE-3 from 3.11.1 to > 3.13.6 and hit that kernel panic(see attachment). It would be glad if > someone can help me with this. > > I attach my kernel config as well. > > Apropriate bugreport on - https://bugzilla.kernel.org/show_bug.cgi?id=72121 You should report this to the person responsible for the OcteonUSB driver, Aaro Koskinen (CC'ed). 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
questions about give back urb in tasklet
hi all: recently we bump to system performance issue when usb irq take quite long. I found below link for discussing how to short http://permalink.gmane.org/gmane.linux.usb.general/89363 I have some questions about this patch. 1. is there patch or kernel config I can use to measure man/avage usb irq time consuming like the above link show 2. I see this patch is roll back in commit "c04ee4b1136e462722567cf6e76bb35a181574a7" and intend to be ready in 3.13-rc1 Is there special reason why we need to roll back? appreciate your help in advance, -- 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
