Re: xhci Portsc register issue
Hi,
> But I'm not sure, since I've never attempted to memory map PCI registers
> from userspace. I was under the impression that you just can't do that.
You can mmap /sys/bus/pci/devices(${device}/resource0. Just hacked up a
tool which dumps the capability registers this way:
http://www.kraxel.org/cgit/usb-tools/tree/usb-print-caps.c
cheers,
Gerd
--
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 00/11] usbnet: usb_control_msg cleanup
From: Ming Lei Date: Thu, 25 Oct 2012 13:46:53 +0800 > This patch set introduces 3 helpers for handling usb read, write > and write_async command, and replaces the low level's implemention > with the generic ones. > > This patchset is a cleanup and about 300 lines code is saved. > > Also, the patchset fixes problem of DMA on buffer embedded inside > one dynamic allocated buffer, and such usages can be found > in cdc-ncm, sierra_net, mcs7830 and asix drivers. All applied, 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] net: usb: Fix memory leak on Tx data path
On Thursday 25 October 2012 21:17:54 Hemant Kumar wrote: > Driver anchors the tx urbs and defers the urb submission if > a transmit request comes when the interface is suspended. > Anchoring urb increments the urb reference count. These > deferred urbs are later accessed by calling usb_get_from_anchor() > for submission during interface resume. usb_get_from_anchor() > unanchors the urb but urb reference count remains same. > This causes the urb reference count to remain non-zero > after usb_free_urb() gets called and urb never gets freed. > Hence call usb_put_urb() after anchoring the urb to properly > balance the reference count for these deferred urbs. Also, > unanchor these deferred urbs during disconnect, to free them > up. Good catch. This needs to go into stable, too. > > Signed-off-by: Hemant Kumar Acked-by: Oliver Neukum 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] net: usb: Fix memory leak on Tx data path
From: Oliver Neukum Date: Fri, 26 Oct 2012 09:39:16 +0200 > On Thursday 25 October 2012 21:17:54 Hemant Kumar wrote: >> Driver anchors the tx urbs and defers the urb submission if >> a transmit request comes when the interface is suspended. >> Anchoring urb increments the urb reference count. These >> deferred urbs are later accessed by calling usb_get_from_anchor() >> for submission during interface resume. usb_get_from_anchor() >> unanchors the urb but urb reference count remains same. >> This causes the urb reference count to remain non-zero >> after usb_free_urb() gets called and urb never gets freed. >> Hence call usb_put_urb() after anchoring the urb to properly >> balance the reference count for these deferred urbs. Also, >> unanchor these deferred urbs during disconnect, to free them >> up. > > Good catch. This needs to go into stable, too. >> >> Signed-off-by: Hemant Kumar > Acked-by: Oliver Neukum Applied and queued up for -stable. -- 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] qmi_wwan/cdc_ether: move Novatel 551 and E362 to qmi_wwan
From: Dan Williams Date: Wed, 24 Oct 2012 17:10:34 -0500 > These devices provide QMI and ethernet functionality via a standard CDC > ethernet descriptor. But when driven by cdc_ether, the QMI > functionality is unavailable because only cdc_ether can claim the USB > interface. Thus blacklist the devices in cdc_ether and add their IDs to > qmi_wwan, which enables both QMI and ethernet simultaneously. > > Signed-off-by: Dan Williams Applied, 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
[PATCH net-next] net: cdc_ncm: error path lock fix
Fixes the sparse warning
drivers/net/usb/cdc_ncm.c:836:9: warning: context imbalance in
'cdc_ncm_txpath_bh' - different lock contexts for basic block
Signed-off-by: Bjørn Mork
---
drivers/net/usb/cdc_ncm.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 682b17a..11370fe 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -842,6 +842,8 @@ static void cdc_ncm_txpath_bh(unsigned long param)
netif_tx_lock_bh(ctx->netdev);
usbnet_start_xmit(NULL, ctx->netdev);
netif_tx_unlock_bh(ctx->netdev);
+ } else {
+ spin_unlock_bh(&ctx->mtx);
}
}
--
1.7.10.4
--
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 net-next] net: sierra: shut up sparse restricted type warnings
Removes the warnings
drivers/net/usb/sierra_net.c:343:45: warning: incorrect type in assignment
(different base types)
drivers/net/usb/sierra_net.c:343:45:expected unsigned short [unsigned]
[short] [usertype]
drivers/net/usb/sierra_net.c:343:45:got restricted __be16 [usertype]
and
drivers/net/usb/sierra_net.c:658:18: warning: cast to restricted __le16
Signed-off-by: Bjørn Mork
---
drivers/net/usb/sierra_net.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c
index c27d277..2c3b82e 100644
--- a/drivers/net/usb/sierra_net.c
+++ b/drivers/net/usb/sierra_net.c
@@ -340,7 +340,7 @@ static void sierra_net_set_ctx_index(struct sierra_net_data
*priv, u8 ctx_ix)
dev_dbg(&(priv->usbnet->udev->dev), "%s %d", __func__, ctx_ix);
priv->tx_hdr_template[0] = 0x3F;
priv->tx_hdr_template[1] = ctx_ix;
- *((u16 *)&priv->tx_hdr_template[2]) =
+ *((__be16 *)&priv->tx_hdr_template[2]) =
cpu_to_be16(SIERRA_NET_HIP_EXT_IP_OUT_ID);
}
@@ -632,7 +632,7 @@ static int sierra_net_change_mtu(struct net_device *net,
int new_mtu)
static int sierra_net_get_fw_attr(struct usbnet *dev, u16 *datap)
{
int result = 0;
- u16 *attrdata;
+ __le16 *attrdata;
attrdata = kmalloc(sizeof(*attrdata), GFP_KERNEL);
if (!attrdata)
--
1.7.10.4
--
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 net-next] net: cdc_ncm: big endian fix
Probably doesn't matter much since the value is used as a boolean anyway, but it removes the sparse warning: drivers/net/usb/cdc_ncm.c:1090:32: warning: incorrect type in assignment (different base types) drivers/net/usb/cdc_ncm.c:1090:32:expected unsigned short [unsigned] [usertype] connected drivers/net/usb/cdc_ncm.c:1090:32:got restricted __le16 [usertype] wValue Signed-off-by: Bjørn Mork --- drivers/net/usb/cdc_ncm.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c index 0ed03b1..682b17a 100644 --- a/drivers/net/usb/cdc_ncm.c +++ b/drivers/net/usb/cdc_ncm.c @@ -1087,7 +1087,7 @@ static void cdc_ncm_status(struct usbnet *dev, struct urb *urb) * USB_CDC_NOTIFY_NETWORK_CONNECTION notification shall be * sent by device after USB_CDC_NOTIFY_SPEED_CHANGE. */ - ctx->connected = event->wValue; + ctx->connected = le16_to_cpu(event->wValue); printk(KERN_INFO KBUILD_MODNAME ": %s: network connection:" " %sconnected\n", -- 1.7.10.4 -- 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 2/2] USB: doc: Binding document for ehci-platform driver
On Thu, Oct 25, 2012 at 10:36:14AM -0400, Alan Stern wrote:
> What happens if the drivers get probed in the wrong order? That is, if
> ehci-platform gets probed before ehci-spear (or whatever)?
The "wrong" driver may get loaded. Right now, you should have them all in
one driver. For instance the crypto node in mpc8315erdb.dts:
| crypto@3 {
| compatible = "fsl,sec3.3", "fsl,sec3.1", "fsl,sec3.0",
|"fsl,sec2.4", "fsl,sec2.2", "fsl,sec2.1",
|"fsl,sec2.0";
…
The higher the version, the more features are available by the hardware.
The driver [0] probes only for "fsl,sec2.0" but it uses
of_device_is_compatible() to check for the other entries. You could also add
all 7 compatible entries to the driver and distinguish them by the driver_data
field. This is an implementation detail.
However, having two drivers, one for "fsl,sec3.3" and one for "fsl,sec2.0",
would "randomly" load one of the two driver depending on link order and so on.
[0] drivers/crypto/talitos.c
>
> Alan Stern
>
Sebastian
--
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 v2 net-next] net: sierra: shut up sparse restricted type warnings
Removes the warnings
drivers/net/usb/sierra_net.c:343:45: warning: incorrect type in assignment
(different base types)
drivers/net/usb/sierra_net.c:343:45:expected unsigned short [unsigned]
[short] [usertype]
drivers/net/usb/sierra_net.c:343:45:got restricted __be16 [usertype]
and
drivers/net/usb/sierra_net.c:658:18: warning: cast to restricted __le16
Signed-off-by: Bjørn Mork
---
v2: rebased on top of the latest fixes which were just applied to net-next
drivers/net/usb/sierra_net.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c
index eb5c7a8..18dd425 100644
--- a/drivers/net/usb/sierra_net.c
+++ b/drivers/net/usb/sierra_net.c
@@ -339,7 +339,7 @@ static void sierra_net_set_ctx_index(struct sierra_net_data
*priv, u8 ctx_ix)
dev_dbg(&(priv->usbnet->udev->dev), "%s %d", __func__, ctx_ix);
priv->tx_hdr_template[0] = 0x3F;
priv->tx_hdr_template[1] = ctx_ix;
- *((u16 *)&priv->tx_hdr_template[2]) =
+ *((__be16 *)&priv->tx_hdr_template[2]) =
cpu_to_be16(SIERRA_NET_HIP_EXT_IP_OUT_ID);
}
@@ -631,7 +631,7 @@ static int sierra_net_change_mtu(struct net_device *net,
int new_mtu)
static int sierra_net_get_fw_attr(struct usbnet *dev, u16 *datap)
{
int result = 0;
- u16 attrdata;
+ __le16 attrdata;
result = usbnet_read_cmd(dev,
/* _u8 vendor specific request */
--
1.7.10.4
--
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: Large files/folders copying ends with I/O error in mass storage
Hi, After applying this patch,we see that vfs_write is taking around 20 seconds.After this,from the bus traces we see that there are 2 consecutive CBW's and the corresponding CSW's are also out of order.How does f_mass_storage.c handle such a situation? On Mon, Oct 22, 2012 at 8:11 PM, Alan Stern wrote: > On Mon, 22 Oct 2012, megha dey wrote: > >> Hi Alan, >> I will update the patch with necessary comments and repush.However,do >> you think this patch may cause some other deleterious effects? > > If I did, I wouldn't have said it was okay. > > 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: [PATCH v3 1/3] usb: dwc3: Add the suspend/resume functionality
Hi, On Fri, Oct 26, 2012 at 10:34:22AM +0530, Vikas Sajjan wrote: > Hi Felipe, > > On 18 October 2012 22:59, Felipe Balbi wrote: > > Hi, > > > > On Thu, Oct 18, 2012 at 12:44:50PM -0400, Alan Stern wrote: > >> On Thu, 18 Oct 2012, Sarah Sharp wrote: > >> > >> > For system suspend while the DW3 hardware is in host mode, doesn't the > >> > USB core prevent drivers from submitting URBs just before the > >> > PCI/platform suspend is called? Alan? > >> > >> Sure it does. > > > > ok great, so my concerns is limited to the gadget side ;-) I still want > > to see both sides tested, though. > > > > (sorry guys, but with DWC3 now passing full USB3 certification, I want > > to be very careful with patches I accept, specially related to PM ;-) > > > > -- > > balbi > > Will test both HOST and GADGET mode as per your suggestion and update you. cool, thanks. Hope we can still make it to v3.8. I guess we have about 2 weeks (maybe 3) to get code to Greg so it soaks in linux-next long enough before the merge window opens. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 1/2] USB: dwc3-exynos: Add support for device tree
Hi,
On Thu, Oct 25, 2012 at 11:37:33AM +0530, Vivek Gautam wrote:
> Hi,
>
> On Tue, Oct 16, 2012 at 3:38 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Tue, Oct 16, 2012 at 03:36:43PM +0530, kishon wrote:
> >> Hi,
> >>
> >> On Tuesday 16 October 2012 03:23 PM, Felipe Balbi wrote:
> >> >On Tue, Oct 16, 2012 at 02:15:56PM +0530, Vivek Gautam wrote:
> >> >>This patch adds support to parse probe data for
> >> >>dwc3-exynos driver using device tree.
> >> >>
> >> >>Signed-off-by: Vivek Gautam
> >> >>---
> >> >> drivers/usb/dwc3/dwc3-exynos.c | 20
> >> >> 1 files changed, 20 insertions(+), 0 deletions(-)
> >> >>
> >> >>diff --git a/drivers/usb/dwc3/dwc3-exynos.c
> >> >>b/drivers/usb/dwc3/dwc3-exynos.c
> >> >>index ca65978..d11ef49 100644
> >> >>--- a/drivers/usb/dwc3/dwc3-exynos.c
> >> >>+++ b/drivers/usb/dwc3/dwc3-exynos.c
> >> >>@@ -21,6 +21,7 @@
> >> >> #include
> >> >> #include
> >> >> #include
> >> >>+#include
> >> >>
> >> >> #include "core.h"
> >> >>
> >> >>@@ -87,6 +88,8 @@ err1:
> >> >>return ret;
> >> >> }
> >> >>
> >> >>+static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
> >> >>+
> >> >> static int __devinit dwc3_exynos_probe(struct platform_device *pdev)
> >> >> {
> >> >>struct dwc3_exynos_data *pdata = pdev->dev.platform_data;
> >> >>@@ -103,6 +106,14 @@ static int __devinit dwc3_exynos_probe(struct
> >> >>platform_device *pdev)
> >> >>goto err0;
> >> >>}
> >> >>
> >> >>+ /*
> >> >>+* Right now device-tree probed devices don't get dma_mask set.
> >> >>+* Since shared usb code relies on it, set it here for now.
> >> >>+* Once we move to full device tree support this will vanish off.
> >> >>+*/
> >> >>+ if (!pdev->dev.dma_mask)
> >> >>+ pdev->dev.dma_mask = &dwc3_exynos_dma_mask;
> >> >
> >> >says who ?
> >> >
> >> >$ git grep -e dma_mask drivers/of/
> >> >drivers/of/platform.c: dev->dev.dma_mask = &dev->archdata.dma_mask;
> >> >drivers/of/platform.c: dev->archdata.dma_mask = 0xUL;
> >> >drivers/of/platform.c: dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> >> >drivers/of/platform.c: dev->dev.coherent_dma_mask = ~0;
> >> >drivers/of/platform.c: dev->dma_mask = ~0;
> >> >
> >> >-ECONFUSED
> >>
> >> dma_mask is set under some ifdef except for "dev->dma_mask = ~0;".
> >> However I agree with you for coherent_dma_mask case.
> >
> > indeed. Should we try to patch that instead ?
> >
> > Rob, should we set dma_mask at the driver or do you have a nicer way to
> > handle it ??
> >
> Can i have suggestions here please ? :)
Benoit, can you answer here since nobody else does ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/1] usb: gadget: Don't attempt to dequeue requests for a disabled USB endpoint on Freescale hardware
Hi, On Thu, Oct 25, 2012 at 02:36:24AM +0200, Laurent Pinchart wrote: > Hi Felipe, > > On Monday 22 October 2012 13:56:01 Felipe Balbi wrote: > > On Mon, Oct 22, 2012 at 12:47:21PM +0200, Laurent Pinchart wrote: > > > On Monday 22 October 2012 03:33:19 Li Yang-R58472 wrote: > > > > On Saturday, October 20, 2012 1:37 AM Felipe Balbi wrote: > > > > > On Fri, Oct 19, 2012 at 06:19:26PM +0100, Simon Haggett wrote: > > > > > > Some gadget drivers may attempt to dequeue requests for an endpoint > > > > > > that has already been disabled. For example, in the UVC gadget > > > > > > driver, uvc_function_set_alt() will call usb_ep_disable() when alt > > > > > > setting 0 is selected. When the userspace application subsequently > > > > > > issues the VIDIOC_STREAMOFF ioctl, uvc_video_enable() invokes > > > > > > usb_ep_dequeue() to ensure that all requests have been cancelled. > > > > > > > > > > bug is on uvc gadget, then. Laurent ? > > > > > > We've discussed this topic a couple of months before. I believe that's not > > > a bug. > > > > > > http://68.183.106.108/lists/linux-usb/msg68869.html > > > > fair enough :-) > > > > That's a different case, however. At the link above we're discussing > > dequeueing a request which is already being dequeued. $SUBJECT is trying > > to fix dequeueing of a request for an endpoint which isn't even enabled. > > You've got a point there :-) That's a different case indeed, I'm open to (at > least evaluating) a fix in the UVC gadget driver if you think that's better. I _do_ think that's better. If the endpoint isn't even enabled, why are you trying to dequeue a request ? :-) cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH] hid: put the case in the right switch statement
Adding Jiri to the recipient list of the patch, otherwise, the thread may fall in the depth of his mailbox :) Cheers, Benjamin On Thu, Oct 25, 2012 at 7:08 PM, Benjamin Tissoires wrote: > Hi Alan, > > Yes, I saw that too. > > Acked-by: Benjamin Tissoires > > On Thu, Oct 25, 2012 at 4:35 PM, Alan Cox wrote: >> From: Alan Cox >> >> Signed-off-by: Alan Cox >> --- >> >> drivers/hid/hid-multitouch.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c >> index 3eb02b9..c97011c 100644 >> --- a/drivers/hid/hid-multitouch.c >> +++ b/drivers/hid/hid-multitouch.c >> @@ -421,11 +421,11 @@ static int mt_input_mapping(struct hid_device *hdev, >> struct hid_input *hi, >> * contact max are global to the report */ >> td->last_field_index = field->index; >> return -1; >> - } >> case HID_DG_TOUCH: >> /* Legacy devices use TIPSWITCH and not TOUCH. >> * Let's just ignore this field. */ >> return -1; >> + } >> /* let hid-input decide for the others */ >> return 0; >> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-input" 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: [PATCH] hid: put the case in the right switch statement
On Fri, 26 Oct 2012, Benjamin Tissoires wrote: > Adding Jiri to the recipient list of the patch, otherwise, the thread > may fall in the depth of his mailbox :) > > Cheers, > Benjamin > > On Thu, Oct 25, 2012 at 7:08 PM, Benjamin Tissoires > wrote: > > Hi Alan, > > > > Yes, I saw that too. > > > > Acked-by: Benjamin Tissoires > > > > On Thu, Oct 25, 2012 at 4:35 PM, Alan Cox wrote: > >> From: Alan Cox > >> > >> Signed-off-by: Alan Cox > >> --- > >> > >> drivers/hid/hid-multitouch.c |2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c > >> index 3eb02b9..c97011c 100644 > >> --- a/drivers/hid/hid-multitouch.c > >> +++ b/drivers/hid/hid-multitouch.c > >> @@ -421,11 +421,11 @@ static int mt_input_mapping(struct hid_device *hdev, > >> struct hid_input *hi, > >> * contact max are global to the report */ > >> td->last_field_index = field->index; > >> return -1; > >> - } > >> case HID_DG_TOUCH: > >> /* Legacy devices use TIPSWITCH and not TOUCH. > >> * Let's just ignore this field. */ > >> return -1; > >> + } > >> /* let hid-input decide for the others */ > >> return 0; > >> > >> Good catch, thanks. Applying. Alan, please don't forget to CC proper maintainers on such patches. Patches tend to often get lost when sent only to mailinglists unfortunately. Thanks, -- Jiri Kosina SUSE Labs -- 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: problem with Roseweil eusb3 enclosure
Sarah Sharp wrote: > On Thu, Oct 25, 2012 at 06:06:53PM -0400, cov...@ccs.covici.com wrote: > > Sarah Sharp wrote: > > > On Thu, Oct 25, 2012 at 12:53:52PM -0400, cov...@ccs.covici.com wrote: > > > > Sarah Sharp wrote: > > > > > On Wed, Oct 24, 2012 at 12:52:18PM -0400, cov...@ccs.covici.com wrote: > > > > How do I get those kernels? Can you give me the address and whatever > > > > else I need to get those? > > > > > > You can follow the directions here: > > > > > > http://kernelnewbies.org/KernelBuild > > > > > > Use the "Downloading the latest -rc tree" section and the "Duplicating > > > your current config" section. > > > > Linus has several git trees -- I have cloned linux-gpio -- is that the > > correct one, or should I use a different one? > > No, not that one. The one listed in the latest -rc section: > > git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Well, with that kernel, it didn't repeat the messages indefinitely, so I could save them and I also have the messages from the log when I unplugged the enclosure and replugged. Here is the output: usb 4-2: Device not responding to set address. usb 4-2: Device not responding to set address. usb 4-2: device not accepting address 6, error -71 hub 4-0:1.0: unable to enumerate USB device on port 2 and when I unplugged and plugged back in I got: Oct 26 05:54:34 ccs kernel: usb 4-2: device not accepting address 68, error -62 Oct 26 05:54:34 ccs kernel: xhci_hcd :04:00.0: Error while assigning device slot ID Oct 26 05:54:34 ccs kernel: hub 4-0:1.0: couldn't allocate port 2 usb_device Oct 26 05:54:34 ccs kernel: xhci_hcd :04:00.0: Bad Slot ID 1 Oct 26 05:54:34 ccs kernel: xhci_hcd :04:00.0: Could not allocate xHCI USB device data structures Oct 26 05:54:34 ccs kernel: hub 4-0:1.0: couldn't allocate port 2 usb_device But if I don't boot with the enclosure plugged in, when the system comes up I can plug in and get a drive. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com -- 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 1/2] USB: dwc3-exynos: Add support for device tree
Hi Felipe,
On 10/26/2012 10:13 AM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Oct 25, 2012 at 11:37:33AM +0530, Vivek Gautam wrote:
>> Hi,
>>
>> On Tue, Oct 16, 2012 at 3:38 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Tue, Oct 16, 2012 at 03:36:43PM +0530, kishon wrote:
Hi,
On Tuesday 16 October 2012 03:23 PM, Felipe Balbi wrote:
> On Tue, Oct 16, 2012 at 02:15:56PM +0530, Vivek Gautam wrote:
>> This patch adds support to parse probe data for
>> dwc3-exynos driver using device tree.
>>
>> Signed-off-by: Vivek Gautam
>> ---
>> drivers/usb/dwc3/dwc3-exynos.c | 20
>> 1 files changed, 20 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-exynos.c
>> b/drivers/usb/dwc3/dwc3-exynos.c
>> index ca65978..d11ef49 100644
>> --- a/drivers/usb/dwc3/dwc3-exynos.c
>> +++ b/drivers/usb/dwc3/dwc3-exynos.c
>> @@ -21,6 +21,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "core.h"
>>
>> @@ -87,6 +88,8 @@ err1:
>>return ret;
>> }
>>
>> +static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
>> +
>> static int __devinit dwc3_exynos_probe(struct platform_device *pdev)
>> {
>>struct dwc3_exynos_data *pdata = pdev->dev.platform_data;
>> @@ -103,6 +106,14 @@ static int __devinit dwc3_exynos_probe(struct
>> platform_device *pdev)
>>goto err0;
>>}
>>
>> + /*
>> +* Right now device-tree probed devices don't get dma_mask set.
>> +* Since shared usb code relies on it, set it here for now.
>> +* Once we move to full device tree support this will vanish off.
>> +*/
>> + if (!pdev->dev.dma_mask)
>> + pdev->dev.dma_mask = &dwc3_exynos_dma_mask;
>
> says who ?
>
> $ git grep -e dma_mask drivers/of/
> drivers/of/platform.c: dev->dev.dma_mask = &dev->archdata.dma_mask;
> drivers/of/platform.c: dev->archdata.dma_mask = 0xUL;
> drivers/of/platform.c: dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> drivers/of/platform.c: dev->dev.coherent_dma_mask = ~0;
> drivers/of/platform.c: dev->dma_mask = ~0;
>
> -ECONFUSED
dma_mask is set under some ifdef except for "dev->dma_mask = ~0;".
However I agree with you for coherent_dma_mask case.
>>>
>>> indeed. Should we try to patch that instead ?
>>>
>>> Rob, should we set dma_mask at the driver or do you have a nicer way to
>>> handle it ??
>>>
>> Can i have suggestions here please ? :)
>
> Benoit, can you answer here since nobody else does ?
Well, I wish I could, but honestly I don't have a clue :-(
Benoit
--
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: usb-wwan: fix multiple memory leaks in error paths
Hello Johan Hovold,
The patch b8f0e82044c9: "USB: usb-wwan: fix multiple memory leaks in
error paths" from Oct 25, 2012, leads to the following warning:
drivers/usb/serial/usb_wwan.c:505 usb_wwan_port_probe()
error: port->bulk_out_endpointAddress is never equal to -1
(wrong type 0 - 255).
drivers/usb/serial/usb_wwan.c
504 for (i = 0; i < N_OUT_URB; i++) {
505 if (port->bulk_out_endpointAddress == -1)
Never true.
506 continue;
507
regards,
dan carpenter
--
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 1/2] USB: dwc3-exynos: Add support for device tree
On Fri, Oct 26, 2012 at 01:44:38PM +0200, Benoit Cousson wrote:
> Hi Felipe,
>
> On 10/26/2012 10:13 AM, Felipe Balbi wrote:
> > Hi,
> >
> > On Thu, Oct 25, 2012 at 11:37:33AM +0530, Vivek Gautam wrote:
> >> Hi,
> >>
> >> On Tue, Oct 16, 2012 at 3:38 PM, Felipe Balbi wrote:
> >>> Hi,
> >>>
> >>> On Tue, Oct 16, 2012 at 03:36:43PM +0530, kishon wrote:
> Hi,
>
> On Tuesday 16 October 2012 03:23 PM, Felipe Balbi wrote:
> > On Tue, Oct 16, 2012 at 02:15:56PM +0530, Vivek Gautam wrote:
> >> This patch adds support to parse probe data for
> >> dwc3-exynos driver using device tree.
> >>
> >> Signed-off-by: Vivek Gautam
> >> ---
> >> drivers/usb/dwc3/dwc3-exynos.c | 20
> >> 1 files changed, 20 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/usb/dwc3/dwc3-exynos.c
> >> b/drivers/usb/dwc3/dwc3-exynos.c
> >> index ca65978..d11ef49 100644
> >> --- a/drivers/usb/dwc3/dwc3-exynos.c
> >> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> >> @@ -21,6 +21,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> #include "core.h"
> >>
> >> @@ -87,6 +88,8 @@ err1:
> >>return ret;
> >> }
> >>
> >> +static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
> >> +
> >> static int __devinit dwc3_exynos_probe(struct platform_device *pdev)
> >> {
> >>struct dwc3_exynos_data *pdata = pdev->dev.platform_data;
> >> @@ -103,6 +106,14 @@ static int __devinit dwc3_exynos_probe(struct
> >> platform_device *pdev)
> >>goto err0;
> >>}
> >>
> >> + /*
> >> +* Right now device-tree probed devices don't get dma_mask set.
> >> +* Since shared usb code relies on it, set it here for now.
> >> +* Once we move to full device tree support this will vanish off.
> >> +*/
> >> + if (!pdev->dev.dma_mask)
> >> + pdev->dev.dma_mask = &dwc3_exynos_dma_mask;
> >
> > says who ?
> >
> > $ git grep -e dma_mask drivers/of/
> > drivers/of/platform.c: dev->dev.dma_mask = &dev->archdata.dma_mask;
> > drivers/of/platform.c: dev->archdata.dma_mask = 0xUL;
> > drivers/of/platform.c: dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> > drivers/of/platform.c: dev->dev.coherent_dma_mask = ~0;
> > drivers/of/platform.c: dev->dma_mask = ~0;
> >
> > -ECONFUSED
>
> dma_mask is set under some ifdef except for "dev->dma_mask = ~0;".
> However I agree with you for coherent_dma_mask case.
> >>>
> >>> indeed. Should we try to patch that instead ?
> >>>
> >>> Rob, should we set dma_mask at the driver or do you have a nicer way to
> >>> handle it ??
> >>>
> >> Can i have suggestions here please ? :)
> >
> > Benoit, can you answer here since nobody else does ?
>
> Well, I wish I could, but honestly I don't have a clue :-(
fair enough, then we will go with Vivek's approach, I'll wait until next
friday before looking into these patches again though.
--
balbi
signature.asc
Description: Digital signature
Re: (BUG) qmi-wwan bug
On 10/26/2012 02:16 AM, Bjørn Mork wrote: "Shawn J. Goff" writes: After the failure happens, I can see from USB traces (and this is with an external USB sniffer) ARP requests going out and nothing coming in - so it seems like it's not a case of dropping URBs. Does the modem respond to other packets than ARP? It is a point to point link, and the ethernet header is just a dummy anyway, so you can turn off ARP on the interface and test. Here is a ping just after failure, then after disabling ARP, then some dhcp discovers (ping + tcpdump + usbmon): # ping 4.2.2.4 PING 4.2.2.4 (4.2.2.4): 56 data bytes 00:44:56.237688 ARP, Request who-has 21.44.110.21 tell 21.44.110.22, length 28 c293e560 2696237824 S Bo:1:004:6 -115 42 = c2b4 b64e6f90 08060001 08000604 0001c2b4 b64e6f90 152c6e16 c293e560 2696238062 C Bo:1:004:6 0 42 > 00:44:57.240239 ARP, Request who-has 21.44.110.21 tell 21.44.110.22, length 28 c293e560 2697240365 S Bo:1:004:6 -115 42 = c2b4 b64e6f90 08060001 08000604 0001c2b4 b64e6f90 152c6e16 c293e560 2697240561 C Bo:1:004:6 0 42 > 00:44:58.242664 ARP, Request who-has 21.44.110.21 tell 21.44.110.22, length 28 c293e560 2698242776 S Bo:1:004:6 -115 42 = c2b4 b64e6f90 08060001 08000604 0001c2b4 b64e6f90 152c6e16 c293e560 2698242931 C Bo:1:004:6 0 42 > --- 4.2.2.4 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss # # ip link set dev wwan0 arp off # # ping 4.2.2.4 PING 4.2.2.4 (4.2.2.4): 56 data bytes --- 4.2.2.4 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss # ip route add 4.2.2.4 dev wwan0 # # ping 4.2.2.4 PING 4.2.2.4 (4.2.2.4): 56 data bytes 00:45:23.338147 IP 21.44.110.22 > 4.2.2.4: ICMP echo request, id 53768, seq 0, length 64 c293e560 2723338296 S Bo:1:004:6 -115 98 = c2b4b64e 6f90c2b4 b64e6f90 08004500 0054 40004001 b161152c 6e160402 c293e560 2723338573 C Bo:1:004:6 0 98 > 00:45:24.341673 IP 21.44.110.22 > 4.2.2.4: ICMP echo request, id 53768, seq 1, length 64 c293e560 2724341810 S Bo:1:004:6 -115 98 = c2b4b64e 6f90c2b4 b64e6f90 08004500 0054 40004001 b161152c 6e160402 c293e560 2724342064 C Bo:1:004:6 0 98 > c293e560 2725342353 S Bo:1:004:6 -115 98 = c2b4b64e 6f90c2b4 b64e6f90 08004500 0054 40004001 b161152c 6e160402 c293e560 2725342625 C Bo:1:004:6 0 98 > 00:45:25.342202 IP 21.44.110.22 > 4.2.2.4: ICMP echo request, id 53768, seq 2, length 64 c293e560 2726342907 S Bo:1:004:6 -115 98 = c2b4b64e 6f90c2b4 b64e6f90 08004500 0054 40004001 b161152c 6e160402 c293e560 2726343058 C Bo:1:004:6 0 98 > 00:45:26.342757 IP 21.44.110.22 > 4.2.2.4: ICMP echo request, id 53768, seq 3, length 64 --- 4.2.2.4 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss # # udhcpc -i wwan0 udhcpc (v1.19.4) started Sending discover... c293e360 2776988614 S Bo:1:004:6 -115 322 = c2b4 b64e6f90 08004500 0134 4011 79ba c293e360 2776988803 C Bo:1:004:6 0 322 > 00:46:16.988471 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c2:b4:b6:4e:6f:90, length 280 Sending discover... c293e360 2779998437 S Bo:1:004:6 -115 322 = c2b4 b64e6f90 08004500 0134 4011 79ba c293e360 2779998561 C Bo:1:004:6 0 322 > 00:46:19.998288 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c2:b4:b6:4e:6f:90, length 280 At the point when things stall out, I don't see anything special happening - there's a large file that is downloading (lots of IN packets) that suddenly stops while the tty port keeps chatting normally. I can also provide a trace from the external sniffer if it's interesting, but here is a usbmon trace of the failure: http://sprunge.us/ORQE . The last incoming message from the wwan endpoint (2:8) is at 183640. I may very well be wrong, but to me this looks like the modem just stops responding for some reason. I have no idea why. That's what I gathered as well; it's perplexing and I'm not really sure where to go from there. -- 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] [trivial] usb: Fix typo in drivers/usb
Correct spelling typo in debug message within drivers/usb.
Signed-off-by: Masanari Iida
---
drivers/usb/gadget/fsl_udc_core.c | 2 +-
drivers/usb/gadget/tcm_usb_gadget.c | 2 +-
drivers/usb/host/Kconfig| 4 ++--
drivers/usb/musb/musb_dsps.c| 2 +-
drivers/usb/renesas_usbhs/fifo.c| 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index 3def828..37a4e01 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -2126,7 +2126,7 @@ static int fsl_proc_read(char *page, char **start, off_t
off, int count,
tmp_reg = fsl_readl(&dr_regs->usbintr);
t = scnprintf(next, size,
- "USB Intrrupt Enable Reg:\n"
+ "USB Interrupt Enable Reg:\n"
"Sleep Enable: %d SOF Received Enable: %d "
"Reset Enable: %d\n"
"System Error Enable: %d "
diff --git a/drivers/usb/gadget/tcm_usb_gadget.c
b/drivers/usb/gadget/tcm_usb_gadget.c
index 5444866..73eac8f 100644
--- a/drivers/usb/gadget/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/tcm_usb_gadget.c
@@ -1387,7 +1387,7 @@ static struct se_node_acl *usbg_alloc_fabric_acl(struct
se_portal_group *se_tpg)
nacl = kzalloc(sizeof(struct usbg_nacl), GFP_KERNEL);
if (!nacl) {
- printk(KERN_ERR "Unable to alocate struct usbg_nacl\n");
+ printk(KERN_ERR "Unable to allocate struct usbg_nacl\n");
return NULL;
}
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 075d2ec..7cac2e8 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -418,7 +418,7 @@ config USB_OHCI_HCD_PLATFORM
default n
---help---
Adds an OHCI host driver for a generic platform device, which
- provieds a memory space and an irq.
+ provides a memory space and an irq.
If unsure, say N.
@@ -428,7 +428,7 @@ config USB_EHCI_HCD_PLATFORM
default n
---help---
Adds an EHCI host driver for a generic platform device, which
- provieds a memory space and an irq.
+ provides a memory space and an irq.
If unsure, say N.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 494772f..59ad13d 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -294,7 +294,7 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
* Also, DRVVBUS pulses for SRP (but not at 5V) ...
*/
if ((usbintr & MUSB_INTR_BABBLE) && is_host_enabled(musb))
- pr_info("CAUTION: musb: Babble Interrupt Occured\n");
+ pr_info("CAUTION: musb: Babble Interrupt Occurred\n");
if (usbintr & ((1 << wrp->drvvbus) << wrp->usb_shift)) {
int drvvbus = dsps_readl(reg_base, wrp->status);
diff --git a/drivers/usb/renesas_usbhs/fifo.c b/drivers/usb/renesas_usbhs/fifo.c
index ecd1730..2a5b78d 100644
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -163,7 +163,7 @@ static int usbhsf_pkt_handler(struct usbhs_pipe *pipe, int
type)
func = pkt->handler->dma_done;
break;
default:
- dev_err(dev, "unknown pkt hander\n");
+ dev_err(dev, "unknown pkt handler\n");
goto __usbhs_pkt_handler_end;
}
--
1.8.0.rc3.16.g8ead1bf
--
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: During xHC Initialization (device is not connected), when HC-RESET is asserted, software is not expecting WRC or PRC bit set
Always use Reply-To-All so that your messages get sent to the mailing
list as well as to me.
Also, please avoid top-posting.
On Fri, 26 Oct 2012, Ankit wrote:
> Hi Alan,
>
> Sorry, earlier code was not proper.
>
> Below is a code (mark as Bold), which we have put in hub_activate(),
Sorry, I can't read this. It is whitespace damaged and in the wrong
format. Please follow the instructions in
Documentation/SubmittingPatches.
Alan Stern
> static void hub_activate(struct usb_hub *hub, enum hub_activation_type type)
> {
>
>
> for (port1 = 1; port1 <= hdev->maxchild; ++port1) {
> struct usb_device *udev = hdev->children[port1-1];
> u16 portstatus, portchange;
>
> portstatus = portchange = 0;
> status = hub_port_status(hub, port1, &portstatus, &portchange);
> if (udev || (portstatus & USB_PORT_STAT_CONNECTION))
> dev_dbg(hub->intfdev,
> "port %d: status %04x change %04x\n",
> port1, portstatus, portchange);
>
> /* After anything other than HUB_RESUME (i.e., initialization
> * or any sort of reset), every port should be disabled.
> * Unconnected ports should likewise be disabled (paranoia),
> * and so should ports for which we have no usb_device.
> */
> if ((portstatus & USB_PORT_STAT_ENABLE) && (
> type != HUB_RESUME ||
> !(portstatus & USB_PORT_STAT_CONNECTION) ||
> !udev ||
> udev->state == USB_STATE_NOTATTACHED)) {
> /*
> * USB3 protocol ports will automatically transition
> * to Enabled state when detect an USB3.0 device attach.
> * Do not disable USB3 protocol ports.
> */
> if (!hub_is_superspeed(hdev)) {
> clear_port_feature(hdev, port1,
>USB_PORT_FEAT_ENABLE);
> portstatus &= ~USB_PORT_STAT_ENABLE;
> } else {
> /* Pretend that power was lost for USB3 devs */
> portstatus &= ~USB_PORT_STAT_ENABLE;
> }
> }
>
> /* Clear status-change flags; we'll debounce later */
> if (portchange & USB_PORT_STAT_C_CONNECTION) {
> need_debounce_delay = true;
> clear_port_feature(hub->hdev, port1,
> USB_PORT_FEAT_C_CONNECTION);
> }
> if (portchange & USB_PORT_STAT_C_ENABLE) {
> need_debounce_delay = true;
> clear_port_feature(hub->hdev, port1,
> USB_PORT_FEAT_C_ENABLE);
> }
> if ((portchange & USB_PORT_STAT_C_BH_RESET) &&
> hub_is_superspeed(hub->hdev)) {
> need_debounce_delay = true;
> clear_port_feature(hub->hdev, port1,
> USB_PORT_FEAT_C_BH_PORT_RESET);
> }
> *if ( (portchange & USB_PORT_STAT_C_RESET)
> && hub_is_superspeed(hub->hdev)) {*
> *need_debounce_delay = true;*
> * clear_port_feature(hub->hdev, port1,*
> * USB_PORT_FEAT_C_RESET);*
> * }*
> *...*
> **
> }
>
> Please, let us know your inputs.
>
> Thanks & Regards,
> Ankit Patel
> Member Of Technical Staff-ASIC
> mob- +91 9099065690
> ankit.a.pa...@sibridgetech.com | www.sibridgetech.com
>
>
>
>
> *An Innovative Solutions Provider*
>
> ASIC | FPGA | Design & Verification IPs | Embedded Solutions
>
>
>
> On Fri, Oct 26, 2012 at 11:03 AM, Ankit wrote:
>
> > Hi Alan,
> >
> > Thanks for your response.
> >
> > We really thankful, if the patch gets submitted.
> >
> > As of now, we have put a condition as below in hub_activate(),
> >
> > for (port1 = 1; port1 <= hdev->maxchild; ++port1) {
> > struct usb_device *udev = hdev->children[port1-1];
> > u16 portstatus, portchange;
> >
> > portstatus = portchange = 0;
> > status = hub_port_status(hub, port1, &portstatus, &portchange);
> >
> > if (portchange & USB_PORT_STAT_C_RESET){
> >dev_dbg(hub_dev, "reset change on port %d\n",i);
> >clear_port_feature(hdev, i, USB_PORT_FEAT_C_RESET);
> > }
> >
> >
> > One more thing, is it the same patch applied to the Compliance
> > Verification and Windows driver as well? If it will, then let us know
> > version number of Compliance Verification and Windows driver.
> >
> >
> > Regards,
> > Ankit Patel
> > Member Of Technical Staff-ASIC
> > mob- +91 9099065690
> > ankit.a.pa...@sibridgetech.com | www.sibridgetech.com
> >
> >
> >
> >
> > *An Innovative Solutions Provider*
> >
> > ASIC | FPGA | Design & Verification IPs | Embedded Solutions
> >
> >
> >
> > On Thu, Oct 25, 2012 at 8:04 PM, Alan Stern
> > wrote:
> >
> >> On Thu, 25 Oct 2012, Ankit wrote:
> >>
> >> > Hi Alan,
> >> >
> >> > Thanks for your response.
> >> >
> >> > Yes, there is a handling of PRC bit in xhci-hub.c
> >> >
> >> > Our query is, at the time of XHCI initialization (inserting xhci-hcd.ko
> >> and
> >> > no USB device is attached), is there PRC and CSC bits should be set?
> >> >
> >> > Our host controller sets PRC and CSC bits at the time of initialization,
> >> > even though no USB device is attached. At the time of initialization,
> >> > hub_probe() gets called and in-turn it calls hub_activate().
> >> hub_activate()
> >> > clears the CSC bit, but PRC bit does not get cleared (in linux 3.6.1).
> >> > hub_events() has functionality to clear the PRC bit, but initially
> >> there is
> >> > no events from HUB, so hub_events() may not clear the PRC bit. Due to
> >> this
> >>
Re: [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
On Fri, 26 Oct 2012, Sebastian Andrzej Siewior wrote: > On Thu, Oct 25, 2012 at 10:36:14AM -0400, Alan Stern wrote: > > What happens if the drivers get probed in the wrong order? That is, if > > ehci-platform gets probed before ehci-spear (or whatever)? > > The "wrong" driver may get loaded. That's my point. That's why ehci-platform.c should not claim to match all devices listing "usb-ehci" in their compatible property. 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: Large files/folders copying ends with I/O error in mass storage
Please don't top-post. On Fri, 26 Oct 2012, megha dey wrote: > Hi, > After applying this patch,we see that vfs_write is taking around 20 > seconds.After this,from the bus traces we see that there are 2 > consecutive CBW's and the corresponding CSW's are also out of > order.How does f_mass_storage.c handle such a situation? Can you be more specific? Exactly what patch did you apply? And can you provide either a debugging log or a usbmon trace showing the packets that are out of order? 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: [PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
Hi Kishon & Benoit, On 09/24/2012 12:06 PM, Rabin Vincent wrote: > 2012/9/24 ABRAHAM, KISHON VIJAY : >> On Sat, Sep 22, 2012 at 3:03 AM, Rabin Vincent wrote: >>> USB doesn't work on pandaboard on linux-next, and bisection shows this >>> patch. Unfortunately, I can't provide a dmesg log because USB is the >>> only way I currently have to get one out(!), but presumably it's because >>> this omap-usb2 device is never registered? Looks like this breaks >>> non-dt USB on pandaboard; is that intended? >> >> Yes. omap-usb2 is *only* dt supported (New drivers shouldn't have the >> old non-dt support). > > Well, USB used to work fine on Pandaboard without DT before the > introduction of "omap-usb2", so one would expected it to continue > working (until the board file is completely removed). > > Anyway, I've moved to DT now. > >> Some patches are queued only for 3.7. >> >> In case you want to use MUSB please use these patches on linux-next.. >> [PATCH v2] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp >> [PATCH] ARM: OMAP2+: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs >> entries (from Benoit) >> [PATCH 0/2] ARM: dts: Add subnode for ocp2scp (patch series) >> [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB (patch series) > > I got these by merging in Benoit's for_3.7/dts_part2 on top of > next-20120921. Thanks. > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > I still can't get musb to work on 3.7-rc2. Apparently it is still missing the patches from Benoit's for_3.7/dts_part2. Maybe I just need to wait for it to be merged? Till then, where can I get a tree where musb works on Panda? Benoit, FYI, I get merge conflicts when merging 3.7-rc2 on top of Linus's kernel HEAD. Am I missing something? regards, -roger -- 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: Problem with OHCI on OMAP4430
On Fri, 26 Oct 2012, Mohan V wrote:
> >> When the USB bus is in suspend, a device connected to OHCI port does
> >> not get detected, whereas the device connected to EHCI port is getting
> >> detected.
> >
> > Can you provide a dmesg log showing the OHCI problem with
> > CONFIG_USB_DEBUG enabled?
> >
> Please find the attached log (ohci-detect.log), where the device is
> disconnected from the
> OHCI port and then does not get detected when connected again.
> We are using android 3.0 kernel.
I'm not going to be able to help very much with an Android kernel.
Does the same problem occur with a vanilla non-Android 3.6 kernel? If
it doesn't, that indicates the problem was caused by some
Android-specific changes.
Are you referring to this part of the log?
> Device not getting detected when
> connected---
>
> / # [ 135.621002] usbhs_wakeup: Enabling clocks
> [ 135.625762] usbhs_runtime_resume:++
> [ 135.630371] usbhs_runtime_resume:--
> [ 135.638183] USB IO PAD Wakeup event triggered##
> [ 135.644958] usbhs_runtime_suspend:++
> [ 135.649749] usbhs_runtime_suspend:-
It appears that ohci_irq() didn't run. Did
ohci_finish_controller_resume() get called?
My guess is your usbhs_runtime_resume() routine has a bug. Maybe the
usbhs_runtime_suspend() routine does too.
> We sometime see the crash in "ohci_hub_status_data" function. So, when
> we add the
> below check at the entry of the function, there is no crash. Please
> find attached crash log.
> (ohci-crash.log)
I don't understand the crash log. What is the cause of the crash? Is
there some error involving spin_lock_irqrestore() in
ohci_hub_status_data()
> if (!HC_IS_RUNNING(hcd->state)) {
> return 0;
> }
>
> But the device does not get detected subsequently with this change. There is
> a similar check in ehci-hub.c.
No, there isn't. Not since the 3.1 kernel. In any case, ehci-hcd is
different from ohci-hcd; you shouldn't expect their hub_status_data
routines to be the same.
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: [PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
Hi Roger, On 10/26/2012 05:16 PM, Roger Quadros wrote: > Hi Kishon & Benoit, > > On 09/24/2012 12:06 PM, Rabin Vincent wrote: >> 2012/9/24 ABRAHAM, KISHON VIJAY : >>> On Sat, Sep 22, 2012 at 3:03 AM, Rabin Vincent wrote: USB doesn't work on pandaboard on linux-next, and bisection shows this patch. Unfortunately, I can't provide a dmesg log because USB is the only way I currently have to get one out(!), but presumably it's because this omap-usb2 device is never registered? Looks like this breaks non-dt USB on pandaboard; is that intended? >>> >>> Yes. omap-usb2 is *only* dt supported (New drivers shouldn't have the >>> old non-dt support). >> >> Well, USB used to work fine on Pandaboard without DT before the >> introduction of "omap-usb2", so one would expected it to continue >> working (until the board file is completely removed). >> >> Anyway, I've moved to DT now. >> >>> Some patches are queued only for 3.7. >>> >>> In case you want to use MUSB please use these patches on linux-next.. >>> [PATCH v2] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp >>> [PATCH] ARM: OMAP2+: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs >>> entries (from Benoit) >>> [PATCH 0/2] ARM: dts: Add subnode for ocp2scp (patch series) >>> [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB (patch series) >> >> I got these by merging in Benoit's for_3.7/dts_part2 on top of >> next-20120921. Thanks. >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-omap" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > I still can't get musb to work on 3.7-rc2. Apparently it is still > missing the patches from Benoit's for_3.7/dts_part2. > > Maybe I just need to wait for it to be merged? They are now in a for_3.8/dts. Unfortunately, one patch that was adding ctrl_module address in the USB data was rejected and thus I'm not sure it will work without that. I think Tony had an idea to map the ctrl_register to regulator fmwk or something like that. > Till then, where can I get a tree where musb works on Panda? > > Benoit, > > FYI, I get merge conflicts when merging 3.7-rc2 on top of Linus's kernel > HEAD. Am I missing something? Yeah, some more patches were merged outside our tree. I fixed that. Can you try with the updated branch? Regards, Benoit -- 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 isochronous frame lost
On Fri, 26 Oct 2012, Stefan May wrote: > it seems that data are interpreted differently. While the host is > getting tons of -71 errors, data is passed to vmware correctly. That's a strange way of describing it. When the -71 errors occur there _is_ no data -- the device didn't send anything. So it doesn't make sense to say the data gets passed to VMWare correctly. In fact, VMWare is changing the -71 error codes to 0. > I've attached two traces that I ran simultaneously on the host and the > guest. One thing that I noticed is that the same camera is setting > different video standards on both systems. While the host sees a > PAL-standard, the guest interprets it as NTSC. How did you notice this? It doesn't show up in your usbmon traces. > Host > bmVideoStandards 0x6c > PAL - 625/50 > SECAM - 625/50 > PAL - 525/60 > > Guest > bmVideoStandards 0x32 > NTSC - 525/60 > NTSC - 625/50 > PAL - 525/60 Maybe you are using different software or different settings in the host and the guest. > Might this be the reason? This is definitely not the reason for the missing -71 codes. They are stripped out by VMWare. > Can I force the host to use NTSC? I don't know. Whatever technique you employ to tell the guest to use NTSC should also work with the host. 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: [PATCH usb-next 2/3] USB: option: replace vendor probe rule with match flags
On Thursday 25 October 2012 23:42:30 Bjørn Mork wrote: > Oliver Neukum writes: > > > On Thursday 25 October 2012 21:58:37 Bjørn Mork wrote: > >> No need for a vendor specific probe exception just to > >> match on the interface class. > > > > No need for a private macro. It already exists. > > > > /** > > * USB_DEVICE_AND_INTERFACE_INFO - describe a specific usb device with a > > class of usb interfaces > > Yes, but that one will match on SubClass and Protocol too, and I don't > know what values those are supposed to have. The idea was to implement > the same match as before, i.e a wildcard for SubClass and Protocol. If we are really missing a macro, the place for it to go is usb.h, not a private version. 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 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
* Benoit Cousson [121026 08:23]: > Hi Roger, > > On 10/26/2012 05:16 PM, Roger Quadros wrote: > > Hi Kishon & Benoit, > > > > On 09/24/2012 12:06 PM, Rabin Vincent wrote: > >> 2012/9/24 ABRAHAM, KISHON VIJAY : > >>> On Sat, Sep 22, 2012 at 3:03 AM, Rabin Vincent wrote: > USB doesn't work on pandaboard on linux-next, and bisection shows this > patch. Unfortunately, I can't provide a dmesg log because USB is the > only way I currently have to get one out(!), but presumably it's because > this omap-usb2 device is never registered? Looks like this breaks > non-dt USB on pandaboard; is that intended? > >>> > >>> Yes. omap-usb2 is *only* dt supported (New drivers shouldn't have the > >>> old non-dt support). > >> > >> Well, USB used to work fine on Pandaboard without DT before the > >> introduction of "omap-usb2", so one would expected it to continue > >> working (until the board file is completely removed). > >> > >> Anyway, I've moved to DT now. > >> > >>> Some patches are queued only for 3.7. > >>> > >>> In case you want to use MUSB please use these patches on linux-next.. > >>> [PATCH v2] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp > >>> [PATCH] ARM: OMAP2+: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs > >>> entries (from Benoit) > >>> [PATCH 0/2] ARM: dts: Add subnode for ocp2scp (patch series) > >>> [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB (patch series) > >> > >> I got these by merging in Benoit's for_3.7/dts_part2 on top of > >> next-20120921. Thanks. > >> -- > >> To unsubscribe from this list: send the line "unsubscribe linux-omap" in > >> the body of a message to majord...@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >> > > > > I still can't get musb to work on 3.7-rc2. Apparently it is still > > missing the patches from Benoit's for_3.7/dts_part2. > > > > Maybe I just need to wait for it to be merged? > > They are now in a for_3.8/dts. Unfortunately, one patch that was adding > ctrl_module address in the USB data was rejected and thus I'm not sure > it will work without that. > > I think Tony had an idea to map the ctrl_register to regulator fmwk or > something like that. For device tree, we may be eventually able to handle the ctrl_register using pinctrl-single.c and pinconf API. It probably does not make sense to set it up as a regulator as the comparator can trigger errors also for the pinconf related bits at least for MMC PBIAS. > > Till then, where can I get a tree where musb works on Panda? On panda, without using device tree, use v3.7-rc2 + the following patches: ARM: OMAP: ocp2scp: create omap device for ocp2scp ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy drivers: bus: ocp2scp: add pdata support Also you need to enable CONFIG_OMAP_USB2. No idea what all is needed to use MUSB with device tree at this point. Regards, Tony -- 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 isochronous frame lost
I saw different bmVideoStandards with lsusb. It is the only parameter with a different value on both sides. Meanwhile, I found a way to make the camera work. I need to use the load option nodrop=1 in the host, but not in the guest. I have no idea why UVC sees incomplete frames only on host side. It is definitely a firmware problem. Could you imagine what was not respected there, so that almost every packet is dropped? Stefan May Am 26.10.2012 17:38, schrieb Alan Stern: On Fri, 26 Oct 2012, Stefan May wrote: it seems that data are interpreted differently. While the host is getting tons of -71 errors, data is passed to vmware correctly. That's a strange way of describing it. When the -71 errors occur there _is_ no data -- the device didn't send anything. So it doesn't make sense to say the data gets passed to VMWare correctly. In fact, VMWare is changing the -71 error codes to 0. I've attached two traces that I ran simultaneously on the host and the guest. One thing that I noticed is that the same camera is setting different video standards on both systems. While the host sees a PAL-standard, the guest interprets it as NTSC. How did you notice this? It doesn't show up in your usbmon traces. Host bmVideoStandards 0x6c PAL - 625/50 SECAM - 625/50 PAL - 525/60 Guest bmVideoStandards 0x32 NTSC - 525/60 NTSC - 625/50 PAL - 525/60 Maybe you are using different software or different settings in the host and the guest. Might this be the reason? This is definitely not the reason for the missing -71 codes. They are stripped out by VMWare. Can I force the host to use NTSC? I don't know. Whatever technique you employ to tell the guest to use NTSC should also work with the host. 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 -- 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: Unreliable USB3 with NEC uPD720200 and Delock Cardreader
Am 25.10.2012 22:11, schrieb Rafael J. Wysocki: On Thursday, October 25, 2012 07:15:58 PM Ulrich Eckhardt wrote: I have done first a cat to the control file which returns already on: uli:/ # cat /sys/devices/pci\:00/\:00\:04.0/power/control on Writing again on to the file does not change anything. Yes, and this means that runtime PM is disabled on the controller. ASPM remains as a possible culprit, then. Can you please boot with pcie_aspm=off in the kernel command line and see if this makes a difference? It make no difference: ... [0.00] Policy zone: Normal [0.00] Kernel command line: root=/dev/disk/by-id/ata-Corsair_Force_3_SSD_12307960149504CF-part1 resume=/dev/disk/by-id/ata-WDC_WD20EARX-00PASB0_WD-WCAZA778-part2 splash=silent quiet vga=0x31a pcie_aspm=off [0.00] bootsplash: silent mode. [0.00] PCIe ASPM is disabled ... [ 124.949190] sdf: detected capacity change from 2032664576 to 0 [ 132.387722] sd 10:0:0:2: [sdf] 3970048 512-byte logical blocks: (2.03 GB/1.89 GiB) [ 132.31] sd 10:0:0:2: [sdf] No Caching mode page present [ 132.388891] sd 10:0:0:2: [sdf] Assuming drive cache: write through [ 132.390876] sd 10:0:0:2: [sdf] No Caching mode page present [ 132.390885] sd 10:0:0:2: [sdf] Assuming drive cache: write through [ 132.393259] sdf: sdf1 [ 137.286335] sdf: detected capacity change from 2032664576 to 0 [ 144.304194] sd 10:0:0:2: [sdf] 3970048 512-byte logical blocks: (2.03 GB/1.89 GiB) [ 144.305345] sd 10:0:0:2: [sdf] No Caching mode page present [ 144.305356] sd 10:0:0:2: [sdf] Assuming drive cache: write through [ 144.307389] sd 10:0:0:2: [sdf] No Caching mode page present [ 144.307399] sd 10:0:0:2: [sdf] Assuming drive cache: write through [ 144.309682] sdf: sdf1 [ 217.179499] hub 9-0:1.0: cannot reset port 2 (err = -19) [ 217.440798] hub 9-0:1.0: hub_port_status failed (err = -19) [ 217.440865] sd 10:0:0:2: Device offlined - not ready after error recovery [ 217.440873] sd 10:0:0:2: [sdf] Unhandled error code [ 217.440875] sd 10:0:0:2: [sdf] [ 217.440876] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK [ 217.440878] sd 10:0:0:2: [sdf] CDB: [ 217.440879] Read(10): 28 00 00 00 0f 00 00 00 f0 00 [ 217.440884] end_request: I/O error, dev sdf, sector 3840 [ 217.440909] sd 10:0:0:2: rejecting I/O to offline device [ 217.440911] sd 10:0:0:2: killing request [ 217.440945] sd 10:0:0:2: rejecting I/O to offline device [ 217.440958] sd 10:0:0:2: [sdf] killing request [ 217.440968] sd 10:0:0:2: rejecting I/O to offline device [ 217.440977] sd 10:0:0:2: rejecting I/O to offline device [ 217.440979] sd 10:0:0:2: rejecting I/O to offline device [ 217.441003] sd 10:0:0:2: [sdf] Unhandled error code [ 217.441008] sd 10:0:0:2: [sdf] [ 217.441012] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [ 217.441017] sd 10:0:0:2: [sdf] CDB: [ 217.441020] Read(10): 28 00 00 00 0f f0 00 00 10 00 [ 217.441036] end_request: I/O error, dev sdf, sector 4080 [ 217.442200] sd 10:0:0:2: rejecting I/O to offline device [ 217.442252] sd 10:0:0:2: rejecting I/O to offline device -- Ulrich Eckhardt http://www.uli-eckhardt.de Ein Blitzableiter auf dem Kirchturm ist das denkbar stärkste Misstrauensvotum gegen den lieben Gott. (Karl Krauss) -- 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: usb_wwan: fix bulk-urb allocation
Make sure we do not allocate urbs if we do not have a bulk endpoint.
Legacy code used incorrect assumption to test for bulk endpoints.
Reported-by: Dan Carpenter
Cc: stable
Signed-off-by: Johan Hovold
---
Thanks for catching this Dan. The driver has been using the incorrect
assumption that the unsigned endpoint address would be -1 when there's no bulk
endpoint (in fact its zero).
My memory-leak patch included a direct comparison which Dan's compiler caught.
The test in the fix wasn't supposed to have been there as I decided to keep
the original code in my final version, but at least this way we found the bogus
assumption.
So, Greg, this one applies on top of usb-linus and should go in v3.7. The bad
test (in setup_urb) has been there since the first version of the driver, but
note that this patch only applies on top of the port-data fixes in usb-linus
(marked for stable).
Thanks,
Johan
drivers/usb/serial/usb_wwan.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/usb_wwan.c b/drivers/usb/serial/usb_wwan.c
index 61a73ad..a3e9c09 100644
--- a/drivers/usb/serial/usb_wwan.c
+++ b/drivers/usb/serial/usb_wwan.c
@@ -455,9 +455,6 @@ static struct urb *usb_wwan_setup_urb(struct
usb_serial_port *port,
struct usb_serial *serial = port->serial;
struct urb *urb;
- if (endpoint == -1)
- return NULL;/* endpoint not needed */
-
urb = usb_alloc_urb(0, GFP_KERNEL); /* No ISO */
if (urb == NULL) {
dev_dbg(&serial->interface->dev,
@@ -489,6 +486,9 @@ int usb_wwan_port_probe(struct usb_serial_port *port)
init_usb_anchor(&portdata->delayed);
for (i = 0; i < N_IN_URB; i++) {
+ if (!port->bulk_in_size)
+ break;
+
buffer = (u8 *)__get_free_page(GFP_KERNEL);
if (!buffer)
goto bail_out_error;
@@ -502,8 +502,8 @@ int usb_wwan_port_probe(struct usb_serial_port *port)
}
for (i = 0; i < N_OUT_URB; i++) {
- if (port->bulk_out_endpointAddress == -1)
- continue;
+ if (!port->bulk_out_size)
+ break;
buffer = kmalloc(OUT_BUFLEN, GFP_KERNEL);
if (!buffer)
--
1.7.12.4
--
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 isochronous frame lost
On Fri, 26 Oct 2012, Stefan May wrote: > I saw different bmVideoStandards with lsusb. It is the only parameter > with a different value on both sides. Meanwhile, I found a way to make > the camera work. I need to use the load option nodrop=1 in the host, but > not in the guest. > I have no idea why UVC sees incomplete frames only on host side. It is > definitely a firmware problem. Could you imagine what was not respected > there, so that almost every packet is dropped? I don't think it is a firmware problem. It is a bug in VMWare. 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: xhci Portsc register issue
On Fri, Oct 26, 2012 at 10:32:05AM +0530, shashank chaturvedi wrote: > >Why would you want to do that? For link power management? What is the > >xHCI kernel driver not providing you such that you have to write a > >userspace program? > > I want to do this for link power managment.But i am able to read & write > the PORTPMSC register (as per xhci spec 5.4.9) from userspace program.Why > not the PORTSC regsiter? Do NOT do this from userspace! You need to modify the xHCI kernel driver to support link PM for your host controller. The USB core has specific times it disables link PM (e.g. before a device is reset) and some drivers may require link PM to be disabled. You are circumventing kernel policy by writing the link PM registers from userspace. Do NOT do this! 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
[GIT PATCH] USB fixes for 3.7-rc3
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.7-rc3 for you to fetch changes up to 1d63f24697b1259921f08ad3684502216c1cd793: Merge tag 'for-usb-linus-2012-10-25' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus (2012-10-25 13:34:25 -0700) USB fixes for 3.7-rc3 Here are a bunch of USB fixes for the 3.7-rc tree. There's a lot of small USB serial driver fixes, and one larger one (the mos7840 driver changes are mostly just moving code around to fix problems.) Thanks to Johan Hovold for finding the problems and fixing them all up. Other than those, there is the usual new device ids, xhci bugfixes, and gadget driver fixes, nothing out of the ordinary. Signed-off-by: Greg Kroah-Hartman Anisse Astier (2): ehci: fix Lucid nohandoff pci quirk to be more generic with BIOS versions ehci: Add yet-another Lucid nohandoff pci quirk Daniel Mack (1): usb: musb: dsps: fix res_name length Dave Jones (1): USB: Add missing license tag to ezusb driver. Greg Kroah-Hartman (3): Merge tag 'fixes-for-v3.7-rc3' of git://git.kernel.org/.../balbi/usb into usb-linus Merge tag 'for-usb-linus-2012-10-23' of git://git.kernel.org/.../sarah/xhci into usb-linus Merge tag 'for-usb-linus-2012-10-25' of git://git.kernel.org/.../sarah/xhci into usb-linus Johan Hovold (30): USB: metro-usb: fix port-data memory leak USB: metro-usb: fix io after disconnect USB: whiteheat: fix memory leak in error path USB: whiteheat: fix port-data memory leak USB: ch341: fix port-data memory leak USB: digi_acceleport: fix port-data memory leak USB: mos7720: fix port-data memory leak USB: omninet: fix port-data memory leak USB: quatech2: fix memory leak in error path USB: quatech2: fix port-data memory leaks USB: quatech2: fix close and disconnect urb handling USB: quatech2: fix io after disconnect USB: opticon: fix DMA from stack USB: opticon: fix memory leak in error path USB: mct_u232: fix port-data memory leak USB: mct_u232: fix broken close USB: keyspan: fix NULL-pointer dereferences and memory leaks USB: usb-wwan: fix multiple memory leaks in error paths USB: sierra: fix memory leak in attach error path USB: sierra: fix memory leak in probe error path USB: sierra: fix port-data memory leak USB: mos7840: fix urb leak at release USB: mos7840: fix port-device leak in error path USB: ipw: fix interface-data memory leak in error path USB: option: fix interface-data memory leak in error path USB: qcserial: fix interface-data memory leak in error path USB: mos7840: remove NULL-urb submission USB: mos7840: remove invalid disconnect handling USB: mos7840: fix port-data memory leak USB: mos7840: fix port_probe flow Kuninori Morimoto (2): usb: renesas_usbhs: fixup: avoid NULL access on error case pipe detach usb: renesas_usbhs: fixup dma transfer stall Lan Tianyu (2): usb/xhci: release xhci->lock during turning on/off usb port's acpi power resource and checking the existence of port's power resource usb/xhci: Remove (__force__ __u16) before assigning DeviceRemovable and assign directly. Lennart Sorensen (1): USB: serial: Fix memory leak in sierra_release() Michael Shigorin (1): usb-storage: add unusual_devs entry for Casio EX-N1 digital camera Octavian Purdila (2): usb hub: send clear_tt_buffer_complete events when canceling TT clear work usb hub: use flush_work instead of flush_work_sync Oliver Neukum (2): xhci: endianness xhci_calculate_intel_u2_timeout xhci: fix integer overflow Sarah Sharp (4): xhci: Fix potential NULL ptr deref in command cancellation. xhci: Fix missing break in xhci_evaluate_context_result. xhci: trivial: Remove assigned but unused slot_ctx. xhci: trivial: Remove assigned but unused ep_ctx. Wei Yongjun (1): usb: gadget: net2272: fix missing unlock on error in net2272_irq() drivers/usb/core/hub.c | 7 +- drivers/usb/gadget/net2272.c | 4 +- drivers/usb/host/pci-quirks.c| 9 +- drivers/usb/host/xhci-dbg.c | 2 - drivers/usb/host/xhci-hub.c | 9 +- drivers/usb/host/xhci-ring.c | 11 +++ drivers/usb/host/xhci.c | 8 +- drivers/usb/misc/ezusb.c | 1 + drivers/usb/musb/musb_dsps.c | 8 +- drivers/usb/renesas_usbhs/fifo.c | 1 + drivers/usb/renesas_usbhs/mod_host.c | 5 + drivers/usb/serial/ch341.c | 23 +++-- drivers/usb/serial/digi_acceleport.c | 11
Re: [PATCH usb-next 2/3] USB: option: replace vendor probe rule with match flags
Oliver Neukum writes: > On Thursday 25 October 2012 23:42:30 Bjørn Mork wrote: >> Oliver Neukum writes: >> >> > No need for a private macro. It already exists. >> > >> > /** >> > * USB_DEVICE_AND_INTERFACE_INFO - describe a specific usb device with a >> > class of usb interfaces >> >> Yes, but that one will match on SubClass and Protocol too, and I don't >> know what values those are supposed to have. The idea was to implement >> the same match as before, i.e a wildcard for SubClass and Protocol. > > If we are really missing a macro, the place for it to go is usb.h, not a > private > version. OK, I'll fix that if you really want it. I did consider it before posting the first version, but concluded that this is a somewhat odd case which few drivers, if any, will want to reuse. It is useful here only because we have the old workaround with no information about the associated SubClass and Protocol. Bjørn -- 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: problem with Roseweil eusb3 enclosure
On Fri, Oct 26, 2012 at 06:35:57AM -0400, cov...@ccs.covici.com wrote: > Sarah Sharp wrote: > > git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > Well, with that kernel, it didn't repeat the messages indefinitely, so I > could save them and I also have the messages from the log when I > unplugged the enclosure and replugged. > > Here is the output: > > usb 4-2: Device not responding to set address. > usb 4-2: Device not responding to set address. > usb 4-2: device not accepting address 6, error -71 > hub 4-0:1.0: unable to enumerate USB device on port 2 Ok, so you were having issues with the Set Address command. > and when I unplugged and plugged back in I got: > Oct 26 05:54:34 ccs kernel: usb 4-2: device not accepting address 68, error > -62 > Oct 26 05:54:34 ccs kernel: xhci_hcd :04:00.0: Error while assigning > device slot ID > Oct 26 05:54:34 ccs kernel: hub 4-0:1.0: couldn't allocate port 2 usb_device > Oct 26 05:54:34 ccs kernel: xhci_hcd :04:00.0: Bad Slot ID 1 > Oct 26 05:54:34 ccs kernel: xhci_hcd :04:00.0: Could not allocate xHCI > USB device data structures > Oct 26 05:54:34 ccs kernel: hub 4-0:1.0: couldn't allocate port 2 usb_device Those error messages are unexpected. Can you recompile that kernel with CONFIG_USB_XHCI_HCD_DEBUGGING turned on, and post the full dmesg from when you boot with the device plugged in, and then unplug and replug it? I need the full dmesg, not just snippets. > But if I don't boot with the enclosure plugged in, when the system comes > up I can plug in and get a drive. Well, that's good. Let's try to figure out what's wrong with the case of booting with the drive connected. 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: Endpoint is not halted
On Fri, Oct 26, 2012 at 10:45:56AM +0530, Chintan Mehta wrote:
> Hi Sarah,
>
> Thanks for the patch, I will try this out and let you know the results.
>
> One thing I am curios about, will this same patch apply to windows
> driver/Compliance Verification Suite as well?
>
> If this also applies to windows driver and Compliance Verification Suite,
> let us know the version numbers, so we can verify our Host with it.
The Linux xHCI driver, the windows driver, and the compliance
verification driver are all separately architected drivers. One patch
will not apply to another.
Sarah Sharp
> On Fri, Oct 26, 2012 at 4:55 AM, Sarah Sharp
> wrote:
>
> > Hi Chintan,
> >
> > I think I have a fix for the TD size issue. Can you install a custom
> > kernel and test it out on your host controller?
> >
> > The directions for building a custom kernel are here:
> > http://kernelnewbies.org/KernelBuild
> >
> > Instead of running any of the commands in "Which kernel to build?"
> > section, use these commands instead:
> >
> > git clone git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git -b
> > for-usb-linus-queue
> > cd xhci
> >
> > Use the "Duplicating your current config" section.
> >
> > If you have trouble booting the 3.7-rc2 kernel, let me know and I'll
> > rebase the patch against a stable kernel version.
> >
> > Sarah Sharp
> >
> >
> > On Thu, Oct 25, 2012 at 03:32:08PM -0700, Sarah Sharp wrote:
> > > Going back over your example, it does look there is a couple bugs in the
> > > Linux xHCI TD size calculations. Notes are below, I'll send you a patch
> > > to test out on your host controller shortly.
> > >
> > > Thanks for catching this!
> > >
> > > Sarah Sharp
> > >
> > > On Thu, Oct 25, 2012 at 02:24:04PM -0700, Sarah Sharp wrote:
> > > > On Fri, Oct 19, 2012 at 11:29:44AM +0530, Chintan Mehta wrote:
> > > > > > > > 2. For Bulk Endpoint:
> > > > > > > >
> > > > > > > >- *Driver can put a TD with total TD transfer size less than
> > > > > > maxpacket
> > > > > > > >size and more than 1 TRB?*
> > > > > > > >- For example, Maxpacketsize is 1K. And TD contains 3 TRBs
> > as below:
> > > > > > > > - 1st trb with TRB transfer length 600 Bytes, chain bit
> > 1 and
> > > > > > > > TDSize 0
> > > > > > > > - 2nd trb with TRB transfer length 200 Bytes, chain bit
> > 1 and
> > > > > > > > TDSize 0
> > > > > > > > - 3rd trb with TRB transfer length 100 Bytes, chain bit
> > 0 and
> > > > > > > > TDSize 0
> > > > > > > >- *What should be the value of TDSize in above TRBs of TD?*
> > > > > >
> > > > > > Again, see section 4.11.2.4.
> > > > > >
> > > > > > TRB 1 600 (600 + 200 + 100) >> 10 = 0
> > > > > > TRB 2 200 (200 + 100) >> 10 = 0
> > > > > > TRB 3 100 (100) >> 10 = 0
> > >
> > > Let's see what the TD size for a 1.0 host controller should be here.
> > >
> > > TD packet count =
> > > roundup(TD size / max packet size) =
> > > roundup(900 / 1024) = 1
> > >
> > > Packets Transferred (TRB 1) =
> > > rounddown(TRB length sum(n) / max packet size)
> > >
> > > where TRB length sum is the sum of the trb lengths up to and including
> > > this TRB, so
> > >
> > > Packets Transferred (TRB 1) = rounddown(600 / 1024) = 0
> > >
> > > TD size = (TD packet count - Packets Transferred)
> > >
> > > Therefore,
> > >
> > > TD size(TRB 1) = (1 - 0) = 1
> > >
> > > Packets Transferred (TRB 2) =
> > > rounddown((600 + 200) / 1024) = 0
> > > TD size(TRB 2) = (1 - 0) = 1
> > >
> > > The TD size for TRB 3 is supposed to be set to 0, since it is the last
> > > TRB in the TD.
> > >
> > > So, the final answer should be
> > > TRB 1: TD size = 1
> > > TRB 2: TD size = 1
> > > TRB 3: TD size = 0
> > >
> > > Now let's see what the xHCI driver actually does.
> > >
> > > static u32 xhci_td_remainder(unsigned int remainder)
> > > {
> > > u32 max = (1 << (21 - 17 + 1)) - 1;
> > >
> > > if ((remainder >> 10) >= max)
> > > return max << 17;
> > > else
> > > return (remainder >> 10) << 17;
> > > }
> > >
> > > static u32 xhci_v1_0_td_remainder(int running_total, int trb_buff_len,
> > > unsigned int total_packet_count, struct urb *urb)
> > > {
> > > int packets_transferred;
> > >
> > > /* One TRB with a zero-length data packet. */
> > > if (running_total == 0 && trb_buff_len == 0)
> > > return 0;
> > >
> > > /* All the TRB queueing functions don't count the current TRB in
> > > * running_total.
> > > */
> > > packets_transferred = (running_total + trb_buff_len) /
> > > usb_endpoint_maxp(&urb->ep->desc);
> > >
> > > return xhci_td_remainder(total_packet_count -
> > packets_transferred);
> > > }
> > >
> > > That doesn't look right from the start, because passing the result to
> > > xhci_td_remainder() will left shift it by 10, which isn't what we want.
> > > I'll assume I've fixed that
Re: Endpoint is not halted
On Fri, Oct 26, 2012 at 02:50:20PM +0800, Shimmer Huang wrote:
> Sarah,
>
> We've found the TD_size issue when developing a new XHCI host controller also:
> 1. need fix xhci_td_remainder() and xhci_v1_0_td_remainder()
What needed to be fixed in xhci_td_remainder()?
> 2. we need to use DIV_ROUND_UP() instead of roundup() when we
> calculating total_packet_count .
> As in recent kernel versions, roundup() is defined as follow
> #define roundup(x, y) ( \
> { \
> const typeof(y) __y = y;\
> (((x) + (__y - 1)) / __y) * __y;\
> } \
> )
>
> And DIV_ROUND_UP is defined as
> #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
>
> The function roundup() is used several times in xhci-ring.c to
> calculate the number of packets needed:
> total_packet_count = roundup(td_len,
> usb_endpoint_maxp(&urb->ep->desc));
>
> total_packet_count = roundup(urb->transfer_buffer_length,
> usb_endpoint_maxp(&urb->ep->desc));
Yes, you're right about needing to use DIV_ROUND_UP() instead of
roundup(). Obviously I didn't test this patch very well. :-/
Chintan, I've updated that branch with the DIV_ROUND_UP() fix.
Please test with that instead, by running:
git fetch orgin
git reset --hard for-usb-linus-queue
And then recompile and try it out.
Shimmer, the fix diff is attached. Please look it over and see if I've
missed any of the TD size fixes you found during your xHCI host bring
up. Did you happen to find any other issues in your testing?
Sarah Sharp
>
> On Fri, Oct 26, 2012 at 7:25 AM, Sarah Sharp
> wrote:
> > Hi Chintan,
> >
> > I think I have a fix for the TD size issue. Can you install a custom
> > kernel and test it out on your host controller?
> >
> > The directions for building a custom kernel are here:
> > http://kernelnewbies.org/KernelBuild
> >
> > Instead of running any of the commands in "Which kernel to build?"
> > section, use these commands instead:
> >
> > git clone git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git -b
> > for-usb-linus-queue
> > cd xhci
> >
> > Use the "Duplicating your current config" section.
> >
> > If you have trouble booting the 3.7-rc2 kernel, let me know and I'll
> > rebase the patch against a stable kernel version.
> >
> > Sarah Sharp
> >
> >
> > On Thu, Oct 25, 2012 at 03:32:08PM -0700, Sarah Sharp wrote:
> >> Going back over your example, it does look there is a couple bugs in the
> >> Linux xHCI TD size calculations. Notes are below, I'll send you a patch
> >> to test out on your host controller shortly.
> >>
> >> Thanks for catching this!
> >>
> >> Sarah Sharp
> >>
> >> On Thu, Oct 25, 2012 at 02:24:04PM -0700, Sarah Sharp wrote:
> >> > On Fri, Oct 19, 2012 at 11:29:44AM +0530, Chintan Mehta wrote:
> >> > > > > > 2. For Bulk Endpoint:
> >> > > > > >
> >> > > > > >- *Driver can put a TD with total TD transfer size less than
> >> > > > maxpacket
> >> > > > > >size and more than 1 TRB?*
> >> > > > > >- For example, Maxpacketsize is 1K. And TD contains 3 TRBs as
> >> > > > > > below:
> >> > > > > > - 1st trb with TRB transfer length 600 Bytes, chain bit 1
> >> > > > > > and
> >> > > > > > TDSize 0
> >> > > > > > - 2nd trb with TRB transfer length 200 Bytes, chain bit 1
> >> > > > > > and
> >> > > > > > TDSize 0
> >> > > > > > - 3rd trb with TRB transfer length 100 Bytes, chain bit 0
> >> > > > > > and
> >> > > > > > TDSize 0
> >> > > > > >- *What should be the value of TDSize in above TRBs of TD?*
> >> > > >
> >> > > > Again, see section 4.11.2.4.
> >> > > >
> >> > > > TRB 1 600 (600 + 200 + 100) >> 10 = 0
> >> > > > TRB 2 200 (200 + 100) >> 10 = 0
> >> > > > TRB 3 100 (100) >> 10 = 0
> >>
> >> Let's see what the TD size for a 1.0 host controller should be here.
> >>
> >> TD packet count =
> >> roundup(TD size / max packet size) =
> >> roundup(900 / 1024) = 1
> >>
> >> Packets Transferred (TRB 1) =
> >> rounddown(TRB length sum(n) / max packet size)
> >>
> >> where TRB length sum is the sum of the trb lengths up to and including
> >> this TRB, so
> >>
> >> Packets Transferred (TRB 1) = rounddown(600 / 1024) = 0
> >>
> >> TD size = (TD packet count - Packets Transferred)
> >>
> >> Therefore,
> >>
> >> TD size(TRB 1) = (1 - 0) = 1
> >>
> >> Packets Transferred (TRB 2) =
> >> rounddown((600 + 200) / 1024) = 0
> >> TD size(TRB 2) = (1 - 0) = 1
> >>
> >> The TD size for TRB 3 is supposed to be set to 0, since it is the last
> >> TRB in the TD.
> >>
> >> So, the final answer should be
> >> TRB 1: TD size = 1
> >> TRB 2: TD size = 1
> >> TRB 3: TD size = 0
> >>
> >> Now let's see what the xHCI driver actually does.
> >>
> >> static u32 xhci_td_remainder(unsigned int remainder)
> >> {
> >> u32 max = (1 << (21 - 17 + 1)) - 1;
> >>
> >> if ((remainder >> 10) >= max)
> >> return max << 17;
> >> else
> >>
Re: [PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
On Fri, 26 Oct 2012, Benoit Cousson wrote: > On 10/26/2012 05:16 PM, Roger Quadros wrote: > > > I still can't get musb to work on 3.7-rc2. Apparently it is still > > missing the patches from Benoit's for_3.7/dts_part2. > > > > Maybe I just need to wait for it to be merged? > > They are now in a for_3.8/dts. Unfortunately, one patch that was adding > ctrl_module address in the USB data was rejected and thus I'm not sure > it will work without that. For v3.7-rc timeframe, looks like it's waiting on an ack from you: http://www.spinics.net/lists/arm-kernel/msg201028.html - Paul -- 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 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
Hi Paul, On 10/26/2012 07:54 PM, Paul Walmsley wrote: > On Fri, 26 Oct 2012, Benoit Cousson wrote: > >> On 10/26/2012 05:16 PM, Roger Quadros wrote: >> >>> I still can't get musb to work on 3.7-rc2. Apparently it is still >>> missing the patches from Benoit's for_3.7/dts_part2. >>> >>> Maybe I just need to wait for it to be merged? >> >> They are now in a for_3.8/dts. Unfortunately, one patch that was adding >> ctrl_module address in the USB data was rejected and thus I'm not sure >> it will work without that. > > For v3.7-rc timeframe, looks like it's waiting on an ack from you: > > http://www.spinics.net/lists/arm-kernel/msg201028.html Oups, I missed that one. But I thought Roger was mentioning the DT patch and not that one. Anyway, I will answer to Tony. Thanks for the reminder Paul. Regards, Benoit -- 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 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
On 10/26/2012 07:57 PM, Benoit Cousson wrote: > Hi Paul, > > On 10/26/2012 07:54 PM, Paul Walmsley wrote: >> On Fri, 26 Oct 2012, Benoit Cousson wrote: >> >>> On 10/26/2012 05:16 PM, Roger Quadros wrote: >>> I still can't get musb to work on 3.7-rc2. Apparently it is still missing the patches from Benoit's for_3.7/dts_part2. Maybe I just need to wait for it to be merged? >>> >>> They are now in a for_3.8/dts. Unfortunately, one patch that was adding >>> ctrl_module address in the USB data was rejected and thus I'm not sure >>> it will work without that. >> >> For v3.7-rc timeframe, looks like it's waiting on an ack from you: >> >> http://www.spinics.net/lists/arm-kernel/msg201028.html > > Oups, I missed that one. But I thought Roger was mentioning the DT patch > and not that one. > > Anyway, I will answer to Tony. Thanks for the reminder Paul. Well, in fact, I cannot even find the original email in my mailbox :-( I was banned again from linux-omap around that time, so that might be the reason. Tony, So please take that hacky patch if it prevents the regression. Thanks, Benoit -- 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: Hibernation with LPM, was: Re: xhci: LPM issues using Western Digital harddrive
On Tue, 16 Oct 2012, Sarah Sharp wrote: > > > > In addition to this, I see that ehci-hcd includes some basic support > > > > for LPM but it doesn't implement the set_usb2_hw_lpm HCD method. It's > > > > a sort of do-it-yourself approach (and it includes a bunch of bugs). > > > > > > Yeah, I think Jacob Pan and another OTC person worked on the USB 2.1 LPM > > > for an Intel SoC board, but they never found very many USB 2.1 devices, > > > so they couldn't test it very well. > > > > Maybe that's an indication we shouldn't bother to support it. What do > > you think? I could take it out of ehci-hcd easily enough. > > My instinct is to just take out. But Alex and Jacob should probably > have some input on that. Given that ten days have gone by with no comment on this, I will go ahead and remove the USB-2.1 LPM code from ehci-hcd. Last chance for any objections... 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: [PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
* Benoit Cousson [121026 11:11]: > On 10/26/2012 07:57 PM, Benoit Cousson wrote: > > Hi Paul, > > > > On 10/26/2012 07:54 PM, Paul Walmsley wrote: > >> On Fri, 26 Oct 2012, Benoit Cousson wrote: > >> > >>> On 10/26/2012 05:16 PM, Roger Quadros wrote: > >>> > I still can't get musb to work on 3.7-rc2. Apparently it is still > missing the patches from Benoit's for_3.7/dts_part2. > > Maybe I just need to wait for it to be merged? > >>> > >>> They are now in a for_3.8/dts. Unfortunately, one patch that was adding > >>> ctrl_module address in the USB data was rejected and thus I'm not sure > >>> it will work without that. > >> > >> For v3.7-rc timeframe, looks like it's waiting on an ack from you: > >> > >> http://www.spinics.net/lists/arm-kernel/msg201028.html > > > > Oups, I missed that one. But I thought Roger was mentioning the DT patch > > and not that one. > > > > Anyway, I will answer to Tony. Thanks for the reminder Paul. > > Well, in fact, I cannot even find the original email in my mailbox :-( > I was banned again from linux-omap around that time, so that might be > the reason. > > So please take that hacky patch if it prevents the regression. OK yes it seems like that's the only option we have until omap4 is device tree only. Regards, Tony -- 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: HDD spins up to slow for USB and/or Mass-Storage Driver
On Wed, Oct 24, 2012 at 08:26:21PM +0200, Matthias Schniedermeyer wrote:
> I tried 3.7-rc2 (exactly, i think)
>
> This isn't the same computer, but the same('oldconfig'ed)
> configuration. This computer has a NEC-chip for xhci.
>
> uname -a:
> Linux exp 3.7.0-rc2 #1 SMP Wed Oct 24 19:45:48 CEST 2012 x86_64 GNU/Linux
>
> First:
> Oct 24 20:17:52 localhost kernel: [ 118.531900] usb 4-1: new SuperSpeed USB
> device number 2 using xhci_hcd
> Oct 24 20:17:52 localhost kernel: [ 118.546081] usb 4-1: Parent hub missing
> LPM exit latency info. Power management will be impacted.
> Oct 24 20:18:02 localhost kernel: [ 128.518344] usb 4-1: New USB device
> found, idVendor=174c, idProduct=5106
> Oct 24 20:18:02 localhost kernel: [ 128.519551] usb 4-1: New USB device
> strings: Mfr=2, Product=3, SerialNumber=1
> Oct 24 20:18:02 localhost kernel: [ 128.520696] usb 4-1: Product: AS2105
> Oct 24 20:18:02 localhost kernel: [ 128.521828] usb 4-1: Manufacturer:
> ASMedia
> Oct 24 20:18:07 localhost kernel: [ 133.507705] usb 4-1: can't set config
> #1, error -110
>
> Command:
> echo 1 >/sys/bus/usb/devices/4-1/bConfigurationValue
>
> Same response as before:
> Oct 24 20:18:50 localhost kernel: [ 176.642856] xhci_hcd :04:00.0:
> Trying to add endpoint 0x81 without dropping it.
I have two hypothesis. Either the USB core's error handling in
usb_set_configuration is not resetting the bandwidth after it the
endpoints are allocated, or maybe the xHCI host stopped responding to
commands all together, and the command to reset the bandwidth timed out.
Can you recompile with CONFIG_USB_XHCI_HCD_DEBUGGING turned on, and send
me the full dmesg? I'd like to see what happens when the configuration
fails, and then you write to the bConfigurationValue file.
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: problem with Roseweil eusb3 enclosure
Sarah Sharp wrote: > On Fri, Oct 26, 2012 at 06:35:57AM -0400, cov...@ccs.covici.com wrote: > > Sarah Sharp wrote: > > > git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > > > Well, with that kernel, it didn't repeat the messages indefinitely, so I > > could save them and I also have the messages from the log when I > > unplugged the enclosure and replugged. > > > > Here is the output: > > > > usb 4-2: Device not responding to set address. > > usb 4-2: Device not responding to set address. > > usb 4-2: device not accepting address 6, error -71 > > hub 4-0:1.0: unable to enumerate USB device on port 2 > > Ok, so you were having issues with the Set Address command. > > > and when I unplugged and plugged back in I got: > > Oct 26 05:54:34 ccs kernel: usb 4-2: device not accepting address 68, error > > -62 > > Oct 26 05:54:34 ccs kernel: xhci_hcd :04:00.0: Error while assigning > > device slot ID > > Oct 26 05:54:34 ccs kernel: hub 4-0:1.0: couldn't allocate port 2 usb_device > > Oct 26 05:54:34 ccs kernel: xhci_hcd :04:00.0: Bad Slot ID 1 > > Oct 26 05:54:34 ccs kernel: xhci_hcd :04:00.0: Could not allocate xHCI > > USB device data structures > > Oct 26 05:54:34 ccs kernel: hub 4-0:1.0: couldn't allocate port 2 usb_device > > Those error messages are unexpected. Can you recompile that kernel with > CONFIG_USB_XHCI_HCD_DEBUGGING turned on, and post the full dmesg from > when you boot with the device plugged in, and then unplug and replug it? > I need the full dmesg, not just snippets. > > > But if I don't boot with the enclosure plugged in, when the system comes > > up I can plug in and get a drive. > > Well, that's good. Let's try to figure out what's wrong with the case > of booting with the drive connected. OK, I will try to compile the kernel as suggested, however a lot of other messages are missing from the kernel log -- like all the messages nornally seen such as Oct 26 06:01:49 ccs kernel: ACPI: bus type pnp registered When I was using the 3.7 kernel, none of those messages were seen, I wonder if they disabled something? -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com -- 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: problem with Roseweil eusb3 enclosure
On Fri, Oct 26, 2012 at 04:06:01PM -0400, cov...@ccs.covici.com wrote: > Sarah Sharp wrote: > > > On Fri, Oct 26, 2012 at 06:35:57AM -0400, cov...@ccs.covici.com wrote: > > > Sarah Sharp wrote: > > > > git clone > > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > > > > > Well, with that kernel, it didn't repeat the messages indefinitely, so I > > > could save them and I also have the messages from the log when I > > > unplugged the enclosure and replugged. > > > > > > Here is the output: > > > > > > usb 4-2: Device not responding to set address. > > > usb 4-2: Device not responding to set address. > > > usb 4-2: device not accepting address 6, error -71 > > > hub 4-0:1.0: unable to enumerate USB device on port 2 > > > > Ok, so you were having issues with the Set Address command. > > > > > and when I unplugged and plugged back in I got: > > > Oct 26 05:54:34 ccs kernel: usb 4-2: device not accepting address 68, > > > error -62 > > > Oct 26 05:54:34 ccs kernel: xhci_hcd :04:00.0: Error while assigning > > > device slot ID > > > Oct 26 05:54:34 ccs kernel: hub 4-0:1.0: couldn't allocate port 2 > > > usb_device > > > Oct 26 05:54:34 ccs kernel: xhci_hcd :04:00.0: Bad Slot ID 1 > > > Oct 26 05:54:34 ccs kernel: xhci_hcd :04:00.0: Could not allocate > > > xHCI USB device data structures > > > Oct 26 05:54:34 ccs kernel: hub 4-0:1.0: couldn't allocate port 2 > > > usb_device > > > > Those error messages are unexpected. Can you recompile that kernel with > > CONFIG_USB_XHCI_HCD_DEBUGGING turned on, and post the full dmesg from > > when you boot with the device plugged in, and then unplug and replug it? > > I need the full dmesg, not just snippets. > > > > > But if I don't boot with the enclosure plugged in, when the system comes > > > up I can plug in and get a drive. > > > > Well, that's good. Let's try to figure out what's wrong with the case > > of booting with the drive connected. > > OK, I will try to compile the kernel as suggested, however a lot of > other messages are missing from the kernel log -- like all the messages > nornally seen such as > Oct 26 06:01:49 ccs kernel: ACPI: bus type pnp registered > > When I was using the 3.7 kernel, none of those messages were seen, I > wonder if they disabled something? First, do you see those messages if you look in /var/log/kern.log (assuming that file exists on your distro)? If so, you may need to run `sudo dmesg -n 8` in order to see the messages in dmesg. Another thing to check is if the default log level changed. What is CONFIG_DEFAULT_MESSAGE_LOGLEVEL set to? Do you have CONFIG_DEBUG_KERNEL turned on? For xHCI debugging, make sure you also have CONFIG_USB_DEBUG turned on as well as CONFIG_USB_XHCI_HCD_DEBUGGING and CONFIG_DEBUG_KERNEL. 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: problem with Roseweil eusb3 enclosure
Sarah Sharp wrote: > On Fri, Oct 26, 2012 at 04:06:01PM -0400, cov...@ccs.covici.com wrote: > > Sarah Sharp wrote: > > > > > On Fri, Oct 26, 2012 at 06:35:57AM -0400, cov...@ccs.covici.com wrote: > > > > Sarah Sharp wrote: > > > > > git clone > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > > > > > > > Well, with that kernel, it didn't repeat the messages indefinitely, so I > > > > could save them and I also have the messages from the log when I > > > > unplugged the enclosure and replugged. > > > > > > > > Here is the output: > > > > > > > > usb 4-2: Device not responding to set address. > > > > usb 4-2: Device not responding to set address. > > > > usb 4-2: device not accepting address 6, error -71 > > > > hub 4-0:1.0: unable to enumerate USB device on port 2 > > > > > > Ok, so you were having issues with the Set Address command. > > > > > > > and when I unplugged and plugged back in I got: > > > > Oct 26 05:54:34 ccs kernel: usb 4-2: device not accepting address 68, > > > > error -62 > > > > Oct 26 05:54:34 ccs kernel: xhci_hcd :04:00.0: Error while > > > > assigning device slot ID > > > > Oct 26 05:54:34 ccs kernel: hub 4-0:1.0: couldn't allocate port 2 > > > > usb_device > > > > Oct 26 05:54:34 ccs kernel: xhci_hcd :04:00.0: Bad Slot ID 1 > > > > Oct 26 05:54:34 ccs kernel: xhci_hcd :04:00.0: Could not allocate > > > > xHCI USB device data structures > > > > Oct 26 05:54:34 ccs kernel: hub 4-0:1.0: couldn't allocate port 2 > > > > usb_device > > > > > > Those error messages are unexpected. Can you recompile that kernel with > > > CONFIG_USB_XHCI_HCD_DEBUGGING turned on, and post the full dmesg from > > > when you boot with the device plugged in, and then unplug and replug it? > > > I need the full dmesg, not just snippets. > > > > > > > But if I don't boot with the enclosure plugged in, when the system comes > > > > up I can plug in and get a drive. > > > > > > Well, that's good. Let's try to figure out what's wrong with the case > > > of booting with the drive connected. > > > > OK, I will try to compile the kernel as suggested, however a lot of > > other messages are missing from the kernel log -- like all the messages > > nornally seen such as > > Oct 26 06:01:49 ccs kernel: ACPI: bus type pnp registered > > > > When I was using the 3.7 kernel, none of those messages were seen, I > > wonder if they disabled something? > > First, do you see those messages if you look in /var/log/kern.log > (assuming that file exists on your distro)? If so, you may need to run > `sudo dmesg -n 8` in order to see the messages in dmesg. > > Another thing to check is if the default log level changed. What is > CONFIG_DEFAULT_MESSAGE_LOGLEVEL set to? Do you have CONFIG_DEBUG_KERNEL > turned on? > > For xHCI debugging, make sure you also have CONFIG_USB_DEBUG turned on > as well as CONFIG_USB_XHCI_HCD_DEBUGGING and CONFIG_DEBUG_KERNEL. Well, the default log level is 4 in both cases, but no messages were generated by the 3.7.0-rc1 kernel. I will make sure those other configs are on -- glad you mentioned them before booting into the kernel. Thanks. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com -- 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: HDD spins up to slow for USB and/or Mass-Storage Driver
On Fri, Oct 26, 2012 at 10:36:06PM +0200, Matthias Schniedermeyer wrote:
> On 26.10.2012 12:27, Sarah Sharp wrote:
> > On Wed, Oct 24, 2012 at 08:26:21PM +0200, Matthias Schniedermeyer wrote:
> > > I tried 3.7-rc2 (exactly, i think)
> > >
> > > This isn't the same computer, but the same('oldconfig'ed)
> > > configuration. This computer has a NEC-chip for xhci.
> > >
> > > uname -a:
> > > Linux exp 3.7.0-rc2 #1 SMP Wed Oct 24 19:45:48 CEST 2012 x86_64 GNU/Linux
> > >
> > > First:
> > > Oct 24 20:17:52 localhost kernel: [ 118.531900] usb 4-1: new SuperSpeed
> > > USB device number 2 using xhci_hcd
> > > Oct 24 20:17:52 localhost kernel: [ 118.546081] usb 4-1: Parent hub
> > > missing LPM exit latency info. Power management will be impacted.
> > > Oct 24 20:18:02 localhost kernel: [ 128.518344] usb 4-1: New USB device
> > > found, idVendor=174c, idProduct=5106
> > > Oct 24 20:18:02 localhost kernel: [ 128.519551] usb 4-1: New USB device
> > > strings: Mfr=2, Product=3, SerialNumber=1
> > > Oct 24 20:18:02 localhost kernel: [ 128.520696] usb 4-1: Product: AS2105
> > > Oct 24 20:18:02 localhost kernel: [ 128.521828] usb 4-1: Manufacturer:
> > > ASMedia
> > > Oct 24 20:18:07 localhost kernel: [ 133.507705] usb 4-1: can't set
> > > config #1, error -110
> > >
> > > Command:
> > > echo 1 >/sys/bus/usb/devices/4-1/bConfigurationValue
> > >
> > > Same response as before:
> > > Oct 24 20:18:50 localhost kernel: [ 176.642856] xhci_hcd :04:00.0:
> > > Trying to add endpoint 0x81 without dropping it.
> >
> > I have two hypothesis. Either the USB core's error handling in
> > usb_set_configuration is not resetting the bandwidth after it the
> > endpoints are allocated, or maybe the xHCI host stopped responding to
> > commands all together, and the command to reset the bandwidth timed out.
> >
> > Can you recompile with CONFIG_USB_XHCI_HCD_DEBUGGING turned on, and send
> > me the full dmesg? I'd like to see what happens when the configuration
> > fails, and then you write to the bConfigurationValue file.
>
> Here we go, this is still with 3.7-rc2:
Ok, I think I see the issue:
> [ 34.083530] usb 3-1: New USB device found, idVendor=174c, idProduct=5106
> [ 34.084647] usb 3-1: New USB device strings: Mfr=2, Product=3,
> SerialNumber=1
> [ 34.085703] usb 3-1: Product: AS2105
> [ 34.086751] usb 3-1: Manufacturer: ASMedia
> [ 34.087856] usb 3-1: usb_probe_device
> [ 34.087858] usb 3-1: configuration #1 chosen from 1 choice
> [ 34.087862] xhci_hcd :04:00.0: add ep 0x81, slot id 1, new drop flags
> = 0x0, new add flags = 0x8, new slot info = 0x1840
> [ 34.087865] xhci_hcd :04:00.0: add ep 0x2, slot id 1, new drop flags =
> 0x0, new add flags = 0x18, new slot info = 0x2040
> [ 34.087867] xhci_hcd :04:00.0: xhci_check_bandwidth called for udev
> 880111aa6000
...
> [ 34.088217] usb 3-1: Successful Endpoint Configure command
...
> [ 39.072627] xhci_hcd :04:00.0: Cancel URB 880113177e40, dev 1, ep
> 0x0, starting at offset 0xd7420a10
> [ 39.072632] xhci_hcd :04:00.0: // Ding dong!
> [ 39.072852] xhci_hcd :04:00.0: Removing canceled TD starting at
> 0xd7420a10 (dma).
> [ 39.072857] xhci_hcd :04:00.0: TRB to noop at offset 0xd7420a10
> [ 39.072861] xhci_hcd :04:00.0: TRB to noop at offset 0xd7420a20
> [ 39.072884] usb 3-1: khubd timed out on ep0out len=0/0
> [ 39.072889] xhci_hcd :04:00.0: xhci_check_bandwidth called for udev
> 880111aa6000
> [ 39.072894] usb 3-1: can't set config #1, error -110
The USB core isn't dropping the endpoints before it calls
xhci_check_bandwidth. I remember running into this bug a while back,
and I even started on a fix, but then couldn't reproduce the problem.
I found the branch with the old fix on it, but it still needs a bit of
work. I'll send you a patch on Monday.
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
kmemleak report on isp1763 and sierra MC8705
Hi Guys, I am debugging a reported kmemleak involving a sierra wireless MC8705 connected through isp1763 on powerpc linux-3.0.22 We are still isolating the exact trigger, but this is a pretty good one so far send "at!reset" to the modem control tty, wait until it finishes rebooting then try to bring up a PPP link that will fail (non existent ISP). After some time, we got the report (included at the end) from kmemleak. There seems to be two variants of trace that is prevalent: something like this: unreferenced object 0xd58e58c8 (size 8): comm "khubd", pid 1034, jiffies 74467293 (age 2380.122s) hex dump (first 8 bytes): 4d 43 38 37 30 35 00 00 MC8705.. backtrace: [] usb_cache_string+0x74/0xac [usbcore] [] usb_enumerate_device+0x44/0xf8 [usbcore] [] usb_new_device+0x3c/0x13c [usbcore] [] hub_thread+0xc8c/0x1544 [usbcore] [] kthread+0x7c/0x80 [] kernel_thread+0x4c/0x68 and something like this: unreferenced object 0xd5893e00 (size 512): comm "khubd", pid 1034, jiffies 74467270 (age 2378.786s) hex dump (first 32 bytes): 09 02 a8 00 06 01 01 e0 00 00 00 00 d5 87 d6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [] usb_get_configuration+0x5c/0x13a8 [usbcore] [] usb_enumerate_device+0xd8/0xf8 [usbcore] [] usb_new_device+0x3c/0x13c [usbcore] [] hub_thread+0xc8c/0x1544 [usbcore] [] kthread+0x7c/0x80 [] kernel_thread+0x4c/0x68 Some questions: 1. Have you guys seen anything like this before? 2. The report does not point to sierra or isp1763, so our current understanding is that the memory is allocated outside these drivers and it is supposed to mark it done for someone to free it. We think this way because if we rigged a driver to leak a memory it allocates, kmemleak will trace right into it. Is this understanding correct? 3. Any ideas on how to deepen the probe to get more understanding of what happens? 4. Michael, is this similar to the problem you reported here? http://marc.info/?l=linux-usb&m=133432571801643&w=4 From reading your report (serial device hanging), It doesn't look like it... 5. Our current hypothesis is this: we open the /dev/ttyUSB to send "at!reset", then a race begins between closing the file handle and freeing the driver resources and the modem hardware actually resetting, which then caused the leak. Can this be it? and if so, any ideas on how to solve it? To test this we are power cycling the modem using a gpio (without opening /dev/ttyUSB) to see if this is the culprit. 6. There is a worrisome line in our (old version) of isp1763 inherited from isp1760: isp1760_endpoint_disable() ... qh_destroy(qh); ep->hcpriv = NULL; /* remove requests and leak them. * ATL are pretty fast done, INT could take a while... * The latter shoule be removed */ What is leaking here? qh_destroy release the memory already. Thanks for everyone's time! -- Richard Retanubun unreferenced object 0xd5922c00 (size 1024): comm "khubd", pid 1034, jiffies 74467113 (age 2378.943s) hex dump (first 32 bytes): ff ff ff ff 31 2e 32 00 00 00 00 00 00 00 00 00 1.2. 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 03 backtrace: [] usb_alloc_dev+0x48/0x290 [usbcore] [] hub_thread+0x654/0x1544 [usbcore] [] kthread+0x7c/0x80 [] kernel_thread+0x4c/0x68 unreferenced object 0xd58e52b0 (size 8): comm "khubd", pid 1034, jiffies 74467113 (age 2378.943s) hex dump (first 8 bytes): 32 2d 31 2e 32 00 04 00 2-1.2... backtrace: [] kvasprintf+0x58/0x88 [] kobject_set_name_vargs+0x34/0x84 [] dev_set_name+0x50/0x60 [] usb_alloc_dev+0x190/0x290 [usbcore] [] hub_thread+0x654/0x1544 [usbcore] [] kthread+0x7c/0x80 [] kernel_thread+0x4c/0x68 unreferenced object 0xd5893e00 (size 512): comm "khubd", pid 1034, jiffies 74467270 (age 2378.786s) hex dump (first 32 bytes): 09 02 a8 00 06 01 01 e0 00 00 00 00 d5 87 d6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [] usb_get_configuration+0x5c/0x13a8 [usbcore] [] usb_enumerate_device+0xd8/0xf8 [usbcore] [] usb_new_device+0x3c/0x13c [usbcore] [] hub_thread+0xc8c/0x1544 [usbcore] [] kthread+0x7c/0x80 [] kernel_thread+0x4c/0x68 unreferenced object 0xd58e5930 (size 8): comm "khubd", pid 1034, jiffies 74467270 (age 2378.786s) hex dump (first 8 bytes): d5 8a dc c0 00 00 00 00 backtrace: [] usb_get_configuration+0x7c/0x13a8 [usbcore] [] usb_enumerate_device+0xd8/0xf8 [usbcore] [] usb_new_device+0x3c/0x13c [usbcore] [] hub_thread+0xc8c/0x1544 [usbcore] [] kthread+0x7c/0x80 [] kernel_thread+0x4c/0x68 unreferenced
RE: Hibernation with LPM, was: Re: xhci: LPM issues using Western Digital harddrive
> -Original Message- > From: Alan Stern [mailto:st...@rowland.harvard.edu] > Sent: Friday, October 26, 2012 11:52 AM > To: Sarah Sharp > Cc: USB list; Du, Alek; Pan, Jacob jun > Subject: Re: Hibernation with LPM, was: Re: xhci: LPM issues using Western > Digital harddrive > > On Tue, 16 Oct 2012, Sarah Sharp wrote: > > > > > > In addition to this, I see that ehci-hcd includes some basic > > > > > support for LPM but it doesn't implement the set_usb2_hw_lpm HCD > > > > > method. It's a sort of do-it-yourself approach (and it includes a > > > > > bunch > of bugs). > > > > > > > > Yeah, I think Jacob Pan and another OTC person worked on the USB > > > > 2.1 LPM for an Intel SoC board, but they never found very many USB > > > > 2.1 devices, so they couldn't test it very well. > > > > > > Maybe that's an indication we shouldn't bother to support it. What > > > do you think? I could take it out of ehci-hcd easily enough. > > > > My instinct is to just take out. But Alex and Jacob should probably > > have some input on that. > > Given that ten days have gone by with no comment on this, I will go ahead > and remove the USB-2.1 LPM code from ehci-hcd. > > Last chance for any objections... > I have no objections. Sorry for the lack of response, it has been awhile since I worked on USB. > 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: HDD spins up to slow for USB and/or Mass-Storage Driver
On Fri, Oct 26, 2012 at 03:01:32PM -0700, Sarah Sharp wrote:
> The USB core isn't dropping the endpoints before it calls
> xhci_check_bandwidth. I remember running into this bug a while back,
> and I even started on a fix, but then couldn't reproduce the problem.
> I found the branch with the old fix on it, but it still needs a bit of
> work. I'll send you a patch on Monday.
Matthias, can you try the attached patch? You should be able to echo 1
to the configuration file after this is applied.
Thanks,
Sarah Sharp
>From fda7b0f5cd061b5c6e680ac71fdebc4158867602 Mon Sep 17 00:00:00 2001
From: Sarah Sharp
Date: Tue, 7 Aug 2012 08:38:09 -0700
Subject: [PATCH] USB: Fix dropping endpoints when SetConfig fails.
When the Set Configuration control transfer fails, the USB core will set
the udev->config to NULL *before* calling usb_check_bandwidth. This
means that endpoints that were part of the previous installed
configuration will never be dropped from the xHCI host (until the device
is disconnected). This leads to extra host bandwidth resources being
held. Fix this by explicitly dropping the endpoints when the Set
Configuration fails.
This patch should be backported. FIXME: version.
Signed-off-by: Sarah Sharp
Cc: sta...@vger.kernel.org
---
drivers/usb/core/hcd.c | 80 +---
drivers/usb/core/message.c |3 ++
include/linux/usb/hcd.h|2 +
3 files changed, 65 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 1e741bc..8169e75 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1693,6 +1693,62 @@ rescan:
}
}
+static int usb_hcd_drop_or_add_alt0(struct usb_device *udev,
+ struct usb_host_config *config,
+ bool drop)
+{
+ int num_intfs, i, ret;
+ struct usb_hcd *hcd;
+
+ hcd = bus_to_hcd(udev->bus);
+ num_intfs = config->desc.bNumInterfaces;
+ for (i = 0; i < num_intfs; ++i) {
+ struct usb_host_interface *first_alt, *alt;
+ int iface_num, j;
+
+ first_alt = &config->intf_cache[i]->altsetting[0];
+ iface_num = first_alt->desc.bInterfaceNumber;
+ /* Set up endpoints for alternate interface setting 0 */
+ alt = usb_find_alt_setting(config, iface_num, 0);
+ if (!alt)
+ /* No alt setting 0? Pick the first setting. */
+ alt = first_alt;
+
+ for (j = 0; j < alt->desc.bNumEndpoints; j++) {
+ if (drop)
+ret = hcd->driver->drop_endpoint(hcd, udev,
+ &alt->endpoint[j]);
+ else
+ret = hcd->driver->add_endpoint(hcd, udev,
+ &alt->endpoint[j]);
+ if (ret < 0)
+return ret;
+ }
+ }
+ return 0;
+}
+
+/**
+ * usb_hcd_revert_bandwidth - revert a configuration that failed to be installed.
+ */
+int usb_hcd_revert_bandwidth(struct usb_device *udev,
+ struct usb_host_config *failed_config)
+{
+ int ret;
+ struct usb_hcd *hcd;
+
+ hcd = bus_to_hcd(udev->bus);
+ if (!hcd->driver->check_bandwidth)
+ return 0;
+
+ ret = usb_hcd_drop_or_add_alt0(udev, failed_config, true);
+ if (!ret)
+ ret = hcd->driver->check_bandwidth(hcd, udev);
+ if (ret < 0)
+ hcd->driver->reset_bandwidth(hcd, udev);
+ return ret;
+}
+
/**
* usb_hcd_alloc_bandwidth - check whether a new bandwidth setting exceeds
*the bus bandwidth
@@ -1719,8 +1775,7 @@ int usb_hcd_alloc_bandwidth(struct usb_device *udev,
struct usb_host_interface *cur_alt,
struct usb_host_interface *new_alt)
{
- int num_intfs, i, j;
- struct usb_host_interface *alt = NULL;
+ int num_intfs, i;
int ret = 0;
struct usb_hcd *hcd;
struct usb_host_endpoint *ep;
@@ -1766,24 +1821,9 @@ int usb_hcd_alloc_bandwidth(struct usb_device *udev,
goto reset;
}
}
- for (i = 0; i < num_intfs; ++i) {
- struct usb_host_interface *first_alt;
- int iface_num;
-
- first_alt = &new_config->intf_cache[i]->altsetting[0];
- iface_num = first_alt->desc.bInterfaceNumber;
- /* Set up endpoints for alternate interface setting 0 */
- alt = usb_find_alt_setting(new_config, iface_num, 0);
- if (!alt)
-/* No alt setting 0? Pick the first setting. */
-alt = first_alt;
-
- for (j = 0; j < alt->desc.bNumEndpoints; j++) {
-ret = hcd->driver->add_endpoint(hcd, udev, &alt->endpoint[j]);
-if (ret < 0)
- goto reset;
- }
- }
+ ret = usb_hcd_drop_or_add_alt0(udev, new_config, false);
+ if (ret < 0)
+ goto reset;
}
if (cur_alt && new_alt) {
struct usb_interface *iface = usb_ifnum_to_if(udev,
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 1ed5afd..58b4bf1 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -1812,7 +1812,10 @@ free_interfaces:
if (ret < 0) {
/* All the old state is gone, so what else can we do?
* The device is probably useless now anyway.
+ * We need to deallocate the bandwidth from the failed
+ * configuration, so we don't leak host resources.
*/
+ usb_hcd_revert_bandwidth(dev, cp);
cp = NULL;
}
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 608050b..0c22499 100644
--- a/inc
dummy_hcd: try to add qh
I tried to add the qh structure. It is likely that patch #1 isn't 100% checkpatch clear. If we agree on #3 then I go and clean it up. Sebastian -- 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 1/3] usb/dummy_hcd: move code that handles an URB into a separate function
The code here is moved out of the list for each into a separate
function. There should be no functional change.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/gadget/dummy_hcd.c | 314 +---
1 file changed, 162 insertions(+), 152 deletions(-)
diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
index 0f7541b..ea702c6 100644
--- a/drivers/usb/gadget/dummy_hcd.c
+++ b/drivers/usb/gadget/dummy_hcd.c
@@ -1659,6 +1659,164 @@ static int handle_control_request(struct dummy_hcd
*dum_hcd, struct urb *urb,
return ret_val;
}
+static int handle_one_urb(struct urbp *urbp, struct dummy_hcd *dum_hcd, int
*total)
+{
+ struct dummy*dum = dum_hcd->dum;
+ struct urb *urb;
+ struct dummy_request*req;
+ u8 address;
+ struct dummy_ep *ep = NULL;
+ int type;
+ int status = -EINPROGRESS;
+ int limit;
+
+ urb = urbp->urb;
+ if (urb->unlinked)
+ goto return_urb;
+ else if (dum_hcd->rh_state != DUMMY_RH_RUNNING)
+ return 0;
+ type = usb_pipetype(urb->pipe);
+
+ /* used up this frame's non-periodic bandwidth?
+* FIXME there's infinite bandwidth for control and
+* periodic transfers ... unrealistic.
+*/
+ if (*total <= 0 && type == PIPE_BULK)
+ return 0;
+
+ /* find the gadget's ep for this request (if configured) */
+ address = usb_pipeendpoint (urb->pipe);
+ if (usb_pipein(urb->pipe))
+ address |= USB_DIR_IN;
+ ep = find_endpoint(dum, address);
+ if (!ep) {
+ /* set_configuration() disagreement */
+ dev_dbg(dummy_dev(dum_hcd),
+ "no ep configured for urb %p\n",
+ urb);
+ status = -EPROTO;
+ goto return_urb;
+ }
+
+ if (ep->already_seen)
+ return 0;
+ ep->already_seen = 1;
+ if (ep == &dum->ep[0] && urb->error_count) {
+ ep->setup_stage = 1;/* a new urb */
+ urb->error_count = 0;
+ }
+ if (ep->halted && !ep->setup_stage) {
+ /* NOTE: must not be iso! */
+ dev_dbg(dummy_dev(dum_hcd), "ep %s halted, urb %p\n",
+ ep->ep.name, urb);
+ status = -EPIPE;
+ goto return_urb;
+ }
+ /* FIXME make sure both ends agree on maxpacket */
+
+ /* handle control requests */
+ if (ep == &dum->ep[0] && ep->setup_stage) {
+ struct usb_ctrlrequest setup;
+ int value = 1;
+
+ setup = *(struct usb_ctrlrequest *) urb->setup_packet;
+ /* paranoia, in case of stale queued data */
+ list_for_each_entry(req, &ep->queue, queue) {
+ list_del_init(&req->queue);
+ req->req.status = -EOVERFLOW;
+ dev_dbg(udc_dev(dum), "stale req = %p\n",
+ req);
+
+ spin_unlock(&dum->lock);
+ req->req.complete(&ep->ep, &req->req);
+ spin_lock(&dum->lock);
+ ep->already_seen = 0;
+ return 1;
+ }
+
+ /* gadget driver never sees set_address or operations
+* on standard feature flags. some hardware doesn't
+* even expose them.
+*/
+ ep->last_io = jiffies;
+ ep->setup_stage = 0;
+ ep->halted = 0;
+
+ value = handle_control_request(dum_hcd, urb, &setup,
+ &status);
+
+ /* gadget driver handles all other requests. block
+* until setup() returns; no reentrancy issues etc.
+*/
+ if (value > 0) {
+ spin_unlock(&dum->lock);
+ value = dum->driver->setup(&dum->gadget,
+ &setup);
+ spin_lock(&dum->lock);
+
+ if (value >= 0) {
+ /* no delays (max 64KB data stage) */
+ limit = 64*1024;
+ goto treat_control_like_bulk;
+ }
+ /* error, see below */
+ }
+
+ if (value < 0) {
+ if (value != -EOPNOTSUPP)
+ dev_dbg(udc_dev(dum),
+ "setup --> %d\n",
+ value);
+ status = -EPIPE;
+ urb->actual_length = 0;
+
[RFC 3/3] usb/dummy_hcd: assign endpoint on enqeue on host side
dummy_urb_enqueue() now assigns the endpoint to the qh structure. If the
UDC disables the endpoint (on the device side) the endpoint information
is removed from the qh as well. I think real HW would timeout on
transfer (and return -EPROTO) so we do here the same except that we
might do this early at enqueue time.
Is this behaviour okay or should the transfer be accepted and -EPROTO should
be returned only from the timer while maintaining "last transfer" member in
qh for INT transfers so they don't come too quickly?
I have no issues for "rmmod g_ncm" anymore and I think it is because I
don't have any re-queues at complete time (due to the possible -EPROTO
at enqueue time).
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/gadget/dummy_hcd.c | 116 +---
1 file changed, 74 insertions(+), 42 deletions(-)
diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
index 2c27566..6c91451 100644
--- a/drivers/usb/gadget/dummy_hcd.c
+++ b/drivers/usb/gadget/dummy_hcd.c
@@ -94,6 +94,12 @@ struct dummy_request {
struct usb_request req;
};
+struct dummy_qh {
+ struct list_head urbp_list;
+ struct list_head qh_list;
+ struct dummy_ep *ep;
+};
+
static inline struct dummy_ep *usb_ep_to_dummy_ep(struct usb_ep *_ep)
{
return container_of(_ep, struct dummy_ep, ep);
@@ -557,7 +563,9 @@ static int dummy_enable(struct usb_ep *_ep,
static int dummy_disable(struct usb_ep *_ep)
{
struct dummy_ep *ep;
+ struct dummy_qh *qh;
struct dummy*dum;
+ struct dummy_hcd*dum_hcd;
unsigned long flags;
int retval;
@@ -565,8 +573,17 @@ static int dummy_disable(struct usb_ep *_ep)
if (!_ep || !ep->desc || _ep->name == ep0name)
return -EINVAL;
dum = ep_to_dummy(ep);
+ dum_hcd = gadget_to_dummy_hcd(&dum->gadget);
spin_lock_irqsave(&dum->lock, flags);
+
+ list_for_each_entry(qh, &dum_hcd->qh_list, qh_list) {
+ if (qh->ep == ep) {
+ qh->ep = NULL;
+ break;
+ }
+ }
+
ep->desc = NULL;
ep->stream_en = 0;
retval = 0;
@@ -1161,10 +1178,32 @@ static int dummy_validate_stream(struct dummy_hcd
*dum_hcd, struct urb *urb)
return 0;
}
-struct dummy_qh {
- struct list_head urbp_list;
- struct list_head qh_list;
-};
+#define is_active(dum_hcd) ((dum_hcd->port_status & \
+ (USB_PORT_STAT_CONNECTION | USB_PORT_STAT_ENABLE | \
+ USB_PORT_STAT_SUSPEND)) \
+ == (USB_PORT_STAT_CONNECTION | USB_PORT_STAT_ENABLE))
+
+static struct dummy_ep *find_endpoint(struct dummy *dum, u8 address)
+{
+ int i;
+
+ if (!is_active((dum->gadget.speed == USB_SPEED_SUPER ?
+ dum->ss_hcd : dum->hs_hcd)))
+ return NULL;
+ if ((address & ~USB_DIR_IN) == 0)
+ return &dum->ep[0];
+ for (i = 1; i < DUMMY_ENDPOINTS; i++) {
+ struct dummy_ep *ep = &dum->ep[i];
+
+ if (!ep->desc)
+ continue;
+ if (ep->desc->bEndpointAddress == address)
+ return ep;
+ }
+ return NULL;
+}
+
+#undef is_active
struct dummy_qh *qh_append_urb(struct dummy_hcd *dum_hcd, struct urb *urb)
{
@@ -1180,6 +1219,8 @@ struct dummy_qh *qh_append_urb(struct dummy_hcd *dum_hcd,
struct urb *urb)
list_add_tail(&qh->qh_list, &dum_hcd->qh_list);
INIT_LIST_HEAD(&qh->urbp_list);
urb->ep->hcpriv = qh;
+ qh->ep = NULL;
+
return qh;
}
@@ -1196,9 +1237,15 @@ static void dummy_disable_ep(struct usb_hcd *hcd, struct
usb_host_endpoint *ep)
goto out;
qh = ep->hcpriv;
- list_del(&qh->qh_list);
- kfree(ep->hcpriv);
- ep->hcpriv = NULL;
+ if (qh) {
+ /*
+* the URBs which might be pending here will be nuked by the
+* timer.
+*/
+ list_del(&qh->qh_list);
+ kfree(ep->hcpriv);
+ ep->hcpriv = NULL;
+ }
out:
spin_unlock_irqrestore(&dum_hcd->dum->lock, flags);
}
@@ -1212,6 +1259,7 @@ static int dummy_urb_enqueue(
struct dummy_qh *qh;
struct urbp *urbp;
unsigned long flags;
+ u8 address;
int rc;
urbp = kmalloc(sizeof *urbp, mem_flags);
@@ -1235,6 +1283,20 @@ static int dummy_urb_enqueue(
if (!qh)
goto err_qh;
+ if (!qh->ep) {
+ struct dummy*dum = dum_hcd->dum;
+
+ address = usb_pipeendpoint(urb->pipe);
+ if (usb_pipein(urb->pipe))
+ address |= USB_DIR_IN;
+ qh->ep = find_endpoint(dum, address);
+ }
+
+ i
[RFC 2/3] usb/dummy_hcd: introduce per-ep qh data structure
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/gadget/dummy_hcd.c | 115 ++--
1 file changed, 88 insertions(+), 27 deletions(-)
diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
index ea702c6..2c27566 100644
--- a/drivers/usb/gadget/dummy_hcd.c
+++ b/drivers/usb/gadget/dummy_hcd.c
@@ -167,7 +167,8 @@ struct dummy_hcd {
unsigned long re_timeout;
struct usb_device *udev;
- struct list_headurbp_list;
+ int active_urbs;
+ struct list_headqh_list;
u32 stream_en_ep;
u8 num_stream[30 / 2];
@@ -1160,12 +1161,55 @@ static int dummy_validate_stream(struct dummy_hcd
*dum_hcd, struct urb *urb)
return 0;
}
+struct dummy_qh {
+ struct list_head urbp_list;
+ struct list_head qh_list;
+};
+
+struct dummy_qh *qh_append_urb(struct dummy_hcd *dum_hcd, struct urb *urb)
+{
+ struct dummy_qh *qh;
+
+ qh = urb->ep->hcpriv;
+ if (qh)
+ return qh;
+
+ qh = kmalloc(sizeof(*qh), GFP_ATOMIC);
+ if (!qh)
+ return qh;
+ list_add_tail(&qh->qh_list, &dum_hcd->qh_list);
+ INIT_LIST_HEAD(&qh->urbp_list);
+ urb->ep->hcpriv = qh;
+ return qh;
+}
+
+static void dummy_disable_ep(struct usb_hcd *hcd, struct usb_host_endpoint *ep)
+{
+ struct dummy_hcd *dum_hcd;
+ struct dummy_qh *qh;
+ unsigned long flags;
+
+ dum_hcd = hcd_to_dummy_hcd(hcd);
+ spin_lock_irqsave(&dum_hcd->dum->lock, flags);
+
+ if (!ep->hcpriv)
+ goto out;
+
+ qh = ep->hcpriv;
+ list_del(&qh->qh_list);
+ kfree(ep->hcpriv);
+ ep->hcpriv = NULL;
+out:
+ spin_unlock_irqrestore(&dum_hcd->dum->lock, flags);
+}
+
static int dummy_urb_enqueue(
struct usb_hcd *hcd,
struct urb *urb,
gfp_t mem_flags
) {
struct dummy_hcd *dum_hcd;
+ struct dummy_qh *qh;
struct urbp *urbp;
unsigned long flags;
int rc;
@@ -1180,16 +1224,16 @@ static int dummy_urb_enqueue(
spin_lock_irqsave(&dum_hcd->dum->lock, flags);
rc = dummy_validate_stream(dum_hcd, urb);
- if (rc) {
- kfree(urbp);
- goto done;
- }
+ if (rc)
+ goto err;
rc = usb_hcd_link_urb_to_ep(hcd, urb);
- if (rc) {
- kfree(urbp);
- goto done;
- }
+ if (rc)
+ goto err;
+
+ qh = qh_append_urb(dum_hcd, urb);
+ if (!qh)
+ goto err_qh;
if (!dum_hcd->udev) {
dum_hcd->udev = urb->dev;
@@ -1197,7 +1241,8 @@ static int dummy_urb_enqueue(
} else if (unlikely(dum_hcd->udev != urb->dev))
dev_err(dummy_dev(dum_hcd), "usb_device address has
changed!\n");
- list_add_tail(&urbp->urbp_list, &dum_hcd->urbp_list);
+ list_add_tail(&urbp->urbp_list, &qh->urbp_list);
+ dum_hcd->active_urbs++;
urb->hcpriv = urbp;
if (usb_pipetype(urb->pipe) == PIPE_CONTROL)
urb->error_count = 1; /* mark as a new urb */
@@ -1209,6 +1254,11 @@ static int dummy_urb_enqueue(
done:
spin_unlock_irqrestore(&dum_hcd->dum->lock, flags);
return rc;
+err_qh:
+ usb_hcd_unlink_urb_from_ep(hcd, urb);
+err:
+ kfree(urbp);
+ goto done;
}
static int dummy_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status)
@@ -1224,7 +1274,7 @@ static int dummy_urb_dequeue(struct usb_hcd *hcd, struct
urb *urb, int status)
rc = usb_hcd_check_unlink_urb(hcd, urb, status);
if (!rc && dum_hcd->rh_state != DUMMY_RH_RUNNING &&
- !list_empty(&dum_hcd->urbp_list))
+ dum_hcd->active_urbs)
mod_timer(&dum_hcd->timer, jiffies);
spin_unlock_irqrestore(&dum_hcd->dum->lock, flags);
@@ -1811,6 +1861,7 @@ static int handle_one_urb(struct urbp *urbp, struct
dummy_hcd *dum_hcd, int *tot
ep->already_seen = ep->setup_stage = 0;
usb_hcd_unlink_urb_from_ep(dummy_hcd_to_hcd(dum_hcd), urb);
+ dum_hcd->active_urbs--;
spin_unlock(&dum->lock);
usb_hcd_giveback_urb(dummy_hcd_to_hcd(dum_hcd), urb, status);
spin_lock(&dum->lock);
@@ -1824,7 +1875,7 @@ static void dummy_timer(unsigned long _dum_hcd)
{
struct dummy_hcd*dum_hcd = (struct dummy_hcd *) _dum_hcd;
struct dummy*dum = dum_hcd->dum;
- struct urbp *urbp, *tmp;
+ struct dummy_qh *qh, *qh_tmp;
unsigned long flags;
int total;
int i;
@@ -1868,16 +1919,20 @@ static void dummy_timer(unsi
Re: kmemleak report on isp1763 and sierra MC8705
On Fri, Oct 26, 2012 at 05:57:23PM -0400, Richard Retanubun wrote: > Hi Guys, > > I am debugging a reported kmemleak involving a sierra wireless MC8705 > connected > through isp1763 on powerpc linux-3.0.22 Does this also happen on 3.6.3? thanks, 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
Re: dummy_hcd: try to add qh
On Sat, 27 Oct 2012, Sebastian Andrzej Siewior wrote: > I tried to add the qh structure. It is likely that patch #1 isn't 100% > checkpatch clear. If we agree on #3 then I go and clean it up. Sorry, I've forgotten the context for this change. (We discussed something and I suggested the right solution would be to add an endpoint-specific data structure like a QH on the host side, but I can't remember the details.) Remind me please, what is the problem you need to solve? 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: HDD spins up to slow for USB and/or Mass-Storage Driver
On Fri, 26 Oct 2012, Sarah Sharp wrote: > On Fri, Oct 26, 2012 at 03:01:32PM -0700, Sarah Sharp wrote: > > The USB core isn't dropping the endpoints before it calls > > xhci_check_bandwidth. I remember running into this bug a while back, > > and I even started on a fix, but then couldn't reproduce the problem. > > I found the branch with the old fix on it, but it still needs a bit of > > work. I'll send you a patch on Monday. > > Matthias, can you try the attached patch? You should be able to echo 1 > to the configuration file after this is applied. It seems that this patch should go farther than it does. Basically, what you are doing amounts to splitting usb_hcd_alloc_bandwidth() up into two separate routines: one for altsetting changes and one for config changes. But that's not how the new code is structured and as a result it ends up looking rather tortuous. Also, I don't like the way we repeat that "find altsetting 0 or use the first altsetting" logic in several places. We should have a single routine that determines which alternate interfaces will be installed as part of a new config. 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
