Re: [PATCH] usbnet: fix race condition caused spinlock bad magic issue
* wangbiao biao.w...@intel.com wrote:
@@ -1448,8 +1448,10 @@ static void usbnet_bh (unsigned long param)
// waiting for all pending urbs to complete?
if (dev-wait) {
+ wait_queue_head_t *wait_d = dev-wait;
if ((dev-txq.qlen + dev-rxq.qlen + dev-done.qlen) == 0) {
- wake_up (dev-wait);
+ if (wait_d)
+ wake_up(wait_d);
}
// or are we maybe short a few urbs?
1)
Nit: the scope of 'wait_d' is unnecessarily broad, it could be moved to
the block that uses it.
2)
Also, the changelog mentions that dev-wait can race - it would be nice to
add to the changelog what exact synchronization mechanism protects
usbnet_terminate_urbs() and usbnet_bh() from seeing/modifying that value
at once - as the code was clearly written without such interaction in
mind.
@@ -1602,6 +1604,7 @@ usbnet_probe (struct usb_interface *udev, const struct
usb_device_id *prod)
init_timer (dev-delay);
mutex_init (dev-phy_mutex);
mutex_init(dev-interrupt_mutex);
+ init_waitqueue_head(unlink_wakeup);
3)
Can that runtime initialization be avoided by using
DECLARE_WAIT_QUEUE_HEAD()?
Thanks,
Ingo
--
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: phy: remove dead code
On 11/10/2013 07:37 PM, Michal Nazarewicz wrote: From: Michal Nazarewicz min...@mina86.com Thanks. This is the result of a merge. Felipe noticed this a few days back and wanted to take care of this, not sure what the exact status is. 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
Re: [PATCH] usbnet: fix race condition caused spinlock bad magic issue
On Mon, 2013-11-11 at 11:08 +0800, wangbiao wrote: From: wang, biao biao.w...@intel.com Date: Mon, 11 Nov 2013 10:23:40 +0800 Subject: [PATCH] usbnet: fix race condition caused spinlock bad magic issue there is race between usbnet_terminate_urbs and usbnet_bh, when unlink_wakeup used in usbnet_bh, it may be already freed and used by other function as unlink_wakeup was a local var on stack. Hi, the debugging is good, but the fix is not good. If you use a global variable, you can init the head only once, that is on module load, not during probe() Doing so can mess up operations with multiple modules as a hotplug happens. 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: [RFCv2 1/4] usb: gadget: epautoconf: switch over to usb_endpoint_type()
On 11/08/2013 07:39 PM, Felipe Balbi wrote: diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c index a777f7b..feaaa7b 100644 --- a/drivers/usb/gadget/epautoconf.c +++ b/drivers/usb/gadget/epautoconf.c @@ -58,7 +58,7 @@ ep_matches ( return 0; /* only support ep0 for portable CONTROL traffic */ - type = desc-bmAttributes USB_ENDPOINT_XFERTYPE_MASK; + type = usb_endpoint_type(desc); if (USB_ENDPOINT_XFER_CONTROL == type) return 0; This does not depend on anything and could go in as is. 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
Re: [RFCv2 2/4] usb: gadget: ep: add feature flags
On 11/08/2013 07:39 PM, Felipe Balbi wrote:
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 942ef5e..cf1d027 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -177,6 +183,13 @@ struct usb_ep {
u8 address;
const struct usb_endpoint_descriptor*desc;
const struct usb_ss_ep_comp_descriptor *comp_desc;
+
+ unsignedhas_bulk:1;
+ unsignedhas_control:1;
+ unsignedhas_interrupt:1;
+ unsignedhas_isochronous:1;
+ unsignedhas_dir_in:1;
+ unsignedhas_dir_out:1;
};
I am not a big fan this bitfields but this is another story.
One thing you might want to add later (because we do one thing at a
time) is that you might want to prefer one kind of an endpoint. For
instance you want hold back this-ep and not give it away for INTR
because it can do double buffer and DMA and you would like to give it
away for 512bytes BULK type of endpoints.
Another restriction is that an endpoint can do INTR, BULK, ISO but has
only a 64byte sized fifo and you would like to give it away as soon as
possible.
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
[pandaboard] OTG port not working
Since suggested by gregkh, here a CC. Greets, Tobias EDIT: Oops, I totally missed the most important bit: https://bugzilla.kernel.org/show_bug.cgi?id=64771 -- 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: huawei_cdc_ncm driver
Thomas Schäfer tschae...@t-online.de writes: The second device with problems is Huawei E3276 (Speedstick LTE III, Telekom, no Hilink, but ipv6-cabable version) This device worked before with SLAAC, now with -next-20131107 it doesn't. Ouch. I noticed after submitting this driver that it probably has some flawed logic wrt carrier detection. I wonder if this patch makes any difference (yes, just delete that line): It didn't. I will test again, from time to time linux-next. If the problem is still there while releasing RC-versions, I will cry out again. I'm afraid I cannot reproduce this problem with the NCM device I've got (Ericsson F5521gw), or with any of my MBIM devices. I am still unable to test IPv6, but IPv4 with DHCP works fine using net-next from today. I do not have any Huawei NCM device, so I cannot really test the new huawei_cdc_ncm. One isse with this driver is that it takes the status/ notification endpoint away from the cdc_ncm driver. I guess there could be some problem there. Or maybe some subtle difference introduced by my fixup series causes trouble for this device? Anyway, I am hoping you can help me pinpoint the cause, as it doesn't seem likely it will be resolved in any other way given than I am unable to reproduce the problem myself. A simple test would be just reverting commit 9fea037de5f3 (net: cdc_ncm: remove non-standard NCM device IDs), to make the cdc_ncm driver (with all the recent changes) handle this device again. If that still does not change anything, then I'd really appreciate it if you could run through (assuming the v3.11 driver was OK): git bisect start 9fea037de5f3 v3.11 -- drivers/net/usb/cdc_ncm.c This should pinpoint the exact change to cdc_ncm.c that made your device start failing, assuming it is a cdc_ncm change that is the cause... Actually it would be good to first verify that v3.11 version of cdc_ncm still works on top of net-next, eliminating any core changes: git reset v3.11 drivers/net/usb/cdc_ncm.c include/linux/usb/cdc_ncm.h git checkout drivers/net/usb/cdc_ncm.c include/linux/usb/cdc_ncm.h Run git reset --hard to get back to a clean HEAD after that test. If that didn't work, then there is no need to run the limited bisect command above. But you might consider doing a full bisect from the last working kernel version instead. This will be a few more steps, though. 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: [Pull Request] xhci: Bug fixes, now with more tags!
This Bug is still not completely solved (Ubuntu 13.10 newest kernel 3.11) Syslog: Nov 2 18:44:29 Arbeits-PC whoopsie[961]: online Nov 2 18:45:41 whoopsie[961]: last message repeated 2 times Nov 2 18:56:27 Arbeits-PC kernel: [ 8411.030685] usb 3-2: USB disconnect, device number 21 Nov 2 18:56:27 Arbeits-PC colord: device removed: sysfs-LGE-Nexus_4 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.253950] usb 3-2: new high-speed USB device number 25 using xhci_hcd Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270843] usb 3-2: New USB device found, idVendor=18d1, idProduct=4ee1 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270848] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270851] usb 3-2: Product: Nexus 4 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270854] usb 3-2: Manufacturer: LGE Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270856] usb 3-2: SerialNumber: 00294807ce91f316 Nov 2 18:56:28 Arbeits-PC colord: Device added: sysfs-LGE-Nexus_4 Nov 2 18:56:28 Arbeits-PC dbus[651]: [system] Activating service name='org.freedesktop.hostname1' (using servicehelper) Nov 2 18:56:28 Arbeits-PC dbus[651]: [system] Successfully activated service 'org.freedesktop.hostname1' Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.451541] usb 3-2: USB disconnect, device number 25 Nov 2 18:56:28 Arbeits-PC colord: device removed: sysfs-LGE-Nexus_4 Nov 2 18:56:29 Arbeits-PC kernel: [ 8413.735802] usb 3-2: new high-speed USB device number 30 using xhci_hcd Nov 2 18:56:45 Arbeits-PC kernel: [ 8418.728670] xhci_hcd :03:00.0: Timeout while waiting for address device command Nov 2 18:56:45 Arbeits-PC kernel: [ 8429.521172] [sched_delayed] sched: RT throttling activated Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: The canary thread is apparently starving. Taking action. Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Demoting known real-time threads. Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Successfully demoted thread 2186 of process 2142 (n/a). Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Successfully demoted thread 2185 of process 2142 (n/a). Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Successfully demoted thread 2184 of process 2142 (n/a). Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Successfully demoted thread 2142 of process 2142 (n/a). Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Demoted 4 threads. Nov 2 18:56:45 Arbeits-PC kernel: [ 8429.720909] usb 3-2: Device not responding to set address. Nov 2 18:56:45 Arbeits-PC kernel: [ 8429.924616] usb 3-2: device not accepting address 30, error -71 Nov 2 18:57:05 Arbeits-PC kernel: [ 8434.917500] xhci_hcd :03:00.0: Timeout while waiting for a slot Nov 2 18:57:05 Arbeits-PC kernel: [ 8449.102462] xhci_hcd :03:00.0: Stopped the command ring failed, maybe the host is dead Nov 2 18:57:05 Arbeits-PC kernel: [ 8449.102479] xhci_hcd :03:00.0: Abort command ring failed Nov 2 18:57:05 Arbeits-PC kernel: [ 8449.102677] xhci_hcd :03:00.0: HC died; cleaning up Nov 2 18:57:05 Arbeits-PC kernel: [ 8449.104659] xHCI xhci_free_dev called with unaddressed device Nov 2 18:57:10 Arbeits-PC kernel: [ 8454.094047] xhci_hcd :03:00.0: Timeout while waiting for a slot Nov 2 18:57:10 Arbeits-PC kernel: [ 8454.094051] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is dead. Nov 2 18:57:10 Arbeits-PC kernel: [ 8454.094060] xHCI xhci_free_dev called with unaddressed device Nov 2 18:57:15 Arbeits-PC kernel: [ 8459.086911] xhci_hcd :03:00.0: Timeout while waiting for a slot Nov 2 18:57:15 Arbeits-PC kernel: [ 8459.086917] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is dead. Nov 2 18:57:15 Arbeits-PC kernel: [ 8459.086930] xHCI xhci_free_dev called with unaddressed device Nov 2 18:57:15 Arbeits-PC kernel: [ 8459.086940] usb 3-1: USB disconnect, device number 2 Nov 2 18:57:15 Arbeits-PC udisksd[2260]: Cleaning up mount point /media/vincent/Elements (device 8:33 no longer exist) Nov 2 18:57:15 Arbeits-PC ntfs-3g[2477]: Unmounting /dev/sdc1 (Elements) Short system hang with looping audio after that every usb-device which is connected with this usb-controller is disconnected until i reboot the system. 2013/11/3 Vincent Thiele vincentthi...@gmail.com: This Bug is still not completely solved (Ubuntu 13.10 newest kernel 3.11) Syslog: Nov 2 18:44:29 Arbeits-PC whoopsie[961]: online Nov 2 18:45:41 whoopsie[961]: last message repeated 2 times Nov 2 18:56:27 Arbeits-PC kernel: [ 8411.030685] usb 3-2: USB disconnect, device number 21 Nov 2 18:56:27 Arbeits-PC colord: device removed: sysfs-LGE-Nexus_4 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.253950] usb 3-2: new high-speed USB device number 25 using xhci_hcd Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270843] usb 3-2: New USB device found, idVendor=18d1, idProduct=4ee1 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270848] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270851] usb 3-2: Product: Nexus 4 Nov 2 18:56:28
Re: [PATCH net-next 02/13] driver: net: remove unnecessary skb NULL check before calling dev_kfree_skb_irq
On Mon, 4 Nov 2013, David Miller wrote:
From: Govindarajulu Varadarajan govindarajul...@gmail.com
Date: Sat, 2 Nov 2013 19:17:43 +0530
@@ -1030,10 +1030,8 @@ static void ni65_xmit_intr(struct net_device *dev,int
csr0)
}
#ifdef XMT_VIA_SKB
- if(p-tmd_skb[p-tmdlast]) {
-dev_kfree_skb_irq(p-tmd_skb[p-tmdlast]);
-p-tmd_skb[p-tmdlast] = NULL;
- }
+dev_kfree_skb_irq(p-tmd_skb[p-tmdlast]);
+p-tmd_skb[p-tmdlast] = NULL;
#endif
I absolutely disagree with this kind of change.
There is a non-trivial cost for NULL'ing out that array entry
unconditionally. It's a dirtied cache line and this is in the
fast path of TX SKB reclaim of this driver.
You've made several changes of this kind.
And it sort-of shows that the places that do check for NULL,
are getting something in return for that test, namely avoidance
of an unnecessary cpu store in the fast path of the driver.
True, in case of dev_kfree_skb_irq. If you look at patch 06-12, at many
places we do
if (s-skb) {
dev_kfree_skb_any(s-skb);
s-skb = NULL)
}
This is in fast path. If the code is not running in hardirq,
dev_kfree_skb_any calls dev_kfree_skb. Which again check if skb is NULL.
So we are checking if skb is null twice. That is what this patch is
trying to fix. (sorry I should have mentioned this in cover letter).
I am not sure if you have read my previous mail. I am pasting it below.
On Sun, 3 Nov 2013, Brandeburg, Jesse wrote:
Thanks for this work, I'm a little concerned that there is a
non-trivial
overhead to this patch.
when doing (for example in the Intel drivers):
if (s-skb) {
dev_kfree_skb(s-skb);
s-skb = NULL;
}
In current code, dev_kfree_skb is NULL safe. Which means skb is
checked for NULL inside dev_kfree_skb. dev_kfree_skb_any is also NULL safe
when the code is running in non-hardirq.
Lets consider two cases
1. skb is not NULL:
* Without my patch:
In the code above, we check for skb!=NULL twice. (once
before calling dev_kfree_skb, once by dev_kfree_skb). And
then we do assignment.
* With this patch:
we check for skb!=NULL once, And then we do assignment.
To fix the twice NULL check, we either have to remove the check
which is inside dev_kfree_skb (1). Or do whats done in this
patch.
(1) is not an option because a lot of kernel code already
assumes that dev_kfree_skb is NULL safe.
2. skb is NULL:
* Without this patch:
One if statement is executed.
* With this patch:
One if statement and one assignment is executed.
From my observation most of the dev_kfree_skb calls are from
e1000_unmap_and_free_tx_resource, e1000_put_txbuf,
atl1_clean_tx_ring, alx_free_txbuf etc. in clean up functions.
Is is quite unlikely thats skb is NULL. So it comes down to one extra
if-branching statement or one extra assignment. I would prefer extra
assignment to branching statement. In my opinion extra assignment is
very little price we pay.
//govind
Another way to solve the double NULL check is to define a new function
something like this
dev_kfree_skb_NULL(struct sk_buff **skb)
{
if(*skb) {
free_skb(*skb);
*skb=NULL;
}
}
and use this if you want to free a skb and make it NULL.
Is this approach better?
//govind
--
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 RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
Hi, On Wednesday 06 November 2013 05:37 AM, Jingoo Han wrote: On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote: On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han jg1@samsung.com wrote: [.] USB3.0 PHY consists of two blocks such as 3.0 block and 2.0 block. This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0 block and 2.0 block, respectively. Conclusion: 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device Base address: 0x1213 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST 3.0 Device) Base address: 0x1210 2.0 block(UTMI+) 3.0 block(PIPE3) And this is of course the PHY used by DWC3 controller, which works at both High speed as well as Super Speed. Right ? Right. While 3.0 block(PIPE3) can be used for Super Speed, 2.0 block(UTMI+) can be used for High speed. It should then come under *single IP muliple PHY* category similar to what Sylwester has done. Thanks Kishon -- 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
[PATCHv2 2/2] check quirk to pad epout buf size when not aligned to maxpacketsize
Check gadget.quirk_ep_out_aligned_size to decide if buffer size requires
to be aligned to maxpacketsize of an out endpoint. ffs_epfile_io() needs
to pad epout buffer to match above condition if quirk is found.
Signed-off-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/f_fs.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
On 11/10/2013 08:50 AM, Michal Nazarewicz wrote:
@@ -787,6 +788,13 @@ static ssize_t ffs_epfile_io(struct file *file,
/* Allocate copy */
if (!halt) {
+/*
+ * Controller requires buffer size to be aligned to
+ * maxpacketsize of an out endpoint.
+ */
+data_len = read gadget-quirk_ep_out_aligned_size ?
+usb_ep_align_maxpacketsize(ep-ep, len) : len;
+
data = kmalloc(len, GFP_KERNEL);
On Mon, Nov 11 2013, David Cohen david.a.co...@linux.intel.com wrote:
Shouldn't this kmalloc() allocate 'data_len' bytes, instead of 'len'?
Yes, of coures.
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index e496b72..fd769a8 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -753,8 +753,9 @@ static ssize_t ffs_epfile_io(struct file *file,
char __user *buf, size_t len, int read)
{
struct ffs_epfile *epfile = file-private_data;
+ struct usb_gadget *gadget = epfile-ffs-gadget;
struct ffs_ep *ep;
- ssize_t ret;
+ ssize_t ret, data_len;
char *data;
int halt;
@@ -787,7 +788,14 @@ static ssize_t ffs_epfile_io(struct file *file,
/* Allocate copy */
if (!halt) {
- data = kmalloc(len, GFP_KERNEL);
+ /*
+* Controller requires buffer size to be aligned to
+* maxpacketsize of an out endpoint.
+*/
+ data_len = read gadget-quirk_ep_out_aligned_size ?
+ usb_ep_align_maxpacketsize(ep-ep, len) : len;
+
+ data = kmalloc(data_len, GFP_KERNEL);
if (unlikely(!data))
return -ENOMEM;
@@ -824,7 +832,7 @@ static ssize_t ffs_epfile_io(struct file *file,
req-context = done;
req-complete = ffs_epfile_io_complete;
req-buf = data;
- req-length = len;
+ req-length = data_len;
ret = usb_ep_queue(ep-ep, req, GFP_ATOMIC);
@@ -836,9 +844,16 @@ static ssize_t ffs_epfile_io(struct file *file,
ret = -EINTR;
usb_ep_dequeue(ep-ep, req);
} else {
+ /*
+* XXX We may end up silently droping data here.
+* Since data_len (i.e. req-length) may be bigger
+* than len (after being rounded up to maxpacketsize),
+* we may end up with more data then user space has
+* space for.
+*/
ret = ep-status;
if (read ret 0
- unlikely(copy_to_user(buf, data, ret)))
+ unlikely(copy_to_user(buf, data, min(ret, len
ret = -EFAULT;
}
}
--
1.8.4.1
--
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
musb: babble interrupt
Hi, On my board, my musb works as host. my kernel version is 3.4.0. The host cannot enumerate some low speed mouse normally,but if I add an extersion cord (abour 1.5m) between the host and device, the mouse can work normally. If the enumeration fails, there is always a babble interrupt happen just after the USB reset ,and the session would be stop(seems automaticly stoped by the IP core). From the sniffer, if the enumeration success, there is an EOP just after the usb reset(about 2us), but if fails, there is no EOP,then babble interrupt issued. So anyone please give me some clue to dig? -- 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: chipidea: udc: first start device on pullup
Don't pullup the resistors on hw_device_state. The gadget framework has
the prepared callback for this. This is necessary if we use gadgets
which need to be enabled after an userspace application got prepared, or
other delayed conditiions have passed.
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
---
drivers/usb/chipidea/udc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index b34c819..976153f 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -84,10 +84,8 @@ static int hw_device_state(struct ci_hdrc *ci, u32 dma)
/* interrupt, error, port change, reset, sleep/suspend */
hw_write(ci, OP_USBINTR, ~0,
USBi_UI|USBi_UEI|USBi_PCI|USBi_URI|USBi_SLI);
- hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
} else {
hw_write(ci, OP_USBINTR, ~0, 0);
- hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
}
return 0;
}
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: move gadget start to bind of each driver
We currently enable the udc on bind_to_driver. This breaks the de/activate mechanism for drivers that depent on userspace components. This patch fixes this by moving the pullup call to each bind. Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de --- drivers/usb/gadget/f_acm.c | 3 +++ drivers/usb/gadget/f_ecm.c | 3 +++ drivers/usb/gadget/f_eem.c | 3 +++ drivers/usb/gadget/f_fs.c | 5 + drivers/usb/gadget/f_hid.c | 2 ++ drivers/usb/gadget/f_loopback.c | 3 +++ drivers/usb/gadget/f_mass_storage.c | 2 ++ drivers/usb/gadget/f_midi.c | 2 ++ drivers/usb/gadget/f_ncm.c | 3 +++ drivers/usb/gadget/f_phonet.c | 3 +++ drivers/usb/gadget/f_rndis.c| 3 +++ drivers/usb/gadget/f_serial.c | 3 +++ drivers/usb/gadget/f_sourcesink.c | 3 +++ drivers/usb/gadget/f_subset.c | 3 +++ drivers/usb/gadget/f_uac1.c | 3 +++ drivers/usb/gadget/f_uac2.c | 3 +++ drivers/usb/gadget/g_ffs.c | 6 +- drivers/usb/gadget/inode.c | 2 ++ drivers/usb/gadget/udc-core.c | 1 - 19 files changed, 54 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/f_acm.c b/drivers/usb/gadget/f_acm.c index ab1065a..045176f 100644 --- a/drivers/usb/gadget/f_acm.c +++ b/drivers/usb/gadget/f_acm.c @@ -697,6 +697,9 @@ acm_bind(struct usb_configuration *c, struct usb_function *f) gadget_is_dualspeed(c-cdev-gadget) ? dual : full, acm-port.in-name, acm-port.out-name, acm-notify-name); + + usb_gadget_connect(cdev-gadget); + return 0; fail: diff --git a/drivers/usb/gadget/f_ecm.c b/drivers/usb/gadget/f_ecm.c index 8d9e6f7..58cb39a 100644 --- a/drivers/usb/gadget/f_ecm.c +++ b/drivers/usb/gadget/f_ecm.c @@ -813,6 +813,9 @@ ecm_bind(struct usb_configuration *c, struct usb_function *f) gadget_is_dualspeed(c-cdev-gadget) ? dual : full, ecm-port.in_ep-name, ecm-port.out_ep-name, ecm-notify-name); + + usb_gadget_connect(cdev-gadget); + return 0; fail: diff --git a/drivers/usb/gadget/f_eem.c b/drivers/usb/gadget/f_eem.c index d61c11d..94cf705 100644 --- a/drivers/usb/gadget/f_eem.c +++ b/drivers/usb/gadget/f_eem.c @@ -322,6 +322,9 @@ static int eem_bind(struct usb_configuration *c, struct usb_function *f) gadget_is_superspeed(c-cdev-gadget) ? super : gadget_is_dualspeed(c-cdev-gadget) ? dual : full, eem-port.in_ep-name, eem-port.out_ep-name); + + usb_gadget_connect(cdev-gadget); + return 0; fail: diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c index 44cf775..a6349ee 100644 --- a/drivers/usb/gadget/f_fs.c +++ b/drivers/usb/gadget/f_fs.c @@ -1496,6 +1496,11 @@ static int functionfs_bind_config(struct usb_composite_dev *cdev, if (unlikely(ret)) ffs_func_free(func); + /* Avoid letting this gadget enumerate until the userspace server is +* active. +*/ + ret = usb_function_deactivate(func-function); + return ret; } diff --git a/drivers/usb/gadget/f_hid.c b/drivers/usb/gadget/f_hid.c index 6e69a8e..03cfa3ee 100644 --- a/drivers/usb/gadget/f_hid.c +++ b/drivers/usb/gadget/f_hid.c @@ -633,6 +633,8 @@ static int __init hidg_bind(struct usb_configuration *c, struct usb_function *f) device_create(hidg_class, NULL, dev, NULL, %s%d, hidg, hidg-minor); + usb_gadget_connect(c-cdev-gadget); + return 0; fail: diff --git a/drivers/usb/gadget/f_loopback.c b/drivers/usb/gadget/f_loopback.c index 4a3873a..08ff937 100644 --- a/drivers/usb/gadget/f_loopback.c +++ b/drivers/usb/gadget/f_loopback.c @@ -225,6 +225,9 @@ autoconf_fail: (gadget_is_superspeed(c-cdev-gadget) ? super : (gadget_is_dualspeed(c-cdev-gadget) ? dual : full)), f-name, loop-in_ep-name, loop-out_ep-name); + + usb_gadget_connect(cdev-gadget); + return 0; } diff --git a/drivers/usb/gadget/f_mass_storage.c b/drivers/usb/gadget/f_mass_storage.c index a03ba2c..20458bd 100644 --- a/drivers/usb/gadget/f_mass_storage.c +++ b/drivers/usb/gadget/f_mass_storage.c @@ -3161,6 +3161,8 @@ static int fsg_bind(struct usb_configuration *c, struct usb_function *f) if (ret) goto autoconf_fail; + usb_gadget_connect(gadget); + return 0; autoconf_fail: diff --git a/drivers/usb/gadget/f_midi.c b/drivers/usb/gadget/f_midi.c index 263e721..8589717 100644 --- a/drivers/usb/gadget/f_midi.c +++ b/drivers/usb/gadget/f_midi.c @@ -895,6 +895,8 @@ f_midi_bind(struct usb_configuration *c, struct usb_function *f) kfree(midi_function); + usb_gadget_connect(cdev-gadget); + return 0; fail_f_midi: diff --git a/drivers/usb/gadget/f_ncm.c b/drivers/usb/gadget/f_ncm.c index
[PATCH v2] usb: xhci: Link TRB must not occur within a USB payload burst
Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
can only occur at a boundary between underlying USB frames (512 bytes for 480M).
If this isn't done the USB frames aren't formatted correctly and, for example,
the USB3 ethernet ax88179_178a card will stop sending (while still receiving)
when running a netperf tcp transmit test with (say) and 8k buffer.
This should be a candidate for stable, the ax88179_178a driver defaults to
gso and tso enabled so it passes a lot of fragmented skb to the USB stack.
Signed-off-by: David Laight david.lai...@aculab.com
---
Changes for v2:
1) Only act on bulk endpoints.
While isoc endpoints could suffer from the same problem it is much less
likely and can't be fixed by adding NOP TRBs (they would stop data being
sent in the poll interval).
2) When writing the NOP TRB use the count of TRBs instead of scanning for
the link TRB.
drivers/usb/host/xhci-ring.c | 53 ++--
1 file changed, 51 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 5480215..c1342dc 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2927,8 +2927,57 @@ static int prepare_ring(struct xhci_hcd *xhci, struct
xhci_ring *ep_ring,
}
while (1) {
- if (room_on_ring(xhci, ep_ring, num_trbs))
- break;
+ if (room_on_ring(xhci, ep_ring, num_trbs)) {
+ union xhci_trb *trb = ep_ring-enqueue;
+ unsigned int usable = ep_ring-enq_seg-trbs +
+ TRBS_PER_SEGMENT - 1 - trb;
+ u32 nop_cmd;
+
+ /*
+* Section 4.11.7.1 TD Fragments states that a link
+* TRB must only occur at the boundary between
+* data bursts (eg 512 bytes for 480M).
+* While it is possible to split a large fragment
+* we don't know the size yet.
+* Simplest solution is to fill the trb before the
+* LINK with nop commands.
+*/
+ if (num_trbs == 1 || num_trbs = usable || usable == 0)
+ break;
+
+ if (ep_ring-type != TYPE_BULK)
+ /*
+* While isoc transfers might have a buffer that
+* crosses a 64k boundary it is unlikely.
+* Since we can't add NOPs without generating
+* gaps in the traffic just hope it never
+* happens at the end of the ring.
+* This could be fixed by writing a LINK TRB
+* instead of the first NOP - however the
+* TRB_TYPE_LINK_LE32() calls would all need
+* changing to check the ring length. */
+ break;
+
+ if (num_trbs = TRBS_PER_SEGMENT) {
+ xhci_err(xhci, Too many fragments %d, max
%d\n,
+ num_trbs, TRBS_PER_SEGMENT - 1);
+ return -ENOMEM;
+ }
+
+ nop_cmd = cpu_to_le32(TRB_TYPE(TRB_TR_NOOP) |
+ ep_ring-cycle_state);
+ ep_ring-num_trbs_free -= usable;
+ do {
+ trb-generic.field[0] = 0;
+ trb-generic.field[1] = 0;
+ trb-generic.field[2] = 0;
+ trb-generic.field[3] = nop_cmd;
+ trb++;
+ } while (--usable);
+ ep_ring-enqueue = trb;
+ if (room_on_ring(xhci, ep_ring, num_trbs))
+ break;
+ }
if (ep_ring == xhci-cmd_ring) {
xhci_err(xhci, Do not support expand command ring\n);
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
On 11/08/2013 04:44 AM, Bjørn Mork wrote: I believe it's nice to document the layout of complex composite devices if known, but if not then I don't see any need to delay a patch like this. From looking at the .inf files from the windows drivers i can't get much info other than: %QcomDevice00% = QportInstall00, USB\VID_12d1PID_1C0B (which is the PID before usb_modeswitch/modem mode kicks in). If there's another to lookup way feel free to prod me :) Regards. -- 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: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
On 11/09/2013 10:47 AM, Johan Hovold wrote:
Ok. Thanks.
Gustavo, could you fix up the commit message (the subject line) and
resend so we can apply this?
Sure, but it was already handled by {
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0xff, 0xff) }
which caused issues without the blacklist (card reader for intf1 maybe?).
I'll ammend the define to focus on the E173s-6 (and probably not other
E173s-*) because according to usb_modeswitch data the E173S's can end up
in PIDs 1c05, 1c07, 1c08 and 1c10 which likely means there are other
variants out there.
Regards.
--
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: xhci: Improve tracing of error events
Even when compiled with USB_DEBUG the diagnostic traces don't contain
any values that help diagnose any errors.
Trace all the fields from error events.
Include the unknown address when the DMA pointer from an event isn't part
of the current TD. This will happen if the error code is TRB error.
Signed-off-by: David Laight david.lai...@aculab.com
---
drivers/usb/host/xhci-ring.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index c1342dc..ace586c 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2520,6 +2520,11 @@ static int handle_data_event(struct xhci_hcd *xhci,
goto cleanup;
}
+ if (status status != -EINPROGRESS)
+ xhci_dbg(xhci, event status %d, buffer %llx, len %x, flags
%x\n,
+ status, event-buffer, event-transfer_len,
+ event-flags);
+
do {
/* This TRB should be in the TD at the head of this ring's
* TD list.
@@ -2593,9 +2598,8 @@ static int handle_data_event(struct xhci_hcd *xhci,
goto cleanup;
}
/* HC is busted, give up! */
- xhci_err(xhci,
- ERROR Transfer event TRB DMA ptr not
- part of current TD\n);
+ xhci_err(xhci, ERROR Transfer event TRB DMA
ptr %lld not part of current TD\n,
+ event-buffer);
return -ESHUTDOWN;
}
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3] USB: serial: option: add support for Huawei E173s-6
Interface 1 on this device isn't for option to bind to otherwise an oops
on usb_wwan with log flooding will happen when accessing the port:
tty_release: ttyUSB1: read/write wait queue active!
It doesn't seem to respond to QMI if it's added to qmi_wwan so don't add
it there - it's likely used by the card reader.
Signed-off-by: Gustavo Zacarias gust...@zacarias.com.ar
---
drivers/usb/serial/option.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index acaee06..04f65a0 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -81,6 +81,7 @@ static void option_instat_callback(struct urb *urb);
#define HUAWEI_VENDOR_ID 0x12D1
#define HUAWEI_PRODUCT_E1730x140C
+#define HUAWEI_PRODUCT_E173S6 0x1C07
#define HUAWEI_PRODUCT_E1750 0x1406
#define HUAWEI_PRODUCT_K4505 0x1464
#define HUAWEI_PRODUCT_K3765 0x1465
@@ -572,6 +573,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1c23,
USB_CLASS_COMM, 0x02, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E173,
0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t) net_intf1_blacklist },
+ { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID,
HUAWEI_PRODUCT_E173S6, 0xff, 0xff, 0xff),
+ .driver_info = (kernel_ulong_t) net_intf1_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1750,
0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t) net_intf2_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1441,
USB_CLASS_COMM, 0x02, 0xff) },
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [pandaboard] OTG port not working
Hi, On Monday 11 November 2013 03:04 PM, Tobias Jakobi wrote: Since suggested by gregkh, here a CC. CONFIG_OMAP_OCP2SCP should also be enabled. Thanks Kishon Greets, Tobias EDIT: Oops, I totally missed the most important bit: https://bugzilla.kernel.org/show_bug.cgi?id=64771 -- 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
[PATCHv4] USB: serial: option: add support for Huawei E173s-6
Interface 1 on this device isn't for option to bind to otherwise an oops
on usb_wwan with log flooding will happen when accessing the port:
tty_release: ttyUSB1: read/write wait queue active!
It doesn't seem to respond to QMI if it's added to qmi_wwan so don't add
it there - it's likely used by the card reader.
Signed-off-by: Gustavo Zacarias gust...@zacarias.com.ar
---
v4:
- Unbreak v2 ID sort broken in v3
v3:
- Focus define name on E173s -6 variant, there are others
- Change msg to E173-s6 add suggested by Johan Hovold
v2:
- Sort define by id as pointed by Sergei Shtylyov
drivers/usb/serial/option.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index acaee06..98a4a1c 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -85,6 +85,7 @@ static void option_instat_callback(struct urb *urb);
#define HUAWEI_PRODUCT_K4505 0x1464
#define HUAWEI_PRODUCT_K3765 0x1465
#define HUAWEI_PRODUCT_K4605 0x14C6
+#define HUAWEI_PRODUCT_E173S6 0x1C07
#define QUANTA_VENDOR_ID 0x0408
#define QUANTA_PRODUCT_Q1010xEA02
@@ -572,6 +573,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1c23,
USB_CLASS_COMM, 0x02, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E173,
0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t) net_intf1_blacklist },
+ { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID,
HUAWEI_PRODUCT_E173S6, 0xff, 0xff, 0xff),
+ .driver_info = (kernel_ulong_t) net_intf1_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1750,
0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t) net_intf2_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1441,
USB_CLASS_COMM, 0x02, 0xff) },
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: xhci: Add support for URB_ZERO_PACKET
If URB_ZERO_PACKET is set on a transfer that is an integral number
of maximum length packets (1k for USB3 bulk) then an additional
zero length fragment must be sent.
Merge together the functions that setup single buffer and scatter-gather
transfers (they aren't that different) simplifying the logic as well.
In particular we note that the number of TRB passed to prepare_ring()
need only be an upper limit on the number required. However we do try
to only request 1 TRB when we know one is sufficient.
Signed-off-by: David Laight david.lai...@aculab.com
---
This patch is basically a rewrite of xhci_queue_bilk_tx(), the diff
is synchronised rather badly so I've copied the new version below.
If you try to test it, you'll need the patch that stops TDs containing
LINK TRBs - otherwise it all goes horribly wrong.
int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
struct urb *urb, int slot_id, unsigned int ep_index)
{
struct xhci_ring *ep_ring;
unsigned int num_trbs;
struct urb_priv *urb_priv;
u32 trb_buff_len, this_sg_len;
struct scatterlist *sg;
u32 trb_type_flags;
u32 max_packet, td_residue, len_left;
u32 td_size;
u64 addr;
int ret;
ep_ring = xhci_urb_to_transfer_ring(xhci, urb);
if (unlikely(!ep_ring))
return -EINVAL;
if (urb-num_sgs == 0) {
sg = NULL;
addr = (u64)urb-transfer_dma;
this_sg_len = urb-transfer_buffer_length;
num_trbs = 0;
} else {
sg = urb-sg;
addr = (u64)sg_dma_address(sg);
this_sg_len = sg_dma_len(sg);
/*
* We only need an upper bound for the number of TRBs.
* Add in two extra TRB for each subsequent segment.
*/
num_trbs = (urb-num_mapped_sgs - 1) * 2;
}
/* One TRB for each 64k 'page' that contains data */
num_trbs += DIV_ROUND_UP((addr (TRB_MAX_BUFF_SIZE - 1)) +
urb-transfer_buffer_length, TRB_MAX_BUFF_SIZE);
max_packet = GET_MAX_PACKET(usb_endpoint_maxp(urb-ep-desc));
/*
* For v 1.0 we need to calculate the number of TD needed to
* complete the transfer.
* The code here is equivalent to 4.11.2.4.
*/
td_residue = urb-transfer_buffer_length;
if (unlikely(urb-transfer_flags URB_ZERO_PACKET)) {
/* We need an extra zero length TD */
num_trbs++;
td_residue++;
}
td_residue = ALIGN(td_residue, max_packet) + max_packet - 1;
ret = prepare_transfer(xhci, xhci-devs[slot_id],
ep_index, urb-stream_id,
num_trbs, urb, 0, mem_flags);
if (unlikely(ret 0))
return ret;
trb_type_flags = TRB_CYCLE | TRB_CHAIN | TRB_TYPE(TRB_NORMAL);
/* Set interrupt on short packet for IN endpoints */
if (usb_urb_dir_in(urb))
trb_type_flags |= TRB_ISP;
/* Queue the first TRB, even if it's zero-length */
len_left = urb-transfer_buffer_length;
for (;;) {
/*
* How much data is in the TRB?
*
* 1. TRBs buffers can't cross 64KB boundaries.
* 2. We don't want to walk off the end of this sg-list buffer.
* 2. Don't exceed the driver-supplied transfer length.
*(May be smaller than the sg list.)
*/
trb_buff_len = (~addr (TRB_MAX_BUFF_SIZE - 1)) + 1;
trb_buff_len = min_t(u32, trb_buff_len, this_sg_len);
trb_buff_len = min_t(u32, trb_buff_len, len_left);
td_residue -= trb_buff_len;
/* TRB_CYCLE is inverted in the first TRB */
trb_type_flags ^= ep_ring-cycle_state;
/*
* Chain all the TRBs together; clear the chain bit in the last
* TRB to indicate it's the last TRB in the chain.
* The td_residue can only be 2 * max_packet - 1 if
* URB_ZERO_PACKET was set, this forces a zero length packet.
* For version 1.0 we could send the last fragment with
* td_size set to 1 - but that is just extra logic.
*/
if (trb_buff_len == len_left (trb_buff_len == 0 ||
td_residue 2 * max_packet - 1)) {
/* The last buffer fragment */
urb_priv = urb-hcpriv;
urb_priv-td[0].last_trb = ep_ring-enqueue;
/* Set TRB_IOC and clear TRB_CHAIN */
trb_type_flags ^= TRB_IOC | TRB_CHAIN;
td_size = 0;
} else {
Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
Gustavo Zacarias gust...@zacarias.com.ar writes: On 11/08/2013 04:44 AM, Bjørn Mork wrote: I believe it's nice to document the layout of complex composite devices if known, but if not then I don't see any need to delay a patch like this. From looking at the .inf files from the windows drivers i can't get much info other than: %QcomDevice00% = QportInstall00, USB\VID_12d1PID_1C0B (which is the PID before usb_modeswitch/modem mode kicks in). If there's another to lookup way feel free to prod me :) One way, if you have access to a Windows system, is observing what happens there. You can look up vid/pid/intfnumber in the Windows device manager. Looking around at various driver files I had here, I found this: bjorn@nemi:/tmp/foo/Huawei$ egrep '1C(05|07|08|10)' *.inf|sort |uniq ew_jubusenum.inf:%EnumDeviceDesc% = DevInstallNet, USB\VID_12D1PID_1C07MI_01 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C05MI_00 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C05MI_01 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C05MI_02 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C07MI_00 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C07MI_02 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C07MI_03 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C07MI_06 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C08MI_00 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C08MI_01 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C10MI_00 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C10MI_01 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C10MI_02 ew_jucdcacm.inf:%BTDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C07MI_06 ew_jucdcacm.inf:%DIAGDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C05MI_01 ew_jucdcacm.inf:%DIAGDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C07MI_02 ew_jucdcacm.inf:%DIAGDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C10MI_01 ew_jucdcacm.inf:%PCUIDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C05MI_02 ew_jucdcacm.inf:%PCUIDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C07MI_03 ew_jucdcacm.inf:%PCUIDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C08MI_01 ew_jucdcacm.inf:%PCUIDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C10MI_02 ew_jucdcecm.inf:%ECMDeviceDesc% = ew_jucdcecm.ndi, USBCDCECM\VID_12D1PID_1C07MI_01 ew_jucdcecm.inf:%NCMDeviceDesc% = ew_jucdcncm.ndi, USBCDCNCM\VID_12D1PID_1C07MI_01 ew_jucdcmdm.inf:%MDMDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C05MI_00 ew_jucdcmdm.inf:%MDMDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C07MI_00 ew_jucdcmdm.inf:%MDMDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C08MI_00 ew_jucdcmdm.inf:%MDMDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C10MI_00 ew_juextctrl.inf:%dc_ecm_dev.DevDesc% = DevInstall, USBCDCECM\VID_12D1PID_1C07MI_01ext_ctrl So according to thos, interface #1 on 12d1:1c07 should be either an ECM or(?) NCM function, so blacklisting it in option is definitely correct if the generic Huawei vendor rule picks it up. Now I do not understand how the same function can be both ECM and NCM, but we should try to find out which one it is... The Huawei Windows driver use a single flag to select one of these, which may explain how they can mix configs like this. It just seems completely pointless. You have already tried qmi_wwan, right? But only with libqmi? This is most likely not a QMI device in any case. There is a fair chance that it supports Huawei's AT^NDISDUP and related vendor specific AT commands though. You should try that, using either qmi_wwan (if ECM) or the new huawei_cdc_ncm driver (if NCM) for the network function. This device use ff/ff/ff for class/subclass/protocol on all interfaces, is that right? 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
[PATCH 1/4] usb: chipidea: msm: Add device tree binding information
From: Ivan T. Ivanov iiva...@mm-sol.com
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/usb/msm-hsusb.txt | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
index 5ea26c6..0a85eba 100644
--- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
+++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
@@ -15,3 +15,19 @@ Example EHCI controller device node:
usb-phy = usb_otg;
};
+CI13xxx (Chipidea) USB controllers
+
+Required properties:
+- compatible: should contain qcom,ci-hdrc
+- reg: offset and length of the register set in the
memory map
+- interrupts: interrupt-specifier for the controller interrupt.
+- usb-phy: phandle for the PHY device
+- dr_mode: Sould be peripheral
+
+ gadget@f9a55000 {
+ compatible = qcom,ci-hdrc;
+ reg = 0xf9a55000 0x400;
+ dr_mode = peripheral;
+ interrupts = 0 134 0;
+ usb-phy = usb_otg;
+ };
\ No newline at end of file
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] usb: chipidea: msm: Clean and fix glue layer driver
From: Ivan T. Ivanov iiva...@mm-sol.com Hi, This series intend to fixup driver, which was broken for a while. It is used to create peripheral role device, which in coordination with phy-usb-msm driver (still some cleanups pending) will provide again USB2.0 gadget support for MSM targets. Generated on to top of usb-3.13-rc1. Regards, Ivan Ivan T. Ivanov (4): usb: chipidea: msm: Add device tree binding information usb: chipidea: msm: Add device tree support usb: chipidea: msm: Initialize offset of the capability registers usb: chipidea: msm: Use USB PHY API to control PHY state .../devicetree/bindings/usb/msm-hsusb.txt | 16 ++ drivers/usb/chipidea/ci_hdrc_msm.c | 33 +++- 2 files changed, 41 insertions(+), 8 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] usb: chipidea: msm: Initialize offset of the capability registers
From: Ivan T. Ivanov iiva...@mm-sol.com
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
drivers/usb/chipidea/ci_hdrc_msm.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
b/drivers/usb/chipidea/ci_hdrc_msm.c
index 747d6c1..e9624f3 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -47,6 +47,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci,
unsigned event)
static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = {
.name = ci_hdrc_msm,
+ .capoffset = DEF_CAPOFFSET,
.flags = CI_HDRC_REGS_SHARED |
CI_HDRC_REQUIRE_TRANSCEIVER |
CI_HDRC_DISABLE_STREAMING,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] usb: chipidea: msm: Add device tree support
From: Ivan T. Ivanov iiva...@mm-sol.com
Allows controller to be specified via device tree.
Pass PHY phandle specified in DT to core driver.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
Cc: devicet...@vger.kernel.org
---
drivers/usb/chipidea/ci_hdrc_msm.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
b/drivers/usb/chipidea/ci_hdrc_msm.c
index 2d51d85..747d6c1 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -57,9 +57,21 @@ static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = {
static int ci_hdrc_msm_probe(struct platform_device *pdev)
{
struct platform_device *plat_ci;
+ struct usb_phy *phy;
dev_dbg(pdev-dev, ci_hdrc_msm_probe\n);
+ /*
+* OTG(PHY) driver takes care of PHY initialization, clock management,
+* powering up VBUS, mapping of registers address space and power
+* management.
+*/
+ phy = devm_usb_get_phy_by_phandle(pdev-dev, usb-phy, 0);
+ if (IS_ERR(phy))
+ return PTR_ERR(phy);
+ else
+ ci_hdrc_msm_platdata.phy = phy;
+
plat_ci = ci_hdrc_add_device(pdev-dev,
pdev-resource, pdev-num_resources,
ci_hdrc_msm_platdata);
@@ -86,10 +98,19 @@ static int ci_hdrc_msm_remove(struct platform_device *pdev)
return 0;
}
+static struct of_device_id msm_ci_dt_match[] = {
+ { .compatible = qcom,ci-hdrc, },
+ { }
+};
+MODULE_DEVICE_TABLE(of, msm_ci_dt_match);
+
static struct platform_driver ci_hdrc_msm_driver = {
.probe = ci_hdrc_msm_probe,
.remove = ci_hdrc_msm_remove,
- .driver = { .name = msm_hsusb, },
+ .driver = {
+ .name = msm_hsusb,
+ .of_match_table = msm_ci_dt_match,
+ },
};
module_platform_driver(ci_hdrc_msm_driver);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] usb: chipidea: msm: Use USB PHY API to control PHY state
From: Ivan T. Ivanov iiva...@mm-sol.com
PHY drivers keep track of the current state of the hardware,
so don't change PHY settings under it.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
drivers/usb/chipidea/ci_hdrc_msm.c |9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
b/drivers/usb/chipidea/ci_hdrc_msm.c
index e9624f3..338b209 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -20,13 +20,11 @@
static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
{
struct device *dev = ci-gadget.dev.parent;
- int val;
switch (event) {
case CI_HDRC_CONTROLLER_RESET_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_RESET_EVENT received\n);
- writel(0, USB_AHBBURST);
- writel(0, USB_AHBMODE);
+ usb_phy_init(ci-transceiver);
break;
case CI_HDRC_CONTROLLER_STOPPED_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_STOPPED_EVENT received\n);
@@ -34,10 +32,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci,
unsigned event)
* Put the transceiver in non-driving mode. Otherwise host
* may not detect soft-disconnection.
*/
- val = usb_phy_io_read(ci-transceiver, ULPI_FUNC_CTRL);
- val = ~ULPI_FUNC_CTRL_OPMODE_MASK;
- val |= ULPI_FUNC_CTRL_OPMODE_NONDRIVING;
- usb_phy_io_write(ci-transceiver, val, ULPI_FUNC_CTRL);
+ usb_phy_notify_disconnect(ci-transceiver, USB_SPEED_UNKNOWN);
break;
default:
dev_dbg(dev, unknown ci_hdrc event\n);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
USB-3.0 suspend/resume issues
Hi All, While reviewing and testing patches for my latest uas patch series, I realized that uas did not have suspend / resume support. Which is not good for a storage driver, since that means a disconnect and reconnect will happen over suspend resume, causing any mounted filesystems on the disk to be unusable until re-mounted. Implementing suspend / resume was not that hard, testing it is another story. I ended up testing USB-3 superspeed device suspend / resume support in general. Below is a report with my findings. I've tested using 4 (*) host configurations: 1.1) My desktop machine with a pci-e add-on card with a nec xhci controller. The firmware completely turns of the power to the pci-e card, triggering the xhci reset-resume paths. With devices plugged directly a root-hub port. 1.2) Same desktop machine with devices plugged into a build-in via vl811 usb-3 hub. Note the hub also looses all power during suspend/resume. 2.1) My dell latitude e6430 laptop, with intel series 7 chipset (pantherpoint) build-in xhci controller, with devices plugged into its regular usb-3 port The xhci controller stays powered during suspend / resume, so the xhci suspend / resume code uses the regular resume path. but the port gets Vbus turned off during suspend, and restored on resume causing attached devices to enter the reset-resume path. 2.2) Same laptop, with devices plugged into the power-sharing usb-3 port, which gets Vbus turned off for a second, then turned back again during suspend. And it gets worse, after resume, while the kernel is already running and is resuming devices, the embedded controller controlling the ports toggles the power off for about .5 seconds and back on again. This Vbus toggle may happen before or after the kernel has resumed the device. If it happens after the kernel has resumed the device, but before khubd gets to run, khubd may not see the disconnect / re-connect, even though the device has lost state! I've tested with 3 devices: 1) usb-2 stick: Brandless, the ones with the flasing lights handed out at plumbers in portland 2) usb-3 stick: Corsair Flash Voyager 16 GB 3) usb-3 uas capable sata dock: Plugable USB3-SATA-UASP1 in uas mode (**) And the results: nec xhci + usb-2 stick on root hub port: reset-resume of xhci + stick: success nec xhci + usb-2 stick on vl811 hub port: reset-resume of xhci + hub + stick: success intel xhci + usb-2 stick on regular usb-3 port: resume of xhci + reset-resume of stick: success intel xhci + usb-2 stick on power-sharing usb-3 port: resume of xhci success stick gets seen as disconnected and the stick needs to be unplugged and replugged for it to be seen again nec xhci + usb-3 stick on root hub port: reset-resume of xhci + stick: success nec xhci + usb-3 stick on vl811 hub port: reset-resume of xhci + hub + stick: success intel xhci + usb-3 stick on regular usb-3 port: resume of xhci: success stick seen as disconnected, shows up again without intervention after circa 1 second intel xhci + usb-3 stick on power-sharing usb-3 port: resume of xhci: success stick seen as disconnected, shows up again without intervention after circa 2 seconds nec xhci + uas dev on root hub port: reset-resume of xhci: success uas dev seen as disconnected, shows up again without intervention after several seconds nec xhci + uas dev on vl811 hub port: reset-resume of xhci + hub: success uas dev seen as disconnected, shows up again without intervention after several seconds intel xhci + uas dev on regular usb-3 port: resume of xhci and reset-resume of uas: success intel xhci + uas dev on power-sharing usb-3 port: resume of xhci: success device seen as disconnected, shows up again without intervention after circa 2 seconds Conclusions: 1) The power-sharing port on the Dell E6430 is a typical example of how broken firmware can be, due to its Vbus toggling after resume it fails to properly suspend / resume any devices. If users care about usb device persistence over suspend / resume for devices plugged into that port they should disable the power sharing feature in the BIOS (which will disable the broken Vbus toggling) 2) Where as USB-2 device don't seem to care much about Vbus being turned on/off during resume, USB-3 (operating at USB-3 speeds) devices do care about this, and depending on (root)-hub and device combination they may or may not suffer a disconnect / reconnect over suspend / resume. I've tried various things to make the disconnect / reconnect go away, but nothing short of inserting unacceptable long sleeps seems to help :| It seems we will need to educate BIOS authors that USB-3 has excellent powermanagement in the spec and that USB-3 ports should not be powered off during suspend. Regards, Hans p.s. I've also ran some tests with the uas device on the intel xhci with the XHCI_RESET_ON_RESUME quirk set to test that code path with streams, and I promptly found a bug there. I've a patch fixing this which will be part
Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
On Mon, Nov 11, 2013 at 06:47:52AM -0300, Gustavo Zacarias wrote:
On 11/09/2013 10:47 AM, Johan Hovold wrote:
Ok. Thanks.
Gustavo, could you fix up the commit message (the subject line) and
resend so we can apply this?
Sure, but it was already handled by {
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0xff, 0xff) }
which caused issues without the blacklist (card reader for intf1 maybe?).
Ah, my bad. Then your original commit message was perfectly adequate. :)
Johan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: chipidea: udc: first start device on pullup
On Mon, Nov 11, 2013 at 12:39:30PM +0100, Michael Grzeschik wrote:
Don't pullup the resistors on hw_device_state. The gadget framework has
the prepared callback for this. This is necessary if we use gadgets
which need to be enabled after an userspace application got prepared, or
other delayed conditiions have passed.
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
---
drivers/usb/chipidea/udc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index b34c819..976153f 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -84,10 +84,8 @@ static int hw_device_state(struct ci_hdrc *ci, u32 dma)
/* interrupt, error, port change, reset, sleep/suspend */
hw_write(ci, OP_USBINTR, ~0,
USBi_UI|USBi_UEI|USBi_PCI|USBi_URI|USBi_SLI);
- hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
} else {
hw_write(ci, OP_USBINTR, ~0, 0);
- hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
}
return 0;
}
Hi Michael, you submitted a similar patch before to fix uvc problem,
but you can't simply delete it, it will cause the udc can't work
if we load gadget first, then plug in the usb cable.
To fix it, it is better mark that gadget as defer_connect, and
introduce such condition at udc driver.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] usb: chipidea: msm: Use USB PHY API to control PHY state
On Mon, Nov 11, 2013 at 03:35:37PM +0200, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
PHY drivers keep track of the current state of the hardware,
so don't change PHY settings under it.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
drivers/usb/chipidea/ci_hdrc_msm.c |9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
b/drivers/usb/chipidea/ci_hdrc_msm.c
index e9624f3..338b209 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -20,13 +20,11 @@
static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
{
struct device *dev = ci-gadget.dev.parent;
- int val;
switch (event) {
case CI_HDRC_CONTROLLER_RESET_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_RESET_EVENT received\n);
- writel(0, USB_AHBBURST);
- writel(0, USB_AHBMODE);
+ usb_phy_init(ci-transceiver);
It will reset the PHY, but your comment is don't change PHY settings under it
break;
case CI_HDRC_CONTROLLER_STOPPED_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_STOPPED_EVENT received\n);
@@ -34,10 +32,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci,
unsigned event)
* Put the transceiver in non-driving mode. Otherwise host
* may not detect soft-disconnection.
*/
- val = usb_phy_io_read(ci-transceiver, ULPI_FUNC_CTRL);
- val = ~ULPI_FUNC_CTRL_OPMODE_MASK;
- val |= ULPI_FUNC_CTRL_OPMODE_NONDRIVING;
- usb_phy_io_write(ci-transceiver, val, ULPI_FUNC_CTRL);
+ usb_phy_notify_disconnect(ci-transceiver, USB_SPEED_UNKNOWN);
Where you have implemented .notify_disconnect?
I have not found it at your phy driver.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] usb: chipidea: msm: Clean and fix glue layer driver
On Mon, Nov 11, 2013 at 03:35:33PM +0200, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com Hi, This series intend to fixup driver, which was broken for a while. It is used to create peripheral role device, which in coordination with phy-usb-msm driver (still some cleanups pending) will provide again USB2.0 gadget support for MSM targets. We haven't seen msm chipidea patch for a long time, good news they appear. Any plans to use the whole chipidea function for msm controller driver (otg, host and peripheral)? -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] USBNET: fix handling padding packet
As my below test on ax99179_178a, I believe the patch should fix padding for dma sg, but need a little update, and I will send out v1 later: $ping -s 974 another_machine #from host with ax99179_178a attached If FLAG_SEND_ZLP is set for ax99179_178a, the above ping won't work any more either on USB3.0 or USB 2.0 host controller. So don't assume that these brand new devices can support ZLP well. I've just posted a fix to the xhci driver to implement URB_ZERO_PACKET. With that fix (and ZLP enabled in the ax88179_178a driver) the above ping works fine (ax88179 Ge card on USB3). I wonder how many other usb drivers fail to support URB_ZERO_PACKET. Maybe the driver should pass a flag to its users (along with SG support). I've also posted (to linux-usb) another fix to the xhci driver that is needed to get SG (and one that cross 64k boundaries) transfers working. David -- 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: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
On 11/11/2013 10:41 AM, Bjørn Mork wrote: One way, if you have access to a Windows system, is observing what happens there. You can look up vid/pid/intfnumber in the Windows device manager. From windows i've got: 3G Modem - usbcdcacm\VID_12D1PID_1C07MI_00 HUAWEI Mobile Connect Network Interface - usbcdcecm\VID_12D1PID_1C07MI_01wwan 3G Application - usbcdcacm\VID_12D1PID_1C07MI_02 3G PC UI - usbcdcacm\VID_12D1PID_1C07MI_03 So it seems to be ECM. So according to thos, interface #1 on 12d1:1c07 should be either an ECM or(?) NCM function, so blacklisting it in option is definitely correct if the generic Huawei vendor rule picks it up. Now I do not understand how the same function can be both ECM and NCM, but we should try to find out which one it is... The Huawei Windows driver use a single flag to select one of these, which may explain how they can mix configs like this. It just seems completely pointless. You have already tried qmi_wwan, right? But only with libqmi? This is most likely not a QMI device in any case. There is a fair chance that it supports Huawei's AT^NDISDUP and related vendor specific AT commands though. You should try that, using either qmi_wwan (if ECM) or the new huawei_cdc_ncm driver (if NCM) for the network function. Yes, tried with libqmi, queries get stuck/timeout with qmicli but nothing nasty. With minicom on /dev/cdc-wdm0 after patching qmi_wwan it seems to be responsive to AT commands so yes it seems we are dealing with ECM here. I'll send a followup patch to include qmi_wwan. This device use ff/ff/ff for class/subclass/protocol on all interfaces, is that right? Yes, for bInterfaceNumber 0..3 i've got Class/SubClass/Protocol 255. 4 and 5 are mass storage which surely correspond with the MicroSD slot and internal flash cdrom emulation/image. Interface 1 has an alternate setting with one endpoint (#0) or 3 endpoints (#1) if that's of any use. You can take a peek at lsusb -vv output @ https://www.zacarias.com.ar/e173s.txt Regards. -- 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 4/4] usb: chipidea: msm: Use USB PHY API to control PHY state
Hi Peter,
On Mon, 2013-11-11 at 21:59 +0800, Peter Chen wrote:
On Mon, Nov 11, 2013 at 03:35:37PM +0200, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
PHY drivers keep track of the current state of the hardware,
so don't change PHY settings under it.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
drivers/usb/chipidea/ci_hdrc_msm.c |9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
b/drivers/usb/chipidea/ci_hdrc_msm.c
index e9624f3..338b209 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -20,13 +20,11 @@
static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
{
struct device *dev = ci-gadget.dev.parent;
- int val;
switch (event) {
case CI_HDRC_CONTROLLER_RESET_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_RESET_EVENT received\n);
- writel(0, USB_AHBBURST);
- writel(0, USB_AHBMODE);
+ usb_phy_init(ci-transceiver);
It will reset the PHY, but your comment is don't change PHY settings under
it
:-). This function is exported by PHY drivers, so they will know how
to handle this change.
break;
case CI_HDRC_CONTROLLER_STOPPED_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_STOPPED_EVENT received\n);
@@ -34,10 +32,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci,
unsigned event)
* Put the transceiver in non-driving mode. Otherwise host
* may not detect soft-disconnection.
*/
- val = usb_phy_io_read(ci-transceiver, ULPI_FUNC_CTRL);
- val = ~ULPI_FUNC_CTRL_OPMODE_MASK;
- val |= ULPI_FUNC_CTRL_OPMODE_NONDRIVING;
- usb_phy_io_write(ci-transceiver, val, ULPI_FUNC_CTRL);
+ usb_phy_notify_disconnect(ci-transceiver, USB_SPEED_UNKNOWN);
Where you have implemented .notify_disconnect?
I have not found it at your phy driver.
Yep, I will post PHY driver changes shortly. Meanwhile this should
not break existing board file based platforms, because not of them
could be compiled (HTC Dream, Halibut Board) and DT based platforms
are sill work in progress.
Regards,
Ivan
--
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/7] usb: dwc3: get usb_phy only if the platform indicates the presence of PHY's
Hi Felipe,
On Thursday 17 October 2013 10:08 PM, Felipe Balbi wrote:
Hi,
On Wed, Oct 16, 2013 at 01:24:11AM +0530, Kishon Vijay Abraham I wrote:
There can be systems which does not have a external usb_phy, so get
usb_phy only if dt data indicates the presence of PHY in the case of dt boot
or
if platform_data indicates the presence of PHY. Also remove checking if
return value is -ENXIO since it's now changed to always enable usb_phy layer.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
I'm fine with this patch, but one comment below:
@@ -387,16 +388,49 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
-dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
-dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
+count = of_count_phandle_with_args(node, usb-phy, NULL);
+switch (count) {
+case 2:
+dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
+usb-phy, 1);
+if (IS_ERR(dwc-usb3_phy)) {
+dev_err(dev, usb3 phy not found\n);
+return PTR_ERR(dwc-usb3_phy);
+}
+case 1:
+dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
+usb-phy, 0);
+if (IS_ERR(dwc-usb2_phy)) {
+dev_err(dev, usb2 phy not found\n);
+return PTR_ERR(dwc-usb2_phy);
+}
+break;
+default:
+dev_err(dev, usb phy nodes not configured\n);
+}
dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
-dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
+if (pdata-usb2_phy) {
+dwc-usb2_phy = devm_usb_get_phy(dev,
+USB_PHY_TYPE_USB2);
+if (IS_ERR(dwc-usb2_phy)) {
+dev_err(dev, usb2 phy not found\n);
+return PTR_ERR(dwc-usb2_phy);
+}
+}
+
+if (pdata-usb3_phy) {
+dwc-usb3_phy = devm_usb_get_phy(dev,
+USB_PHY_TYPE_USB3);
+if (IS_ERR(dwc-usb3_phy)) {
+dev_err(dev, usb3 phy not found\n);
+return PTR_ERR(dwc-usb3_phy);
+}
+}
dwc-needs_fifo_resize = pdata-tx_fifo_resize;
dwc-dr_mode = pdata-dr_mode;
@@ -409,36 +443,6 @@ static int dwc3_probe(struct platform_device *pdev)
if (dwc-maximum_speed == USB_SPEED_UNKNOWN)
dwc-maximum_speed = USB_SPEED_SUPER;
-if (IS_ERR(dwc-usb2_phy)) {
-ret = PTR_ERR(dwc-usb2_phy);
-
-/*
- * if -ENXIO is returned, it means PHY layer wasn't
- * enabled, so it makes no sense to return -EPROBE_DEFER
- * in that case, since no PHY driver will ever probe.
- */
-if (ret == -ENXIO)
-return ret;
-
-dev_err(dev, no usb2 phy configured\n);
-return -EPROBE_DEFER;
-}
-
-if (IS_ERR(dwc-usb3_phy)) {
-ret = PTR_ERR(dwc-usb3_phy);
-
-/*
- * if -ENXIO is returned, it means PHY layer wasn't
- * enabled, so it makes no sense to return -EPROBE_DEFER
- * in that case, since no PHY driver will ever probe.
- */
-if (ret == -ENXIO)
-return ret;
-
-dev_err(dev, no usb3 phy configured\n);
-return -EPROBE_DEFER;
-}
the idea for doing the error checking here was actually to avoid
duplicating it in all previous cases, as you did. Please keep the error
checking here and you're good to go.
-
dwc-xhci_resources[0].start = res-start;
dwc-xhci_resources[0].end = dwc-xhci_resources[0].start +
DWC3_XHCI_REGS_END;
diff --git a/drivers/usb/dwc3/platform_data.h
b/drivers/usb/dwc3/platform_data.h
index 7db34f0..49ffa6d 100644
--- a/drivers/usb/dwc3/platform_data.h
+++ b/drivers/usb/dwc3/platform_data.h
@@ -24,4 +24,6 @@ struct dwc3_platform_data {
enum usb_device_speed maximum_speed;
enum usb_dr_mode dr_mode;
bool tx_fifo_resize;
+bool usb2_phy;
+bool usb3_phy;
This would look better as a quirks flag, then we could:
unsigned long quirks;
#define DWC3_QUIRK_NO_USB3_PHY
Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
Gustavo Zacarias gust...@zacarias.com.ar writes: With minicom on /dev/cdc-wdm0 after patching qmi_wwan it seems to be responsive to AT commands so yes it seems we are dealing with ECM here. I'll send a followup patch to include qmi_wwan. Maybe run a small discussion on the ModemManager list first? This would be the first non-QMI device there, and I don't think userspace is prepared for that I expected this type of device might exist, but we haven't really tried to support it before (AFAIK). Although the qmi_wwan driver doesn't care about whether the embedded control protocol is QMI or AT or something else, current userspace applications do. I am not entirely sure about how this should be handled, but it should be sorted out before we start adding non QMI devices to the driver. This device use ff/ff/ff for class/subclass/protocol on all interfaces, is that right? Yes, for bInterfaceNumber 0..3 i've got Class/SubClass/Protocol 255. 4 and 5 are mass storage which surely correspond with the MicroSD slot and internal flash cdrom emulation/image. Interface 1 has an alternate setting with one endpoint (#0) or 3 endpoints (#1) if that's of any use. You can take a peek at lsusb -vv output @ https://www.zacarias.com.ar/e173s.txt Thanks 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: [PATCH 0/4] usb: chipidea: msm: Clean and fix glue layer driver
Hi Peter, On Mon, 2013-11-11 at 22:02 +0800, Peter Chen wrote: On Mon, Nov 11, 2013 at 03:35:33PM +0200, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com Hi, This series intend to fixup driver, which was broken for a while. It is used to create peripheral role device, which in coordination with phy-usb-msm driver (still some cleanups pending) will provide again USB2.0 gadget support for MSM targets. We haven't seen msm chipidea patch for a long time, good news they appear. Any plans to use the whole chipidea function for msm controller driver (otg, host and peripheral)? Things are little complicated here :-). Currently qcom,echi-host is supposed to control host role. Not tested this completely, but this how is handled also by down stream kernel (codeaurora.org). In this repo there are even 2 slightly different versions of the driver. And OTG and PHY control situations is even ... Currently this functionality is handled by phy-msm-usb. There is a separate gadget driver downstream, which seems to be used in production targets. My plan is to first port minimal set of changes form downstream kernel to phy-msm-usb, which will bring up peripheral role. Regards, Ivan -- 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: chipidea: udc: first start device on pullup
On Mon, Nov 11, 2013 at 09:42:35PM +0800, Peter Chen wrote:
On Mon, Nov 11, 2013 at 12:39:30PM +0100, Michael Grzeschik wrote:
Don't pullup the resistors on hw_device_state. The gadget framework has
the prepared callback for this. This is necessary if we use gadgets
which need to be enabled after an userspace application got prepared, or
other delayed conditiions have passed.
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
---
drivers/usb/chipidea/udc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index b34c819..976153f 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -84,10 +84,8 @@ static int hw_device_state(struct ci_hdrc *ci, u32 dma)
/* interrupt, error, port change, reset, sleep/suspend */
hw_write(ci, OP_USBINTR, ~0,
USBi_UI|USBi_UEI|USBi_PCI|USBi_URI|USBi_SLI);
- hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
} else {
hw_write(ci, OP_USBINTR, ~0, 0);
- hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
}
return 0;
}
Hi Michael, you submitted a similar patch before to fix uvc problem,
but you can't simply delete it, it will cause the udc can't work
if we load gadget first, then plug in the usb cable.
Yes, you also mentioned this the last time. But here, when the
gadget was loaded first and plugged in afterwarts works as well.
Did you see when the pullup function get called? I did also send a
patch that is changing the pullup call inside the gadget drivers.
To fix it, it is better mark that gadget as defer_connect, and
introduce such condition at udc driver.
No, I don't see why this needs to be specially handled inside this
driver. We have the framework for this. USBCMD_RS does pullup the
DP resistor.
The datasheet says, that we have to ensure that the device needs to be
properly setup before touching this bit. As the framework does call
usb_gadget_connect after the gadget has started and connected to the udc
this should be the case.
Thanks,
Michael
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
On Mon, 2013-11-11 at 15:43 +0100, Bjørn Mork wrote: Gustavo Zacarias gust...@zacarias.com.ar writes: With minicom on /dev/cdc-wdm0 after patching qmi_wwan it seems to be responsive to AT commands so yes it seems we are dealing with ECM here. I'll send a followup patch to include qmi_wwan. This is a bit confusing... so you added the device to qmi_wwan, and now one of the AT ports works (cdc-wdm0) and the net port also works, as exposed by qmi_wwan? What's the full lsusb -v for this device after it's modeswitched? I looked through all the recent mails you've sent and couldn't find one. Are the descriptors for standard USB specifications (ACM, WDM, ECM, NCM, etc), or are they vendor-specific 0xFF-type ones but implement the standard protocols? Maybe run a small discussion on the ModemManager list first? This would be the first non-QMI device there, and I don't think userspace is prepared for that We've got a bug open for this in ModemManager: https://bugzilla.gnome.org/show_bug.cgi?id=699741 Quite a few 2008 - 2009-era SonyEricsson phones (TM-506 and others) and many of the Ericsson MBM WWAN minicards expose a cdc-wdm AT port, so this device wouldn't be the first to expose an AT-capable cdc-wdm port. ModemManager does not currently support AT-capable cdc-wdm interfaces though, since the SE devices didn't use them for the primary/secondary AT ports. I expected this type of device might exist, but we haven't really tried to support it before (AFAIK). Although the qmi_wwan driver doesn't care about whether the embedded control protocol is QMI or AT or something else, current userspace applications do. I am not entirely sure about how this should be handled, but it should be sorted out before we start adding non QMI devices to the driver. If we start adding non-QMI devices to the driver, then we should rename it to something more generic. Or, better yet, make the driver generic, and keep qmi_wwan a sub-driver with all the current device IDs. Dan This device use ff/ff/ff for class/subclass/protocol on all interfaces, is that right? Yes, for bInterfaceNumber 0..3 i've got Class/SubClass/Protocol 255. 4 and 5 are mass storage which surely correspond with the MicroSD slot and internal flash cdrom emulation/image. Interface 1 has an alternate setting with one endpoint (#0) or 3 endpoints (#1) if that's of any use. You can take a peek at lsusb -vv output @ https://www.zacarias.com.ar/e173s.txt Thanks 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 -- 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] usb: xhci: Use TRB_CYCLE instead of the constant 0x1
This makes it clear that the ring-cycle_state value is used when
writing to the actual ring itself.
Always use ^= TRB_CYCLE to invert the bit.
Signed-off-by: David Laight david.lai...@aculab.com
---
Changes for v2:
1 Adjusted so that it should apply to HEAD.
(One of the ?: had been changed to ^=.)
2 Added Signed-off line.
drivers/usb/host/xhci-mem.c | 10 +-
drivers/usb/host/xhci-ring.c | 16
drivers/usb/host/xhci.c | 2 +-
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 9b5d1c3..5b2d835 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -597,7 +597,7 @@ struct xhci_stream_info *xhci_alloc_stream_info(struct
xhci_hcd *xhci,
*/
for (cur_stream = 1; cur_stream num_streams; cur_stream++) {
stream_info-stream_rings[cur_stream] =
- xhci_ring_alloc(xhci, 2, 1, TYPE_STREAM, mem_flags);
+ xhci_ring_alloc(xhci, 2, TRB_CYCLE, TYPE_STREAM,
mem_flags);
cur_ring = stream_info-stream_rings[cur_stream];
if (!cur_ring)
goto cleanup_rings;
@@ -906,7 +906,7 @@ int xhci_alloc_virt_device(struct xhci_hcd *xhci, int
slot_id,
}
/* Allocate endpoint 0 ring */
- dev-eps[0].ring = xhci_ring_alloc(xhci, 2, 1, TYPE_CTRL, flags);
+ dev-eps[0].ring = xhci_ring_alloc(xhci, 2, TRB_CYCLE, TYPE_CTRL,
flags);
if (!dev-eps[0].ring)
goto fail;
@@ -1326,7 +1326,7 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
type = usb_endpoint_type(ep-desc);
/* Set up the endpoint ring */
virt_dev-eps[ep_index].new_ring =
- xhci_ring_alloc(xhci, 2, 1, type, mem_flags);
+ xhci_ring_alloc(xhci, 2, TRB_CYCLE, type, mem_flags);
if (!virt_dev-eps[ep_index].new_ring) {
/* Attempt to use the ring cache */
if (virt_dev-num_rings_cached == 0)
@@ -2311,7 +2311,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
goto fail;
/* Set up the command ring to have one segments for now. */
- xhci-cmd_ring = xhci_ring_alloc(xhci, 1, 1, TYPE_COMMAND, flags);
+ xhci-cmd_ring = xhci_ring_alloc(xhci, 1, TRB_CYCLE, TYPE_COMMAND,
flags);
if (!xhci-cmd_ring)
goto fail;
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
@@ -2355,7 +2355,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
* the event ring segment table (ERST). Section 4.9.3.
*/
xhci_dbg_trace(xhci, trace_xhci_dbg_init, // Allocating event ring);
- xhci-event_ring = xhci_ring_alloc(xhci, ERST_NUM_SEGS, 1, TYPE_EVENT,
+ xhci-event_ring = xhci_ring_alloc(xhci, ERST_NUM_SEGS, TRB_CYCLE,
TYPE_EVENT,
flags);
if (!xhci-event_ring)
goto fail;
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d3f4a9a..408978b 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -178,7 +178,7 @@ static void inc_deq(struct xhci_hcd *xhci, struct xhci_ring
*ring)
if (ring-type == TYPE_EVENT
last_trb_on_last_seg(xhci, ring,
ring-deq_seg, ring-dequeue)) {
- ring-cycle_state ^= 1;
+ ring-cycle_state ^= TRB_CYCLE;
}
ring-deq_seg = ring-deq_seg-next;
ring-dequeue = ring-deq_seg-trbs;
@@ -257,7 +257,7 @@ static void inc_enq(struct xhci_hcd *xhci, struct xhci_ring
*ring,
/* Toggle the cycle bit after the last ring segment. */
if (last_trb_on_last_seg(xhci, ring, ring-enq_seg,
next)) {
- ring-cycle_state = (ring-cycle_state ? 0 : 1);
+ ring-cycle_state ^= TRB_CYCLE;
}
}
ring-enq_seg = ring-enq_seg-next;
@@ -475,7 +475,7 @@ static struct xhci_segment *find_trb_seg(
cur_seg-trbs[TRBS_PER_SEGMENT - 1] trb) {
generic_trb = cur_seg-trbs[TRBS_PER_SEGMENT - 1].generic;
if (generic_trb-field[3] cpu_to_le32(LINK_TOGGLE))
- *cycle_state ^= 0x1;
+ *cycle_state ^= TRB_CYCLE;
cur_seg = cur_seg-next;
if (cur_seg == start_seg)
/* Looped over the entire list. Oops! */
@@ -2967,7 +2967,7 @@ static int prepare_ring(struct xhci_hcd *xhci, struct
xhci_ring *ep_ring,
/* Toggle the cycle bit after the last ring segment. */
if (last_trb_on_last_seg(xhci, ring, ring-enq_seg,
next)) {
-
Re: [PATCH] usb: musb: gadget: stall when SETUP packet size is invalid
While working on v2 - already figured out MUSB_CSR0_P_DATAEND bit also
needs to be set - I found a weird thing.
For debug purpose, I changed Line 803 in musb_gadget_ep0.c as
following to stall all SETUP packets.
-if (len != 8) {
+if (len == 8) {
Then the protocol analyzer shows total 16 CONTROL transfers, 12
GET_DESCRIPTOR, and 4 SET_ADDRESS, all have stall response from the
device. But the musb gadget received doubled of the transfers as in
the log below. Does anyone have any thought why the transfers are
doubled on musb side?
[ 24.936096] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 24.941955] packet: 80 06 00 01 00 00 40 00
[ 24.942230] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 24.948059] packet: 80 06 00 01 00 00 40 00
[ 24.948242] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 24.954040] packet: 80 06 00 01 00 00 40 00
[ 25.168090] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 25.173919] packet: 80 06 00 01 00 00 40 00
[ 25.174102] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 25.179931] packet: 80 06 00 01 00 00 40 00
[ 25.180114] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 25.185913] packet: 80 06 00 01 00 00 40 00
[ 25.512084] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 25.517913] packet: 80 06 00 01 00 00 40 00
[ 25.518127] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 25.523925] packet: 80 06 00 01 00 00 40 00
[ 25.524108] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 25.529937] packet: 80 06 00 01 00 00 40 00
[ 25.744079] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 25.749908] packet: 80 06 00 01 00 00 40 00
[ 25.750122] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 25.755920] packet: 80 06 00 01 00 00 40 00
[ 25.756103] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 25.761932] packet: 80 06 00 01 00 00 40 00
[ 26.088104] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 26.093933] packet: 00 05 45 00 00 00 00 00
[ 26.296081] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 26.301910] packet: 00 05 45 00 00 00 00 00
[ 26.616119] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 26.621948] packet: 00 05 46 00 00 00 00 00
[ 26.824096] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 26.829925] packet: 00 05 46 00 00 00 00 00
the analyzer has no more transfers from here
[ 27.357116] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 27.362945] packet: 80 06 00 01 00 00 40 00
[ 27.365112] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 27.370941] packet: 80 06 00 01 00 00 40 00
[ 27.373107] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 27.378936] packet: 80 06 00 01 00 00 40 00
[ 27.596130] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 27.601959] packet: 80 06 00 01 00 00 40 00
[ 27.604125] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 27.609954] packet: 80 06 00 01 00 00 40 00
[ 27.612121] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 27.617950] packet: 80 06 00 01 00 00 40 00
[ 28.001129] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 28.006988] packet: 80 06 00 01 00 00 40 00
[ 28.009124] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 28.014953] packet: 80 06 00 01 00 00 40 00
[ 28.017120] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 28.022949] packet: 80 06 00 01 00 00 40 00
[ 28.240142] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 28.245971] packet: 80 06 00 01 00 00 40 00
[ 28.248138] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 28.253967] packet: 80 06 00 01 00 00 40 00
[ 28.256134] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 28.261962] packet: 80 06 00 01 00 00 40 00
[ 28.589141] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 28.594970] packet: 00 05 6e 00 00 00 00 00
[ 28.800140] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 28.805969] packet: 00 05 6e 00 00 00 00 00
[ 29.177154] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 29.182983] packet: 00 05 6f 00 00 00 00 00
[ 29.388153] musb_g_ep0_irq 831: 0 SETUP packet len 8 != 8 ?
[ 29.393981] packet: 00 05 6f 00 00 00 00 00
Thanks,
-Bin.
On Fri, Nov 8, 2013 at 4:29 PM, Bin Liu binml...@gmail.com wrote:
On Fri, Nov 8, 2013 at 2:42 PM, Felipe Balbi ba...@ti.com wrote:
On Fri, Nov 08, 2013 at 02:20:24PM -0600, Bin Liu wrote:
no commit log == no commit ;-)
I am not sure what else needs to say other than the subject. But I
will try to make some...
Signed-off-by: Bin Liu b-...@ti.com
---
drivers/usb/musb/musb_gadget_ep0.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_gadget_ep0.c
b/drivers/usb/musb/musb_gadget_ep0.c
index 3e9ec7c..f31b9b1 100644
--- a/drivers/usb/musb/musb_gadget_ep0.c
+++ b/drivers/usb/musb/musb_gadget_ep0.c
@@ -664,6 +664,24 @@ __acquires(musb-lock)
return retval;
}
+/* dump the EP0 fifo for debug */
+static void musb_g_ep0_dump_fifo(struct musb *musb, int len)
+{
I would
Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
Dan Williams d...@redhat.com writes: On Mon, 2013-11-11 at 15:43 +0100, Bjørn Mork wrote: Maybe run a small discussion on the ModemManager list first? This would be the first non-QMI device there, and I don't think userspace is prepared for that We've got a bug open for this in ModemManager: https://bugzilla.gnome.org/show_bug.cgi?id=699741 Quite a few 2008 - 2009-era SonyEricsson phones (TM-506 and others) and many of the Ericsson MBM WWAN minicards expose a cdc-wdm AT port, so this device wouldn't be the first to expose an AT-capable cdc-wdm port. Yes, I am fully aware of this. But currently there is an assumed relationship between driver and cdc-wdm protocol: cdc-wdm = AT (except for the unfortunate v3.4+5 Huawei QMI case) qmi_wwan = QMI cdc_mbim = MBIM huawei_cdc_ncm = AT ModemManager does not currently support AT-capable cdc-wdm interfaces though, since the SE devices didn't use them for the primary/secondary AT ports. I expected this type of device might exist, but we haven't really tried to support it before (AFAIK). Although the qmi_wwan driver doesn't care about whether the embedded control protocol is QMI or AT or something else, current userspace applications do. I am not entirely sure about how this should be handled, but it should be sorted out before we start adding non QMI devices to the driver. If we start adding non-QMI devices to the driver, then we should rename it to something more generic. Or, better yet, make the driver generic, and keep qmi_wwan a sub-driver with all the current device IDs. This puts way too much into the driver name, IMHO. I don't think renaming the driver or creating two distinct driver names for AT or QMI devices makes much sense, given that these drivers will be identical. FWIW it's just a coincidence that the qmi_wwan driver didn't end up being named huawei_something instead. We could make the protocol (if known) an attribute of the cdc-wdm device, either in sysfs or adding another ioctl. A sysfs attribute would have been nice, but I guess the discussion around the message size attribute applies here too? But if we do that, then we do handle QMI+ECM and AT+ECM devices differently, so maybe separate drivers makes sense anyway? Hmm, as usual I don't know what I want... 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: [PATCH] usb: xhci: Link TRB must not occur with a USB payload burst.
From: Alan Stern [mailto:st...@rowland.harvard.edu] On Fri, 8 Nov 2013, David Laight wrote: ... GET_MAX_PACKET always returns MaxPacketSize, and for USB-3 bulk endpoints, MaxPacketSize is always 1024. MaxBurstSize can be anything from 1 to 16. I've just read something that explained about bursts. According to my version of the spec (Rev 1.0, dated 5/21/2010), if a TD is larger than the MBP and its length isn't a multiple of the MBP, then the last MBP boundary in the TD must also be a TRB boundary. This follows from two statements in section 4.11.7.1: If the TD Transfer Size is an even multiple of the MBP then all TD Fragments shall define exact multiples of MBP data bytes. If not, then only the last TD Fragment shall define less than MBP data (or the Residue) bytes. No, that doesn't stop there being only 1 TD fragment. (I think it means exact multiple of the MBP.) Suppose, for example, the MBP is 1024. If you have a TD with length 1500, and if it had only one fragment, the last (and only) fragment's length would not less than the MBP and it would not be an exact multiple of the MBP. That doesn't matter - eg example 2 in figure 25 I agree that the text is not as clear as it should be. Reading it all again makes me think that a LINK trb is only allowed on the burst boundary (which might be 16k bytes). The only real way to implement that is to ensure that TD never contain LINK TRB. There are other things that can be done at a TD fragment boundary (or only once per TD fragment) - but the code doesn't attempt any of them. The restriction might be there to simplify the hardware to retransmit as TRB burst. My USB3 ethernet card (ax88179_178a driver) is running a lot more reliably with these changes. David -- 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: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
On 11/11/2013 01:10 PM, Dan Williams wrote: This is a bit confusing... so you added the device to qmi_wwan, and now one of the AT ports works (cdc-wdm0) and the net port also works, as exposed by qmi_wwan? What's the full lsusb -v for this device after it's modeswitched? I looked through all the recent mails you've sent and couldn't find one. Are the descriptors for standard USB specifications (ACM, WDM, ECM, NCM, etc), or are they vendor-specific 0xFF-type ones but implement the standard protocols? I'm not 100% sure how to test the wwan0 interface: init modem, AT^NDISUP... to leave it ready and then run a dhcp client on wwan0? If that's it then no, wwan0 doesn't work, just cdc-wdm0 is providing something useful. I've uploaded the lsusb dump to https://www.zacarias.com.ar/e173s.txt to avoid too much noise (mentioned in my last mail to Bjørn), and yes, they're all 0xFF except for storage. Regards. -- 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: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
Gustavo Zacarias gust...@zacarias.com.ar writes: On 11/11/2013 01:10 PM, Dan Williams wrote: This is a bit confusing... so you added the device to qmi_wwan, and now one of the AT ports works (cdc-wdm0) and the net port also works, as exposed by qmi_wwan? What's the full lsusb -v for this device after it's modeswitched? I looked through all the recent mails you've sent and couldn't find one. Are the descriptors for standard USB specifications (ACM, WDM, ECM, NCM, etc), or are they vendor-specific 0xFF-type ones but implement the standard protocols? I'm not 100% sure how to test the wwan0 interface: init modem, AT^NDISUP... to leave it ready and then run a dhcp client on wwan0? If that's it then no, wwan0 doesn't work, just cdc-wdm0 is providing something useful. If dhcp doesn't work after a successful AT^NDISDUP connection, then there is still a chance that this actuall is a NCM device. That would make things easier in many ways :-) Please try the huawei_cdc_ncm driver, although I am not completely sure that works at all at the moment. Snooping on the device in Windows is another option... Or the device might just not support DHCP. You could try the AT^DHCP? command after connecting, and then configure the wwan0 device manually using addresses from the output of that command. 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: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
On Mon, 2013-11-11 at 18:03 +0100, Bjørn Mork wrote: Dan Williams d...@redhat.com writes: On Mon, 2013-11-11 at 15:43 +0100, Bjørn Mork wrote: Maybe run a small discussion on the ModemManager list first? This would be the first non-QMI device there, and I don't think userspace is prepared for that We've got a bug open for this in ModemManager: https://bugzilla.gnome.org/show_bug.cgi?id=699741 Quite a few 2008 - 2009-era SonyEricsson phones (TM-506 and others) and many of the Ericsson MBM WWAN minicards expose a cdc-wdm AT port, so this device wouldn't be the first to expose an AT-capable cdc-wdm port. Yes, I am fully aware of this. But currently there is an assumed relationship between driver and cdc-wdm protocol: cdc-wdm = AT (except for the unfortunate v3.4+5 Huawei QMI case) Assumed where? kernel or ModemManager? qmi_wwan = QMI cdc_mbim = MBIM huawei_cdc_ncm = AT ModemManager does not currently support AT-capable cdc-wdm interfaces though, since the SE devices didn't use them for the primary/secondary AT ports. I expected this type of device might exist, but we haven't really tried to support it before (AFAIK). Although the qmi_wwan driver doesn't care about whether the embedded control protocol is QMI or AT or something else, current userspace applications do. I am not entirely sure about how this should be handled, but it should be sorted out before we start adding non QMI devices to the driver. If we start adding non-QMI devices to the driver, then we should rename it to something more generic. Or, better yet, make the driver generic, and keep qmi_wwan a sub-driver with all the current device IDs. This puts way too much into the driver name, IMHO. I don't think renaming the driver or creating two distinct driver names for AT or QMI devices makes much sense, given that these drivers will be identical. FWIW it's just a coincidence that the qmi_wwan driver didn't end up being named huawei_something instead. Yeah, might be a coincidence but a driver name of qmi_wwan driving non-QMI devices still seems quite wrong. option driving non-option devices was also wrong, but at the time nobody pushed back on that. The correct solution at the time would have been to rename 'option' to wwan_serial or something like that. If we're going to pursue this, lets make the qmi_wwan driver a generic name instead. We could make the protocol (if known) an attribute of the cdc-wdm device, either in sysfs or adding another ioctl. A sysfs attribute would have been nice, but I guess the discussion around the message size attribute applies here too? While might be nice, it does have drawbacks and it's harder to get mistakes corrected if they are done in the kernel, due to how (in)frequently people update their kernels. I guess I'd say we stick with userspace solutions for this for now, even if it does duplicate the VID/PID lists or use probing. But if we do that, then we do handle QMI+ECM and AT+ECM devices differently, so maybe separate drivers makes sense anyway? So the net-port parts of qmi_wwan just do standard ECM then? Was it simply the case that, at the time, nobody else was doing quasi-ECM except Qualcomm? Dan Hmm, as usual I don't know what I want... 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: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
On Mon, 2013-11-11 at 18:27 +0100, Bjørn Mork wrote: Gustavo Zacarias gust...@zacarias.com.ar writes: On 11/11/2013 01:10 PM, Dan Williams wrote: This is a bit confusing... so you added the device to qmi_wwan, and now one of the AT ports works (cdc-wdm0) and the net port also works, as exposed by qmi_wwan? What's the full lsusb -v for this device after it's modeswitched? I looked through all the recent mails you've sent and couldn't find one. Are the descriptors for standard USB specifications (ACM, WDM, ECM, NCM, etc), or are they vendor-specific 0xFF-type ones but implement the standard protocols? I'm not 100% sure how to test the wwan0 interface: init modem, AT^NDISUP... to leave it ready and then run a dhcp client on wwan0? If that's it then no, wwan0 doesn't work, just cdc-wdm0 is providing something useful. If dhcp doesn't work after a successful AT^NDISDUP connection, then there is still a chance that this actuall is a NCM device. That would make things easier in many ways :-) Please try the huawei_cdc_ncm driver, although I am not completely sure that works at all at the moment. Snooping on the device in Windows is another option... Or the device might just not support DHCP. You could try the AT^DHCP? command after connecting, and then configure the wwan0 device manually using addresses from the output of that command. Yeah, do that. Not all devices reliably support DHCP on the port. Configuring manually with the results of ^DHCP would be a more reliable test. Dan -- 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: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
Dan Williams d...@redhat.com writes: On Mon, 2013-11-11 at 18:03 +0100, Bjørn Mork wrote: Dan Williams d...@redhat.com writes: On Mon, 2013-11-11 at 15:43 +0100, Bjørn Mork wrote: Maybe run a small discussion on the ModemManager list first? This would be the first non-QMI device there, and I don't think userspace is prepared for that We've got a bug open for this in ModemManager: https://bugzilla.gnome.org/show_bug.cgi?id=699741 Quite a few 2008 - 2009-era SonyEricsson phones (TM-506 and others) and many of the Ericsson MBM WWAN minicards expose a cdc-wdm AT port, so this device wouldn't be the first to expose an AT-capable cdc-wdm port. Yes, I am fully aware of this. But currently there is an assumed relationship between driver and cdc-wdm protocol: cdc-wdm = AT (except for the unfortunate v3.4+5 Huawei QMI case) Assumed where? kernel or ModemManager? Maybe just in my head :-) I thought ModemManager based it's decisions wrt protocol on the driver? This puts way too much into the driver name, IMHO. I don't think renaming the driver or creating two distinct driver names for AT or QMI devices makes much sense, given that these drivers will be identical. FWIW it's just a coincidence that the qmi_wwan driver didn't end up being named huawei_something instead. Yeah, might be a coincidence but a driver name of qmi_wwan driving non-QMI devices still seems quite wrong. option driving non-option devices was also wrong, but at the time nobody pushed back on that. The correct solution at the time would have been to rename 'option' to wwan_serial or something like that. If we're going to pursue this, lets make the qmi_wwan driver a generic name instead. Well, I am sure you are right. We could make the protocol (if known) an attribute of the cdc-wdm device, either in sysfs or adding another ioctl. A sysfs attribute would have been nice, but I guess the discussion around the message size attribute applies here too? While might be nice, it does have drawbacks and it's harder to get mistakes corrected if they are done in the kernel, due to how (in)frequently people update their kernels. I guess I'd say we stick with userspace solutions for this for now, even if it does duplicate the VID/PID lists or use probing. But if we do that, then we do handle QMI+ECM and AT+ECM devices differently, so maybe separate drivers makes sense anyway? So the net-port parts of qmi_wwan just do standard ECM then? Yes. Only the descriptors are weird. The rest is standard ECM. Was it simply the case that, at the time, nobody else was doing quasi-ECM except Qualcomm? Limited by the devices I knew of. 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
[PATCH v6 2/2] usb-serial: Moxa UPORT 12XX/14XX/16XX driver
Add a driver which supports the following Moxa USB to serial converters:
* 2 ports : UPort 1250, UPort 1250I
* 4 ports : UPort 1410, UPort 1450, UPort 1450I
* 8 ports : UPort 1610-8, UPort 1650-8
* 16 ports : UPort 1610-16, UPort 1650-16
The UPORT devices don't directy fit the USB serial model. USB serial
assumes a bulk in/out endpoint pair per serial port. Thus a dual port
USB serial device is expected to have two bulk in/out pairs. The Moxa
UPORT only has one pair for data transfer and places a header on each
transfer over the endpoint indicating for which port the transfer
relates to. There is a second endpoint pair for events, such as modem
control lines changing state, setting baud rates etc. Again, a
multiplexing header is used on these endpoints.
Some ports need to have a kfifo explicitily allocated since the
framework does not allocate one if there is no associated endpoints.
The framework will however free it on unload of the module.
All data transfers are made on port0, yet the locks are taken on PortN.
urb-context points to PortN, even though the URB is for port0.
Where possible, code from the generic driver is called. However
mxuport_process_read_urb_data() is mostly a cut/paste of
usb_serial_generic_process_read_urb().
The driver will attempt to load firmware from userspace and compare
the available version and the running version. If the available
version is newer, it will be download into RAM of the device and
started. This is optional and the driver appears to work O.K. with
older firmware in the devices ROM.
This driver is based on the MOXA driver and retains MOXAs copyright.
Signed-off-by: Andrew Lunn and...@lunn.ch
---
v1-v2
Remove debug module parameter.
Add missing \n to dev_dbg() strings.
Consistent dev_dbg(%s - message in lowercase\n, __func__);
Don't log failed allocations.
Remove defensive checks for NULL mx_port.
Use snprintf() instead of sprintf().
Use port-icount and usb_serial_generic_get_icount().
Break firmware download into smaller functions.
Don't DMA to/from buffers on the stack.
Use more of the generic write functions.
Make use of port_probe() and port_remove().
Indent the device structure.
Minor cleanups in mxuport_close()
__u8 - u8, __u16 - u16.
remove mxuport_wait_until_sent() and implemented mxuport_tx_empty()
Remove mxuport_write_room() and use the generic equivelent.
Remove unneeded struct mx_uart_config members
Make use of generic functions for receiving data and events.
Name mxport consistently.
Use usb_serial_generic_tiocmiwait()
Let line discipline handle TCFLSH ioctl.
Import contents of mxuport.h into mxuport.c
Use shifts and ORs to create version number.
Use port_number, not minor
Clarify the meaning of interface in mx_uart_config.
Remove buffer from mxuport_send_async_ctrl_urb().
No need to multiply USB_CTRL_SET_TIMEOUT by HZ.
Simplify buffer allocation and free.
Swap (un)throttle to synchronous interface, remove async code.
Pass usb_serial to mxuport_[recv|send]_ctrl_urb()
Add missing {} on if else statement.
Use unsigned char type, remove casts.
Replace constants with defines.
Add error handling when disabling HW flow control.
Verify port is open before passing it recieved data
Verify contents of received data events.
Remove broken support for alternative baud rates.
Fix B0 and modem line handling. Remove uart_cfg structure.
Remove hold_reason, which was set, but never used.
s/is/if/
Move parts of port open into port probe.
Remove mxport-port and pass usb_serial_port instead.
Remove mxport-flags which is no longer used.
Allocate buffers before starting firmware download.
Remove redundent detected debug message.
Use devm_kzalloc() to simply memory handling.
Remove repeated debug message when sending break.
Implement mxuport_dtr_rts().
Add locking around mcr_state.
Remove unused lsr_state from mxuport_port.
Support 485 via official IOCTL and sysfs.
Use usleep_range() instread of mdelay().
Simplify the comments.
Use port0 as a template when setting up bulk out endpoints.
Set bulk_in_size for unused endpoints to 0.
Rebase to v3.12-rc2
v3-v4
Remove support for rs485 - No hardware to test it on.
Fix formatting of multi line comments.
Use HEADER_SIZE instead of hard coded 4.
Use EIO instread of ECOMM.
Drop use of spinlocks on mxuport_{un}throttle().
Remove unneeded parenthesis.
Split mxuport_process_read_urb_event() into a number of functions.
Check for zero bytes of data.
Don't needlessly initialize variables.
Fold mxuport_port_init() into mxuport_port_open()
Correctly handle the on parameter in mxuport_dtr_rts().
Drop mxuport_get_serial_info and the now empty ioctl handler.
Splitup mxuport_set_termios() into smaller functions
Make use of C_* macros for cflags.
Terminate the firmware download on error.
Remove some unneeded dev_dbg()'s.
Let usb-serial core fill .write function in usb_serial_driver.
Change usb_serial_driver.name to match filename.
Move tiocmget() and tiocmset() next to each other.
Only one declaration per line.
[PATCH v6 1/2] tty: Add C_CMSPAR(tty)
Add the missing C_CMSPAR(tty) macro.
Signed-off-by: Andrew Lunn and...@lunn.ch
---
include/linux/tty.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 64f864651d86..8d1ba896070a 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -137,6 +137,7 @@ struct tty_bufhead {
#define C_CLOCAL(tty) _C_FLAG((tty), CLOCAL)
#define C_CIBAUD(tty) _C_FLAG((tty), CIBAUD)
#define C_CRTSCTS(tty) _C_FLAG((tty), CRTSCTS)
+#define C_CMSPAR(tty) _C_FLAG((tty), CMSPAR)
#define L_ISIG(tty)_L_FLAG((tty), ISIG)
#define L_ICANON(tty) _L_FLAG((tty), ICANON)
--
1.8.4.rc3
--
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: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
On 11/11/2013 02:27 PM, Bjørn Mork wrote: If dhcp doesn't work after a successful AT^NDISDUP connection, then there is still a chance that this actuall is a NCM device. That would make things easier in many ways :-) Please try the huawei_cdc_ncm driver, although I am not completely sure that works at all at the moment. Snooping on the device in Windows is another option... Or the device might just not support DHCP. You could try the AT^DHCP? command after connecting, and then configure the wwan0 device manually using addresses from the output of that command. Actually it wasn't connecting at all, but it was my mistake, the command doesn't work on /dev/ttyUSB?, only on /dev/cdc-acm0, greeted by the always-on led and a happy ^NDISSTAT:1 result. It doesn't help that Huawei OKs every command even if it's ignoring it. And no, AT^DHCP wasn't necessary, dhcp on wwan0 worked just fine. Regards. -- 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: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
On Mon, 2013-11-11 at 18:41 +0100, Bjørn Mork wrote: Dan Williams d...@redhat.com writes: On Mon, 2013-11-11 at 18:03 +0100, Bjørn Mork wrote: Dan Williams d...@redhat.com writes: On Mon, 2013-11-11 at 15:43 +0100, Bjørn Mork wrote: Maybe run a small discussion on the ModemManager list first? This would be the first non-QMI device there, and I don't think userspace is prepared for that We've got a bug open for this in ModemManager: https://bugzilla.gnome.org/show_bug.cgi?id=699741 Quite a few 2008 - 2009-era SonyEricsson phones (TM-506 and others) and many of the Ericsson MBM WWAN minicards expose a cdc-wdm AT port, so this device wouldn't be the first to expose an AT-capable cdc-wdm port. Yes, I am fully aware of this. But currently there is an assumed relationship between driver and cdc-wdm protocol: cdc-wdm = AT (except for the unfortunate v3.4+5 Huawei QMI case) Assumed where? kernel or ModemManager? Maybe just in my head :-) I thought ModemManager based it's decisions wrt protocol on the driver? It's a mix of driver names, device names, and udev rules. For example, ModemManager currently only cares about devices named cdc-wdm* when the USB device is driven by qmi_wwan or cdc_mbim. Otherwise these ports are ignored (as is the case for Ericsson devices). And this check only sets probing flags, so this could easily be extended to probe cdc-wdm devices for AT commands too. One example of solely driver-based detection is the 'hso' driver, which only drives Option HSO devices. In this case, ModemManager uses the driver name as the filter. This puts way too much into the driver name, IMHO. I don't think renaming the driver or creating two distinct driver names for AT or QMI devices makes much sense, given that these drivers will be identical. FWIW it's just a coincidence that the qmi_wwan driver didn't end up being named huawei_something instead. Yeah, might be a coincidence but a driver name of qmi_wwan driving non-QMI devices still seems quite wrong. option driving non-option devices was also wrong, but at the time nobody pushed back on that. The correct solution at the time would have been to rename 'option' to wwan_serial or something like that. If we're going to pursue this, lets make the qmi_wwan driver a generic name instead. Well, I am sure you are right. I've been wrong before :) We could make the protocol (if known) an attribute of the cdc-wdm device, either in sysfs or adding another ioctl. A sysfs attribute would have been nice, but I guess the discussion around the message size attribute applies here too? While might be nice, it does have drawbacks and it's harder to get mistakes corrected if they are done in the kernel, due to how (in)frequently people update their kernels. I guess I'd say we stick with userspace solutions for this for now, even if it does duplicate the VID/PID lists or use probing. But if we do that, then we do handle QMI+ECM and AT+ECM devices differently, so maybe separate drivers makes sense anyway? So the net-port parts of qmi_wwan just do standard ECM then? Yes. Only the descriptors are weird. The rest is standard ECM. Well, including all the IPv4/IPv6 quirks? Those seem to be Qualcomm specific; especially where the rawip/8023 and QoS options are concerned. Were we ever to support rawip or the QoS options, we'd need a completely different driver. My suggestion here would be to create a new cdc-ecm driver (like we did for cdc_eem or cdc_ether or cdc_ncm) and make qmi_wwan a sub-driver of that (if that's even needed given these all are subdrivers of usbnet). This way we keep standard ECM in one place and pile all the vendor-specific hacks into sub-drivers instead of tangling them all together? Dan Was it simply the case that, at the time, nobody else was doing quasi-ECM except Qualcomm? Limited by the devices I knew of. 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: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
Dan Williams d...@redhat.com writes: So the net-port parts of qmi_wwan just do standard ECM then? Yes. Only the descriptors are weird. The rest is standard ECM. Well, including all the IPv4/IPv6 quirks? No, all the firmware bugs are very implementation specific :-) I don't know if the ECM similarity is intentional or not. It's really a simple protocol, just transmitting plain ethernet frames over bulk USB. Those seem to be Qualcomm specific; especially where the rawip/8023 and QoS options are concerned. Were we ever to support rawip or the QoS options, we'd need a completely different driver. Yes. My suggestion here would be to create a new cdc-ecm driver (like we did for cdc_eem or cdc_ether or cdc_ncm) and make qmi_wwan a sub-driver of that (if that's even needed given these all are subdrivers of usbnet). This way we keep standard ECM in one place and pile all the vendor-specific hacks into sub-drivers instead of tangling them all together? This is pretty much what we already have there... All the networking code is in usbnet, and already shared with cdc_ether. The code in qmi_wwan is just a) device specific probing b) enabling the cdc-wdm subdriver c) quirks Nothing more. 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: [PATCHv2 2/2] check quirk to pad epout buf size when not aligned to maxpacketsize
On 11/11/2013 03:21 AM, Michal Nazarewicz wrote:
Check gadget.quirk_ep_out_aligned_size to decide if buffer size requires
to be aligned to maxpacketsize of an out endpoint. ffs_epfile_io() needs
to pad epout buffer to match above condition if quirk is found.
Signed-off-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/f_fs.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
On 11/10/2013 08:50 AM, Michal Nazarewicz wrote:
@@ -787,6 +788,13 @@ static ssize_t ffs_epfile_io(struct file *file,
/* Allocate copy */
if (!halt) {
+ /*
+* Controller requires buffer size to be aligned to
+* maxpacketsize of an out endpoint.
+*/
+ data_len = read gadget-quirk_ep_out_aligned_size ?
+ usb_ep_align_maxpacketsize(ep-ep, len) : len;
+
data = kmalloc(len, GFP_KERNEL);
On Mon, Nov 11 2013, David Cohen david.a.co...@linux.intel.com wrote:
Shouldn't this kmalloc() allocate 'data_len' bytes, instead of 'len'?
Yes, of coures.
Thanks. It looks fine. I'll test these patches now.
But the whole series became messy with too many amends. If you don't
mind, I'll send a v5 of my patch set including my v4.1 patches + your 2
ones following the correct sequence.
Br, David Cohen
--
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] usb: musb: gadget: stall when SETUP packet size is invalid
This is required by the USB Specs.
Also dump the fifo for debug purpose.
Signed-off-by: Bin Liu b-...@ti.com
---
v2:
- Modification based on Felipe's comments
* Added commit log;
* Wrapped dump fifo function with #ifdef DEBUG;
* Used static buffer for dump;
* Changed dump level to KERN_DEBUG;
- Changed the dump fifo function to inline;
- Set MUSB_CSR0_P_DATAEND bit to avoid confusing log;
drivers/usb/musb/musb_gadget_ep0.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_gadget_ep0.c
b/drivers/usb/musb/musb_gadget_ep0.c
index 2af45a0..af9e7de 100644
--- a/drivers/usb/musb/musb_gadget_ep0.c
+++ b/drivers/usb/musb/musb_gadget_ep0.c
@@ -658,6 +658,23 @@ __acquires(musb-lock)
return retval;
}
+/* dump the EP0 fifo for debug */
+static inline void musb_g_ep0_dump_fifo(struct musb *musb, int len)
+{
+#ifdef DEBUG
+#define BUF_LEN16
+
+ u8 buf[BUF_LEN];
+
+ if (len = 0)
+ return;
+
+ musb-ops-read_fifo(musb-endpoints[0], min(len, BUF_LEN), buf);
+ print_hex_dump(KERN_DEBUG, packet: , DUMP_PREFIX_NONE,
+ 16, 1, buf, len, false);
+#endif /* DEBUG */
+}
+
/*
* Handle peripheral ep0 interrupt
*
@@ -802,7 +819,16 @@ setup:
if (len != 8) {
ERR(SETUP packet len %d != 8 ?\n, len);
- break;
+ musb_g_ep0_dump_fifo(musb, len);
+ /*
+* set the DATAEND bit here to
+* help avoid SetupEnd interrupt coming
+* in the idle stage when we're stalling...
+*/
+ musb-ackpend = MUSB_CSR0_P_SVDRXPKTRDY |
+ MUSB_CSR0_P_DATAEND;
+ retval = IRQ_HANDLED;
+ goto stall;
}
musb_read_setup(musb, setup);
retval = IRQ_HANDLED;
--
1.8.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 09/12] usb: gadget: r8a66597-udc: Convert to clk_prepare/unprepare
On Sat, Nov 09, 2013 at 03:09:33PM +0100, Laurent Pinchart wrote: Hi Felipe, On Tuesday 29 October 2013 18:47:19 Shimoda, Yoshihiro wrote: Hi Laurent-san, (2013/10/29 7:49), Laurent Pinchart wrote: Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and clk_disable_unprepare() to get ready for the migration to the common clock framework. Cc: Felipe Balbi ba...@ti.com Cc: linux-usb@vger.kernel.org Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Thank you for the patch. Acked-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com Could you please pick this patch up ? after -rc1 is out, I don't see why not. -- balbi signature.asc Description: Digital signature
Re: [pandaboard] OTG port not working
Hi, On Sun, Nov 10, 2013 at 07:58:50PM -0500, Alan Ott wrote: On 11/10/2013 06:14 PM, Tobias Jakobi wrote: Since suggested by gregkh, here a CC. Typically you're going to get a better response on mailing lists if you give a little more information. Start with the following: 1. What kernel are you using? 2. Which gadget are you trying to use (assumed from OTG)? 3. What procedure are you using? 4. What is the expected behavior? 5. What is the acutal behavior? 6. What do you see in the logs (what can you learn from higher debugging levels)? Thanks Alan, that's exactly what we need. Also makes sense to Cc maintainers ;-) -- balbi signature.asc Description: Digital signature
Re: musb: babble interrupt
Hi, On Mon, Nov 11, 2013 at 07:38:14PM +0800, Yingchun Li wrote: Hi, On my board, my musb works as host. my kernel version is 3.4.0. The host cannot enumerate some low speed mouse normally,but if I add an extersion cord (abour 1.5m) between the host and device, the mouse can work normally. If the enumeration fails, there is always a babble interrupt happen just after the USB reset ,and the session would be stop(seems automaticly stoped by the IP core). From the sniffer, if the enumeration success, there is an EOP just after the usb reset(about 2us), but if fails, there is no EOP,then babble interrupt issued. So anyone please give me some clue to dig? sorry, you're on your own using such an old kernel. You need to try with a more recent kernel such as v3.12. note that you didn't even bothered to merge all 68 stable releases the v3.4 kernel had. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: chipidea: udc: first start device on pullup
On Mon, Nov 11, 2013 at 12:39:30PM +0100, Michael Grzeschik wrote: Don't pullup the resistors on hw_device_state. The gadget framework has the prepared callback for this. This is necessary if we use gadgets which need to be enabled after an userspace application got prepared, or other delayed conditiions have passed. s/conditiions/conditions other than that, Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/2] usb: gadget: f_fs: remove loop from I/O function
Hi Michal,
On 11/10/2013 08:50 AM, Michal Nazarewicz wrote:
From: Michal Nazarewicz min...@mina86.com
When endpoint changes (due to it being disabled or alt setting changed),
mimic the action as if the change happened after the request has been
queued, instead of retrying with the new endpoint.
Signed-off-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/f_fs.c | 94 +--
1 file changed, 41 insertions(+), 53 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 44cf775..f875f26 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -754,74 +754,61 @@ static ssize_t ffs_epfile_io(struct file *file,
{
struct ffs_epfile *epfile = file-private_data;
struct ffs_ep *ep;
- char *data = NULL;
ssize_t ret;
+ char *data;
int halt;
- goto first_try;
- do {
- spin_unlock_irq(epfile-ffs-eps_lock);
- mutex_unlock(epfile-mutex);
+ /* Are we still active? */
+ if (WARN_ON(epfile-ffs-state != FFS_ACTIVE)) {
+ ret = -ENODEV;
+ goto error;
+ }
-first_try:
- /* Are we still active? */
- if (WARN_ON(epfile-ffs-state != FFS_ACTIVE)) {
- ret = -ENODEV;
+ /* Wait for endpoint to be enabled */
+ ep = epfile-ep;
+ if (!ep) {
+ if (file-f_flags O_NONBLOCK) {
+ ret = -EAGAIN;
goto error;
}
- /* Wait for endpoint to be enabled */
- ep = epfile-ep;
- if (!ep) {
- if (file-f_flags O_NONBLOCK) {
- ret = -EAGAIN;
- goto error;
- }
-
- if (wait_event_interruptible(epfile-wait,
-(ep = epfile-ep))) {
- ret = -EINTR;
- goto error;
- }
- }
-
- /* Do we halt? */
- halt = !read == !epfile-in;
- if (halt epfile-isoc) {
- ret = -EINVAL;
+ if (wait_event_interruptible(epfile-wait, (ep = epfile-ep))) {
FYI this line fails checkpatch:
ERROR: do not use assignment in if condition
#70: FILE: drivers/usb/gadget/f_fs.c:777:
+ if (wait_event_interruptible(epfile-wait, (ep = epfile-ep))) {
total: 1 errors, 0 warnings, 121 lines checked
Since you're just moving that line here, you may want (or not) to clean
this up in a new patch for 3.13.
Br, David Cohen
--
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 v5 1/5] usb: gadget: move bitflags to the end of usb_gadget struct
This patch moves all bitflags to the end of usb_gadget struct in order
to improve readability.
Signed-off-by: David Cohen david.a.co...@linux.intel.com
---
include/linux/usb/gadget.h | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 942ef5e053bf..23b3bfd0a842 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -485,6 +485,11 @@ struct usb_gadget_ops {
* @max_speed: Maximal speed the UDC can handle. UDC must support this
* and all slower speeds.
* @state: the state we are now (attached, suspended, configured, etc)
+ * @name: Identifies the controller hardware type. Used in diagnostics
+ * and sometimes configuration.
+ * @dev: Driver model state for this abstract device.
+ * @out_epnum: last used out ep number
+ * @in_epnum: last used in ep number
* @sg_supported: true if we can handle scatter-gather
* @is_otg: True if the USB device port uses a Mini-AB jack, so that the
* gadget driver must provide a USB OTG descriptor.
@@ -497,11 +502,6 @@ struct usb_gadget_ops {
* only supports HNP on a different root port.
* @b_hnp_enable: OTG device feature flag, indicating that the A-Host
* enabled HNP support.
- * @name: Identifies the controller hardware type. Used in diagnostics
- * and sometimes configuration.
- * @dev: Driver model state for this abstract device.
- * @out_epnum: last used out ep number
- * @in_epnum: last used in ep number
*
* Gadgets have a mostly-portable gadget driver implementing device
* functions, handling all usb configurations and interfaces. Gadget
@@ -530,16 +530,17 @@ struct usb_gadget {
enum usb_device_speed speed;
enum usb_device_speed max_speed;
enum usb_device_state state;
+ const char *name;
+ struct device dev;
+ unsignedout_epnum;
+ unsignedin_epnum;
+
unsignedsg_supported:1;
unsignedis_otg:1;
unsignedis_a_peripheral:1;
unsignedb_hnp_enable:1;
unsigneda_hnp_support:1;
unsigneda_alt_hnp_support:1;
- const char *name;
- struct device dev;
- unsignedout_epnum;
- unsignedin_epnum;
};
#define work_to_gadget(w) (container_of((w), struct usb_gadget, work))
--
1.8.4.rc3
--
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 v5 5/5] usb: dwc3: set gadget's quirk ep_out_align_size
DWC3 requires epout to have buffer size aligned to MaxPacketSize value. This patch sets necessary quirk for it. Signed-off-by: David Cohen david.a.co...@linux.intel.com --- drivers/usb/dwc3/gadget.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 5452c0fce360..b85ec110d6a0 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -2600,6 +2600,12 @@ int dwc3_gadget_init(struct dwc3 *dwc) dwc-gadget.name= dwc3-gadget; /* +* Per databook, DWC3 needs buffer size to be aligned to MaxPacketSize +* on ep out. +*/ + dwc-gadget.quirk_ep_out_aligned_size = true; + + /* * REVISIT: Here we should clear all pending IRQs to be * sure we're starting from a well known location. */ -- 1.8.4.rc3 -- 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 v5 4/5] usb: f_fs: check quirk to pad epout buf size when not aligned to maxpacketsize
From: Michal Nazarewicz min...@mina86.com
Check gadget.quirk_ep_out_aligned_size to decide if buffer size requires
to be aligned to maxpacketsize of an out endpoint. ffs_epfile_io() needs
to pad epout buffer to match above condition if quirk is found.
Signed-off-by: Michal Nazarewicz min...@mina86.com
Acked-by: David Cohen david.a.co...@linux.intel.com
---
drivers/usb/gadget/f_fs.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index f1563c47e0c2..c49288778fe0 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -755,8 +755,9 @@ static ssize_t ffs_epfile_io(struct file *file,
char __user *buf, size_t len, int read)
{
struct ffs_epfile *epfile = file-private_data;
+ struct usb_gadget *gadget = epfile-ffs-gadget;
struct ffs_ep *ep;
- ssize_t ret;
+ ssize_t ret, data_len;
char *data;
int halt;
@@ -789,7 +790,14 @@ static ssize_t ffs_epfile_io(struct file *file,
/* Allocate copy */
if (!halt) {
- data = kmalloc(len, GFP_KERNEL);
+ /*
+* Controller requires buffer size to be aligned to
+* maxpacketsize of an out endpoint.
+*/
+ data_len = read gadget-quirk_ep_out_aligned_size ?
+ usb_ep_align_maxpacketsize(ep-ep, len) : len;
+
+ data = kmalloc(data_len, GFP_KERNEL);
if (unlikely(!data))
return -ENOMEM;
@@ -826,7 +834,7 @@ static ssize_t ffs_epfile_io(struct file *file,
req-context = done;
req-complete = ffs_epfile_io_complete;
req-buf = data;
- req-length = len;
+ req-length = data_len;
ret = usb_ep_queue(ep-ep, req, GFP_ATOMIC);
@@ -838,9 +846,16 @@ static ssize_t ffs_epfile_io(struct file *file,
ret = -EINTR;
usb_ep_dequeue(ep-ep, req);
} else {
+ /*
+* XXX We may end up silently droping data here.
+* Since data_len (i.e. req-length) may be bigger
+* than len (after being rounded up to maxpacketsize),
+* we may end up with more data then user space has
+* space for.
+*/
ret = ep-status;
if (read ret 0
- unlikely(copy_to_user(buf, data, ret)))
+ unlikely(copy_to_user(buf, data, min(ret, len
ret = -EFAULT;
}
}
--
1.8.4.rc3
--
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 v5 0/5] add gadget quirk to adapt f_fs for DWC3
Hi, These patches are a proposal to add gadget quirks in an immediate objective to adapt f_fs when using DWC3 controller. But the quirk solution is generic and can be used by other controllers to adapt gadget functions to their non-standard restrictions. This change is necessary to make Android's adbd service to work on Intel Merrifield with f_fs instead of out-of-tree android gadget. This new patch set was tested and validated in my environment: - Intel Merrifield was able to use DWC3/f_fs with adbd service (it wasn't before). Changes from v4 to v5: - Added 2 patches from Michal Nazarewicz to address comments from Alan Stern on f_fs driver. --- David Cohen (3): usb: gadget: move bitflags to the end of usb_gadget struct usb: gadget: add quirk_ep_out_aligned_size field to struct usb_gadget usb: dwc3: set gadget's quirk ep_out_align_size Michal Nazarewicz (2): usb: gadget: f_fs: remove loop from I/O function usb: f_fs: check quirk to pad epout buf size when not aligned to maxpacketsize drivers/usb/dwc3/gadget.c | 6 +++ drivers/usb/gadget/f_fs.c | 115 +++-- include/linux/usb/gadget.h | 35 ++ 3 files changed, 91 insertions(+), 65 deletions(-) -- 1.8.4.rc3 -- 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 v5 2/5] usb: gadget: add quirk_ep_out_aligned_size field to struct usb_gadget
Due to USB controllers may have different restrictions, usb gadget layer
needs to provide a generic way to inform gadget functions to complain
with non-standard requirements.
This patch adds 'quirk_ep_out_aligned_size' field to struct usb_gadget
to inform when controller's epout requires buffer size to be aligned to
MaxPacketSize. A helper is also provided to align buffer size when
necessary.
Signed-off-by: David Cohen david.a.co...@linux.intel.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
Michal,
I added prefix 'usb: f_fs: ' to patch's subject. I did not add 'usb: gadget:
f_fs' due to it would be too long.
include/linux/usb/gadget.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 23b3bfd0a842..41e8834af57d 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -441,6 +441,19 @@ static inline void usb_ep_fifo_flush(struct usb_ep *ep)
ep-ops-fifo_flush(ep);
}
+/**
+ * usb_ep_align_maxpacketsize - returns @len aligned to ep's maxpacketsize
+ * @ep: the endpoint whose maxpacketsize is used to align @len
+ * @len: buffer size's length to align to @ep's maxpacketsize
+ *
+ * This helper is used in case it's required for any reason to align buffer's
+ * size to an ep's maxpacketsize.
+ */
+static inline size_t usb_ep_align_maxpacketsize(struct usb_ep *ep, size_t len)
+{
+ return round_up(len, (size_t)ep-desc-wMaxPacketSize);
+}
+
/*-*/
@@ -502,6 +515,8 @@ struct usb_gadget_ops {
* only supports HNP on a different root port.
* @b_hnp_enable: OTG device feature flag, indicating that the A-Host
* enabled HNP support.
+ * @quirk_ep_out_aligned_size: epout requires buffer size to be aligned to
+ * MaxPacketSize.
*
* Gadgets have a mostly-portable gadget driver implementing device
* functions, handling all usb configurations and interfaces. Gadget
@@ -541,6 +556,7 @@ struct usb_gadget {
unsignedb_hnp_enable:1;
unsigneda_hnp_support:1;
unsigneda_alt_hnp_support:1;
+ unsignedquirk_ep_out_aligned_size:1;
};
#define work_to_gadget(w) (container_of((w), struct usb_gadget, work))
--
1.8.4.rc3
--
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 v5 3/5] usb: gadget: f_fs: remove loop from I/O function
From: Michal Nazarewicz min...@mina86.com
When endpoint changes (due to it being disabled or alt setting changed),
mimic the action as if the change happened after the request has been
queued, instead of retrying with the new endpoint.
Signed-off-by: Michal Nazarewicz min...@mina86.com
Cc: David Cohen david.a.co...@linux.intel.com
---
drivers/usb/gadget/f_fs.c | 94 +--
1 file changed, 41 insertions(+), 53 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 75e4b7846a8d..f1563c47e0c2 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -756,74 +756,61 @@ static ssize_t ffs_epfile_io(struct file *file,
{
struct ffs_epfile *epfile = file-private_data;
struct ffs_ep *ep;
- char *data = NULL;
ssize_t ret;
+ char *data;
int halt;
- goto first_try;
- do {
- spin_unlock_irq(epfile-ffs-eps_lock);
- mutex_unlock(epfile-mutex);
+ /* Are we still active? */
+ if (WARN_ON(epfile-ffs-state != FFS_ACTIVE)) {
+ ret = -ENODEV;
+ goto error;
+ }
-first_try:
- /* Are we still active? */
- if (WARN_ON(epfile-ffs-state != FFS_ACTIVE)) {
- ret = -ENODEV;
+ /* Wait for endpoint to be enabled */
+ ep = epfile-ep;
+ if (!ep) {
+ if (file-f_flags O_NONBLOCK) {
+ ret = -EAGAIN;
goto error;
}
- /* Wait for endpoint to be enabled */
- ep = epfile-ep;
- if (!ep) {
- if (file-f_flags O_NONBLOCK) {
- ret = -EAGAIN;
- goto error;
- }
-
- if (wait_event_interruptible(epfile-wait,
-(ep = epfile-ep))) {
- ret = -EINTR;
- goto error;
- }
- }
-
- /* Do we halt? */
- halt = !read == !epfile-in;
- if (halt epfile-isoc) {
- ret = -EINVAL;
+ if (wait_event_interruptible(epfile-wait, (ep = epfile-ep))) {
+ ret = -EINTR;
goto error;
}
+ }
- /* Allocate copy */
- if (!halt !data) {
- data = kzalloc(len, GFP_KERNEL);
- if (unlikely(!data))
- return -ENOMEM;
+ /* Do we halt? */
+ halt = !read == !epfile-in;
+ if (halt epfile-isoc) {
+ ret = -EINVAL;
+ goto error;
+ }
- if (!read
- unlikely(__copy_from_user(data, buf, len))) {
- ret = -EFAULT;
- goto error;
- }
- }
+ /* Allocate copy */
+ if (!halt) {
+ data = kmalloc(len, GFP_KERNEL);
+ if (unlikely(!data))
+ return -ENOMEM;
- /* We will be using request */
- ret = ffs_mutex_lock(epfile-mutex,
-file-f_flags O_NONBLOCK);
- if (unlikely(ret))
+ if (!read unlikely(copy_from_user(data, buf, len))) {
+ ret = -EFAULT;
goto error;
+ }
+ }
- /*
-* We're called from user space, we can use _irq rather then
-* _irqsave
-*/
- spin_lock_irq(epfile-ffs-eps_lock);
+ /* We will be using request */
+ ret = ffs_mutex_lock(epfile-mutex, file-f_flags O_NONBLOCK);
+ if (unlikely(ret))
+ goto error;
+ spin_lock_irq(epfile-ffs-eps_lock);
- /*
-* While we were acquiring mutex endpoint got disabled
-* or changed?
-*/
- } while (unlikely(epfile-ep != ep));
+ /* While we were acquiring mutex endpoint got disabled or changed. */
+ if (epfile-ep != ep) {
+ ret = -ESHUTDOWN;
+ spin_unlock_irq(epfile-ffs-eps_lock);
+ goto error_unlock;
+ }
/* Halt */
if (unlikely(halt)) {
@@ -858,6 +845,7 @@ first_try:
}
}
+error_unlock:
mutex_unlock(epfile-mutex);
error:
kfree(data);
--
1.8.4.rc3
--
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: [PATCHv2 2/2] check quirk to pad epout buf size when not aligned to maxpacketsize
On Mon, 11 Nov 2013, Michal Nazarewicz wrote:
Check gadget.quirk_ep_out_aligned_size to decide if buffer size requires
to be aligned to maxpacketsize of an out endpoint. ffs_epfile_io() needs
to pad epout buffer to match above condition if quirk is found.
Signed-off-by: Michal Nazarewicz min...@mina86.com
I think this is still wrong.
@@ -787,7 +788,14 @@ static ssize_t ffs_epfile_io(struct file *file,
/* Allocate copy */
if (!halt) {
- data = kmalloc(len, GFP_KERNEL);
+ /*
+ * Controller requires buffer size to be aligned to
+ * maxpacketsize of an out endpoint.
+ */
+ data_len = read gadget-quirk_ep_out_aligned_size ?
+ usb_ep_align_maxpacketsize(ep-ep, len) : len;
+
+ data = kmalloc(data_len, GFP_KERNEL);
if (unlikely(!data))
return -ENOMEM;
@@ -824,7 +832,7 @@ static ssize_t ffs_epfile_io(struct file *file,
req-context = done;
req-complete = ffs_epfile_io_complete;
req-buf = data;
- req-length = len;
+ req-length = data_len;
IIUC, req-length should still be set to len, not to data_len.
ret = usb_ep_queue(ep-ep, req, GFP_ATOMIC);
@@ -836,9 +844,16 @@ static ssize_t ffs_epfile_io(struct file *file,
ret = -EINTR;
usb_ep_dequeue(ep-ep, req);
} else {
+ /*
+ * XXX We may end up silently droping data here.
+ * Since data_len (i.e. req-length) may be bigger
+ * than len (after being rounded up to maxpacketsize),
+ * we may end up with more data then user space has
+ * space for.
+ */
Then this will never come up. If the host sends a packet that's too
long, you'll get a -EOVERFLOW error.
ret = ep-status;
if (read ret 0
- unlikely(copy_to_user(buf, data, ret)))
+ unlikely(copy_to_user(buf, data, min(ret, len
ret = -EFAULT;
}
}
The reason for the quirk is that the controller may write all the
incoming data to the buffer, even if this is more data than the driver
requested.
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: xhci: Link TRB must not occur with a USB payload burst.
On Mon, 11 Nov 2013, David Laight wrote: Suppose, for example, the MBP is 1024. If you have a TD with length 1500, and if it had only one fragment, the last (and only) fragment's length would not less than the MBP and it would not be an exact multiple of the MBP. That doesn't matter - eg example 2 in figure 25 You're right. I do wish the spec had been written more clearly. Reading it all again makes me think that a LINK trb is only allowed on the burst boundary (which might be 16k bytes). The only real way to implement that is to ensure that TD never contain LINK TRB. That's one way to do it. Or you could allow a Link TRB at an intermediate MBP boundary. It comes down to a question of how often you want the controller to issue an interrupt. If a ring segment is 4 KB (one page), then it can hold 256 TRBs. With scatter-gather transfers, each SG element typically refers to something like a 2-page buffer (depends on how fragmented the memory is). Therefore a ring segment will describe somewhere around 512 pages of data, i.e., something like 2 MB. Since SuperSpeed is 500 MB/s, you'd end up getting in the vicinity of 250 interrupts every second just because of ring segment crossings. Using larger ring segments would help. 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: [PATCHv2 2/2] check quirk to pad epout buf size when not aligned to maxpacketsize
On Mon, Nov 11 2013, Alan Stern wrote:
On Mon, 11 Nov 2013, Michal Nazarewicz wrote:
Check gadget.quirk_ep_out_aligned_size to decide if buffer size requires
to be aligned to maxpacketsize of an out endpoint. ffs_epfile_io() needs
to pad epout buffer to match above condition if quirk is found.
Signed-off-by: Michal Nazarewicz min...@mina86.com
I think this is still wrong.
@@ -824,7 +832,7 @@ static ssize_t ffs_epfile_io(struct file *file,
req-context = done;
req-complete = ffs_epfile_io_complete;
req-buf = data;
-req-length = len;
+req-length = data_len;
IIUC, req-length should still be set to len, not to data_len.
ret = usb_ep_queue(ep-ep, req, GFP_ATOMIC);
@@ -836,9 +844,16 @@ static ssize_t ffs_epfile_io(struct file *file,
ret = -EINTR;
usb_ep_dequeue(ep-ep, req);
} else {
+/*
+ * XXX We may end up silently droping data here.
+ * Since data_len (i.e. req-length) may be bigger
+ * than len (after being rounded up to maxpacketsize),
+ * we may end up with more data then user space has
+ * space for.
+ */
Then this will never come up. If the host sends a packet that's too
long, you'll get a -EOVERFLOW error.
ret = ep-status;
if (read ret 0
-unlikely(copy_to_user(buf, data, ret)))
+unlikely(copy_to_user(buf, data, min(ret, len
ret = -EFAULT;
}
}
The reason for the quirk is that the controller may write all the
incoming data to the buffer, even if this is more data than the driver
requested.
If that's the case, then it indeed solves the problem of silently
throwing away data. I guess it makes more sense then my understanding
of the quirk.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo--
signature.asc
Description: PGP signature
Re: [PATCHv2 2/2] check quirk to pad epout buf size when not aligned to maxpacketsize
On Mon, Nov 11 2013, David Cohen wrote: But the whole series became messy with too many amends. If you don't mind, I'll send a v5 of my patch set including my v4.1 patches + your 2 ones following the correct sequence. Please do, but as Alan pointed out my second patch needs some fixes, namely the last two hunks are not needed. If you want I can resend the patch, or you could just drop them by yourself. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo-- signature.asc Description: PGP signature
Re: [PATCH 1/2] usb: gadget: f_fs: remove loop from I/O function
On 11/10/2013 08:50 AM, Michal Nazarewicz wrote:
+if (wait_event_interruptible(epfile-wait, (ep = epfile-ep))) {
On Mon, Nov 11 2013, David Cohen wrote:
FYI this line fails checkpatch:
ERROR: do not use assignment in if condition
#70: FILE: drivers/usb/gadget/f_fs.c:777:
+ if (wait_event_interruptible(epfile-wait, (ep = epfile-ep))) {
total: 1 errors, 0 warnings, 121 lines checked
This is intentional.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo--
signature.asc
Description: PGP signature
Re: [PATCH v4 1/3] usb: ehci: add freescale imx28 special write register method
On 10/30/2013 04:06 AM, Peter Chen wrote:
According to Freescale imx28 Errata, ENGR119653 USB: ARM to USB
register error issue, All USB register write operations must
use the ARM SWP instruction. So, we implement a special ehci_write
for imx28.
Discussion for it at below:
http://marc.info/?l=linux-usbm=137996395529294w=2
Signed-off-by: Peter Chen peter.c...@freescale.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci.h | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index e8f41c5..535aa8b 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -225,6 +225,7 @@ struct ehci_hcd { /* one per controller */
unsignedhas_synopsys_hc_bug:1; /* Synopsys HC */
unsignedframe_index_bug:1; /* MosChip (AKA NetMos) */
unsignedneed_oc_pp_cycle:1; /* MPC834X port power */
+ unsignedimx28_write_fix:1; /* For Freescale i.MX28 */
/* required for usb32 quirk */
#define OHCI_CTRL_HCFS (3 6)
@@ -728,6 +729,13 @@ static inline unsigned int ehci_readl(const struct
ehci_hcd *ehci,
#endif
}
+#ifdef CONFIG_SOC_IMX28
+static inline void imx28_ehci_writel(u32 val32, volatile u32 *addr)
You should annotate the addr pointer with __iomem, or better use the
signature of ehci_writel():
static inline void imx28_ehci_writel(const unsinged int val32, __u32
__iomem *addr)
Marc
+{
+ __asm__ (swp %0, %0, [%1] : : r(val32), r(addr));
+}
+#endif
+
static inline void ehci_writel(const struct ehci_hcd *ehci,
const unsigned int val, __u32 __iomem *regs)
{
@@ -735,6 +743,11 @@ static inline void ehci_writel(const struct ehci_hcd
*ehci,
ehci_big_endian_mmio(ehci) ?
writel_be(val, regs) :
writel(val, regs);
+#elif defined(CONFIG_SOC_IMX28)
+ if (ehci-imx28_write_fix)
+ imx28_ehci_writel(val, regs);
+ else
+ writel(val, regs);
#else
writel(val, regs);
#endif
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v4 2/3] usb: chipidea: add freescale imx28 special write register method
On 10/30/2013 04:06 AM, Peter Chen wrote:
According to Freescale imx28 Errata, ENGR119653 USB: ARM to USB
register error issue, All USB register write operations must
use the ARM SWP instruction. So, we implement special hw_write
and hw_test_and_clear for imx28.
Discussion for it at below:
http://marc.info/?l=linux-usbm=137996395529294w=2
Signed-off-by: Peter Chen peter.c...@freescale.com
---
Changes for v4:
- introducing __hw_write to encapsulate low level write,
it can reduce the duplicated code.
drivers/usb/chipidea/ci.h| 26 --
drivers/usb/chipidea/core.c |2 ++
drivers/usb/chipidea/host.c |1 +
include/linux/usb/chipidea.h |1 +
4 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 1c94fc5..f9b1914 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -173,6 +173,8 @@ struct ci_hdrc {
struct dentry *debugfs;
boolid_event;
boolb_sess_valid_event;
+ /* imx28 needs swp instruction for writing */
+ boolimx28_write_fix;
};
static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
@@ -253,6 +255,26 @@ static inline u32 hw_read(struct ci_hdrc *ci, enum
ci_hw_regs reg, u32 mask)
return ioread32(ci-hw_bank.regmap[reg]) mask;
}
+#ifdef CONFIG_SOC_IMX28
+static inline void imx28_ci_writel(u32 val32, volatile u32 *addr)
same applies here:
static inline void imx28_ci_writel(u32 val32, void __iomem *addr)
Marc
+{
+ __asm__ (swp %0, %0, [%1] : : r(val32), r(addr));
+}
+#endif
+
+static inline void __hw_write(struct ci_hdrc *ci, u32 val,
+ void __iomem *addr)
+{
+#ifdef CONFIG_SOC_IMX28
+ if (ci-imx28_write_fix)
+ imx28_ci_writel(val, addr);
+ else
+ iowrite32(val, addr);
+#else
+ iowrite32(val, addr);
+#endif
+}
+
/**
* hw_write: writes to a hw register
* @reg: register index
@@ -266,7 +288,7 @@ static inline void hw_write(struct ci_hdrc *ci, enum
ci_hw_regs reg,
data = (ioread32(ci-hw_bank.regmap[reg]) ~mask)
| (data mask);
- iowrite32(data, ci-hw_bank.regmap[reg]);
+ __hw_write(ci, data, ci-hw_bank.regmap[reg]);
}
/**
@@ -281,7 +303,7 @@ static inline u32 hw_test_and_clear(struct ci_hdrc *ci,
enum ci_hw_regs reg,
{
u32 val = ioread32(ci-hw_bank.regmap[reg]) mask;
- iowrite32(val, ci-hw_bank.regmap[reg]);
+ __hw_write(ci, val, ci-hw_bank.regmap[reg]);
return val;
}
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 06204b7..357a059 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -551,6 +551,8 @@ static int ci_hdrc_probe(struct platform_device *pdev)
ci-dev = dev;
ci-platdata = dev-platform_data;
+ ci-imx28_write_fix = !!(ci-platdata-flags
+ CI_HDRC_IMX28_WRITE_FIX);
ret = hw_device_init(ci, base);
if (ret 0) {
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 59e6020..06fd042 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -65,6 +65,7 @@ static int host_start(struct ci_hdrc *ci)
ehci-caps = ci-hw_bank.cap;
ehci-has_hostpc = ci-hw_bank.lpm;
ehci-has_tdi_phy_lpm = ci-hw_bank.lpm;
+ ehci-imx28_write_fix = ci-imx28_write_fix;
if (ci-platdata-reg_vbus) {
ret = regulator_enable(ci-platdata-reg_vbus);
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 7d39967..708bd11 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -24,6 +24,7 @@ struct ci_hdrc_platform_data {
* but otg is not supported (no register otgsc).
*/
#define CI_HDRC_DUAL_ROLE_NOT_OTGBIT(4)
+#define CI_HDRC_IMX28_WRITE_FIX BIT(5)
enum usb_dr_modedr_mode;
#define CI_HDRC_CONTROLLER_RESET_EVENT 0
#define CI_HDRC_CONTROLLER_STOPPED_EVENT 1
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [pandaboard] OTG port not working
Kishon Vijay Abraham I wrote: CONFIG_OMAP_OCP2SCP should also be enabled. Suggestion tried and getting new (interesting) messages from the kernel. Updated the bug: https://bugzilla.kernel.org/show_bug.cgi?id=64771 - Tobias -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] usb: chipidea: imx: set CI_HDRC_IMX28_WRITE_FIX for imx28
On 10/30/2013 04:06 AM, Peter Chen wrote:
Due to imx28 needs ARM swp instruction for writing, we set
CI_HDRC_IMX28_WRITE_FIX for imx28.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/ci_hdrc_imx.c | 32 ++--
1 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 023d3cb..68f7f5e 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -23,6 +23,26 @@
#include ci.h
#include ci_hdrc_imx.h
+#define CI_HDRC_IMX_IMX28_WRITE_FIX BIT(0)
+
+struct ci_hdrc_imx_platform_flag {
+ unsigned int flags;
+};
+
+static const struct ci_hdrc_imx_platform_flag imx27_usb_data = {
+};
+
+static const struct ci_hdrc_imx_platform_flag imx28_usb_data = {
+ .flags = CI_HDRC_IMX_IMX28_WRITE_FIX,
+};
+
+static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
+ { .compatible = fsl,imx28-usb, .data = imx28_usb_data},
+ { .compatible = fsl,imx27-usb, .data = imx27_usb_data},
^^^
Nitpick, please add , or a single space.
Marc
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, ci_hdrc_imx_dt_ids);
+
struct ci_hdrc_imx_data {
struct usb_phy *phy;
struct platform_device *ci_pdev;
@@ -82,6 +102,9 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
CI_HDRC_DISABLE_STREAMING,
};
int ret;
+ const struct of_device_id *of_id =
+ of_match_device(ci_hdrc_imx_dt_ids, pdev-dev);
+ const struct ci_hdrc_imx_platform_flag *imx_platform_flag = of_id-data;
data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
if (!data) {
@@ -115,6 +138,9 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
pdata.phy = data-phy;
+ if (imx_platform_flag-flags CI_HDRC_IMX_IMX28_WRITE_FIX)
+ pdata.flags |= CI_HDRC_IMX28_WRITE_FIX;
+
if (!pdev-dev.dma_mask)
pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
if (!pdev-dev.coherent_dma_mask)
@@ -174,12 +200,6 @@ static int ci_hdrc_imx_remove(struct platform_device
*pdev)
return 0;
}
-static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
- { .compatible = fsl,imx27-usb, },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, ci_hdrc_imx_dt_ids);
-
static struct platform_driver ci_hdrc_imx_driver = {
.probe = ci_hdrc_imx_probe,
.remove = ci_hdrc_imx_remove,
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: gadget: should usb_ep_enable() clear EP STALL?
Hi, On Fri, Nov 01, 2013 at 09:26:41AM +0100, Johannes Stezenbach wrote: Hi, On Thu, Oct 31, 2013 at 10:21:28AM -0500, Felipe Balbi wrote: On Thu, Oct 31, 2013 at 04:02:20PM +0100, Johannes Stezenbach wrote: On Wed, Oct 30, 2013 at 10:44:30PM +0100, Johannes Stezenbach wrote: On Wed, Oct 30, 2013 at 12:54:15PM -0500, Felipe Balbi wrote: Do you have any patches on f_sourcesink which might have caused this bug ? No patches, but maybe out of date code. However, I'm looking at current git master, I see you clear dep-flags but I don't see any dwc3_send_gadget_ep_cmd(DWC3_DEPCMD_CLEARSTALL)? I just tried to add __dwc3_gadget_ep_set_halt(dep, false); right before the call to __dwc3_gadget_ep_disable() in dwc3_gadget_ep_disable(), it seems to fix the issue. It is easily reproducible using the attached Python script, it should print: $ ./dwc3test.py [Errno 32] Pipe error (expected) OK but instead prints: $ ./dwc3test.py [Errno 32] Pipe error (expected) [Errno 32] Pipe error can you send a patch to dwc3 so we can review and possibly apply ? I could create a patch, but I can't test it with the current upstream version because I'm stuck with an old 3.4.x kernel and dwc3 version (not under my control). So my idea was to make it reproducible for you so you can create the patch and test it. If you want you can add Reported-by: or Suggested-by:. All right, I'll add to my todo for this week ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCHv2 2/2] check quirk to pad epout buf size when not aligned to maxpacketsize
Hi Alan, Michal,
On 11/11/2013 01:09 PM, Michal Nazarewicz wrote:
On Mon, Nov 11 2013, Alan Stern wrote:
On Mon, 11 Nov 2013, Michal Nazarewicz wrote:
Check gadget.quirk_ep_out_aligned_size to decide if buffer size requires
to be aligned to maxpacketsize of an out endpoint. ffs_epfile_io() needs
to pad epout buffer to match above condition if quirk is found.
Signed-off-by: Michal Nazarewicz min...@mina86.com
I think this is still wrong.
@@ -824,7 +832,7 @@ static ssize_t ffs_epfile_io(struct file *file,
req-context = done;
req-complete = ffs_epfile_io_complete;
req-buf = data;
- req-length = len;
+ req-length = data_len;
IIUC, req-length should still be set to len, not to data_len.
I misunderstood the first time I read it:
In order to avoid DWC3 to stall, we need to update req-length (this is
the most important fix). kmalloc() is updated too to prevent USB
controller to overflow buffer boundaries.
ret = usb_ep_queue(ep-ep, req, GFP_ATOMIC);
@@ -836,9 +844,16 @@ static ssize_t ffs_epfile_io(struct file *file,
ret = -EINTR;
usb_ep_dequeue(ep-ep, req);
} else {
+ /*
+* XXX We may end up silently droping data here.
+* Since data_len (i.e. req-length) may be bigger
+* than len (after being rounded up to maxpacketsize),
+* we may end up with more data then user space has
+* space for.
+*/
Then this will never come up. If the host sends a packet that's too
long, you'll get a -EOVERFLOW error.
ret = ep-status;
if (read ret 0
- unlikely(copy_to_user(buf, data, ret)))
+ unlikely(copy_to_user(buf, data, min(ret, len
ret = -EFAULT;
}
}
The reason for the quirk is that the controller may write all the
incoming data to the buffer, even if this is more data than the driver
requested.
If that's the case, then it indeed solves the problem of silently
throwing away data. I guess it makes more sense then my understanding
of the quirk.
The main reason of this quirk it to prevent DWC3 to stall or to
overflow buffer after usb_ep_queue() above. Since req-length has to be
updated, I disagree with Alan in this case and give my ack to this
Michal's approach.
Br, David Cohen
--
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: gadget: composite: reset delayed_status on reset_config
The delayed_status value is used to keep track of status response packets on ep0. It needs to be reset or the set_config function would still delay the answer, if the usb device got unplugged while waiting for setup_continue to be called. Cc: sta...@vger.kernel.org Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de --- drivers/usb/gadget/composite.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c index 3e7ae70..2018ba1 100644 --- a/drivers/usb/gadget/composite.c +++ b/drivers/usb/gadget/composite.c @@ -593,6 +593,7 @@ static void reset_config(struct usb_composite_dev *cdev) bitmap_zero(f-endpoints, 32); } cdev-config = NULL; + cdev-delayed_status = 0; } static int set_config(struct usb_composite_dev *cdev, -- 1.8.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: gadget: f_fs: remove loop from I/O function
Hi Michal,
On 11/10/2013 08:50 AM, Michal Nazarewicz wrote:
From: Michal Nazarewicz min...@mina86.com
When endpoint changes (due to it being disabled or alt setting changed),
mimic the action as if the change happened after the request has been
queued, instead of retrying with the new endpoint.
Signed-off-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/f_fs.c | 94 +--
1 file changed, 41 insertions(+), 53 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 44cf775..f875f26 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -754,74 +754,61 @@ static ssize_t ffs_epfile_io(struct file *file,
{
struct ffs_epfile *epfile = file-private_data;
struct ffs_ep *ep;
- char *data = NULL;
ssize_t ret;
+ char *data;
You can't non-initialize data, otherwise we'll end up with this correct
warning:
drivers/usb/gadget/f_fs.c:866:7: warning: 'data' may be used
uninitialized in this function [-Wmaybe-uninitialized]
If you agree, you can send v5.1 to my 5th patch set (or let me handle
it).
Br, David
--
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: [PATCHv2 2/2] check quirk to pad epout buf size when not aligned to maxpacketsize
On 11/11/2013 03:21 AM, Michal Nazarewicz wrote:
Check gadget.quirk_ep_out_aligned_size to decide if buffer size requires
to be aligned to maxpacketsize of an out endpoint. ffs_epfile_io() needs
to pad epout buffer to match above condition if quirk is found.
Signed-off-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/f_fs.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
On 11/10/2013 08:50 AM, Michal Nazarewicz wrote:
@@ -787,6 +788,13 @@ static ssize_t ffs_epfile_io(struct file *file,
/* Allocate copy */
if (!halt) {
+ /*
+* Controller requires buffer size to be aligned to
+* maxpacketsize of an out endpoint.
+*/
+ data_len = read gadget-quirk_ep_out_aligned_size ?
+ usb_ep_align_maxpacketsize(ep-ep, len) : len;
+
data = kmalloc(len, GFP_KERNEL);
On Mon, Nov 11 2013, David Cohen david.a.co...@linux.intel.com wrote:
Shouldn't this kmalloc() allocate 'data_len' bytes, instead of 'len'?
Yes, of coures.
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index e496b72..fd769a8 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
[snip]
ret = ep-status;
if (read ret 0
- unlikely(copy_to_user(buf, data, ret)))
+ unlikely(copy_to_user(buf, data, min(ret, len
You need to replace min(ret, len) by min_t(size_t, ret, len) to avoid
this warning:
drivers/usb/gadget/f_fs.c:858:124: warning: comparison of distinct
pointer types lacks a cast [enabled by default]
Once again, you (or me) need to reply to my v5 patch set.
Br, David
--
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 v5 3/5] usb: gadget: f_fs: remove loop from I/O function
On 11/11/2013 12:16 PM, David Cohen wrote:
From: Michal Nazarewicz min...@mina86.com
When endpoint changes (due to it being disabled or alt setting changed),
mimic the action as if the change happened after the request has been
queued, instead of retrying with the new endpoint.
Signed-off-by: Michal Nazarewicz min...@mina86.com
Cc: David Cohen david.a.co...@linux.intel.com
---
drivers/usb/gadget/f_fs.c | 94 +--
1 file changed, 41 insertions(+), 53 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 75e4b7846a8d..f1563c47e0c2 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -756,74 +756,61 @@ static ssize_t ffs_epfile_io(struct file *file,
{
struct ffs_epfile *epfile = file-private_data;
struct ffs_ep *ep;
- char *data = NULL;
ssize_t ret;
+ char *data;
int halt;
- goto first_try;
- do {
- spin_unlock_irq(epfile-ffs-eps_lock);
- mutex_unlock(epfile-mutex);
+ /* Are we still active? */
+ if (WARN_ON(epfile-ffs-state != FFS_ACTIVE)) {
+ ret = -ENODEV;
+ goto error;
+ }
-first_try:
- /* Are we still active? */
- if (WARN_ON(epfile-ffs-state != FFS_ACTIVE)) {
- ret = -ENODEV;
+ /* Wait for endpoint to be enabled */
+ ep = epfile-ep;
+ if (!ep) {
+ if (file-f_flags O_NONBLOCK) {
+ ret = -EAGAIN;
goto error;
}
- /* Wait for endpoint to be enabled */
- ep = epfile-ep;
- if (!ep) {
- if (file-f_flags O_NONBLOCK) {
- ret = -EAGAIN;
- goto error;
- }
-
- if (wait_event_interruptible(epfile-wait,
-(ep = epfile-ep))) {
- ret = -EINTR;
- goto error;
- }
- }
-
- /* Do we halt? */
- halt = !read == !epfile-in;
- if (halt epfile-isoc) {
- ret = -EINVAL;
+ if (wait_event_interruptible(epfile-wait, (ep = epfile-ep))) {
+ ret = -EINTR;
goto error;
}
+ }
- /* Allocate copy */
- if (!halt !data) {
- data = kzalloc(len, GFP_KERNEL);
- if (unlikely(!data))
- return -ENOMEM;
+ /* Do we halt? */
+ halt = !read == !epfile-in;
One curiosity here. This patch prints the following warning:
In file included from (...)/drivers/usb/gadget/g_ffs.c:55:0:
(...)/drivers/usb/gadget/f_fs.c: In function 'ffs_epfile_io.isra.18':
(...)/drivers/usb/gadget/f_fs.c:837:15: warning: 'data_len' may be used
uninitialized in this function [-Wmaybe-uninitialized]
But if we do this dummy change on it:
@@ -782,7 +782,10 @@ static ssize_t ffs_epfile_io(struct file *file,
}
/* Do we halt? */
- halt = !read == !epfile-in;
+ if (!read == !epfile-in)
+ halt = 1;
+ else
+ halt = 0;
if (halt epfile-isoc) {
ret = -EINVAL;
goto error;
The warning goes away. This false-positive warning comes out of this
gcc version:
$ i686-linux-android-gcc --version
i686-linux-android-gcc (GCC) 4.7
Br, David Cohen
+ if (halt epfile-isoc) {
+ ret = -EINVAL;
+ goto error;
+ }
- if (!read
- unlikely(__copy_from_user(data, buf, len))) {
- ret = -EFAULT;
- goto error;
- }
- }
+ /* Allocate copy */
+ if (!halt) {
+ data = kmalloc(len, GFP_KERNEL);
+ if (unlikely(!data))
+ return -ENOMEM;
- /* We will be using request */
- ret = ffs_mutex_lock(epfile-mutex,
-file-f_flags O_NONBLOCK);
- if (unlikely(ret))
+ if (!read unlikely(copy_from_user(data, buf, len))) {
+ ret = -EFAULT;
goto error;
+ }
+ }
- /*
-* We're called from user space, we can use _irq rather then
-* _irqsave
-*/
- spin_lock_irq(epfile-ffs-eps_lock);
+ /* We will be using request */
+ ret = ffs_mutex_lock(epfile-mutex, file-f_flags O_NONBLOCK);
+ if (unlikely(ret))
+ goto error;
+ spin_lock_irq(epfile-ffs-eps_lock);
- /*
-
Re: [PATCH v5 2/5] usb: gadget: add quirk_ep_out_aligned_size field to struct usb_gadget
On Mon, Nov 11 2013, David Cohen wrote:
Due to USB controllers may have different restrictions, usb gadget layer
needs to provide a generic way to inform gadget functions to complain
with non-standard requirements.
This patch adds 'quirk_ep_out_aligned_size' field to struct usb_gadget
to inform when controller's epout requires buffer size to be aligned to
MaxPacketSize. A helper is also provided to align buffer size when
necessary.
Signed-off-by: David Cohen david.a.co...@linux.intel.com
Acked-by: Alan Stern st...@rowland.harvard.edu
Acked-by: Michal Nazarewicz min...@mina86.com
---
Michal,
I added prefix 'usb: f_fs: ' to patch's subject. I did not add 'usb: gadget:
f_fs' due to it would be too long.
include/linux/usb/gadget.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 23b3bfd0a842..41e8834af57d 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -441,6 +441,19 @@ static inline void usb_ep_fifo_flush(struct usb_ep *ep)
ep-ops-fifo_flush(ep);
}
+/**
+ * usb_ep_align_maxpacketsize - returns @len aligned to ep's maxpacketsize
+ * @ep: the endpoint whose maxpacketsize is used to align @len
+ * @len: buffer size's length to align to @ep's maxpacketsize
+ *
+ * This helper is used in case it's required for any reason to align buffer's
+ * size to an ep's maxpacketsize.
+ */
+static inline size_t usb_ep_align_maxpacketsize(struct usb_ep *ep, size_t
len)
+{
+ return round_up(len, (size_t)ep-desc-wMaxPacketSize);
+}
+
Come to think of it, perhaps even better helper would be:
static inline size_t usb_ep_align_maybe(
struct usb_gadget *gadget, struct usb_ep *ep, size_t len) {
return gadget-quir_ep_out_aligned_size ?
round_up(len, (size_t)ep-desc-wMaxPacketSize) : len;
}
/*-*/
@@ -502,6 +515,8 @@ struct usb_gadget_ops {
* only supports HNP on a different root port.
* @b_hnp_enable: OTG device feature flag, indicating that the A-Host
* enabled HNP support.
+ * @quirk_ep_out_aligned_size: epout requires buffer size to be aligned to
+ * MaxPacketSize.
*
* Gadgets have a mostly-portable gadget driver implementing device
* functions, handling all usb configurations and interfaces. Gadget
@@ -541,6 +556,7 @@ struct usb_gadget {
unsignedb_hnp_enable:1;
unsigneda_hnp_support:1;
unsigneda_alt_hnp_support:1;
+ unsignedquirk_ep_out_aligned_size:1;
};
#define work_to_gadget(w)(container_of((w), struct usb_gadget, work))
--
1.8.4.rc3
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo--
signature.asc
Description: PGP signature
[PATCHv5.1 3/5] usb: gadget: f_fs: remove loop from I/O function
When endpoint changes (due to it being disabled or alt setting changed),
mimic the action as if the change happened after the request has been
queued, instead of retrying with the new endpoint.
Signed-off-by: Michal Nazarewicz min...@mina86.com
Cc: David Cohen david.a.co...@linux.intel.com
---
drivers/usb/gadget/f_fs.c | 94 ---
1 file changed, 40 insertions(+), 54 deletions(-)
Fixed checkpatch.pl issues pointed out by David.
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 0658908..6cb0b22 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -758,73 +758,59 @@ static ssize_t ffs_epfile_io(struct file *file,
ssize_t ret;
int halt;
- goto first_try;
- do {
- spin_unlock_irq(epfile-ffs-eps_lock);
- mutex_unlock(epfile-mutex);
+ /* Are we still active? */
+ if (WARN_ON(epfile-ffs-state != FFS_ACTIVE)) {
+ ret = -ENODEV;
+ goto error;
+ }
-first_try:
- /* Are we still active? */
- if (WARN_ON(epfile-ffs-state != FFS_ACTIVE)) {
- ret = -ENODEV;
+ /* Wait for endpoint to be enabled */
+ ep = epfile-ep;
+ if (!ep) {
+ if (file-f_flags O_NONBLOCK) {
+ ret = -EAGAIN;
goto error;
}
- /* Wait for endpoint to be enabled */
- ep = epfile-ep;
- if (!ep) {
- if (file-f_flags O_NONBLOCK) {
- ret = -EAGAIN;
- goto error;
- }
-
- if (wait_event_interruptible(epfile-wait,
-(ep = epfile-ep))) {
- ret = -EINTR;
- goto error;
- }
- }
-
- /* Do we halt? */
- halt = !read == !epfile-in;
- if (halt epfile-isoc) {
- ret = -EINVAL;
+ ret = wait_event_interruptible(epfile-wait, (ep = epfile-ep));
+ if (ret) {
+ ret = -EINTR;
goto error;
}
+ }
- /* Allocate copy */
- if (!halt !data) {
- data = kzalloc(len, GFP_KERNEL);
- if (unlikely(!data))
- return -ENOMEM;
+ /* Do we halt? */
+ halt = !read == !epfile-in;
+ if (halt epfile-isoc) {
+ ret = -EINVAL;
+ goto error;
+ }
- if (!read
- unlikely(__copy_from_user(data, buf, len))) {
- ret = -EFAULT;
- goto error;
- }
- }
+ /* Allocate copy */
+ if (!halt) {
+ data = kmalloc(len, GFP_KERNEL);
+ if (unlikely(!data))
+ return -ENOMEM;
- /* We will be using request */
- ret = ffs_mutex_lock(epfile-mutex,
-file-f_flags O_NONBLOCK);
- if (unlikely(ret))
+ if (!read unlikely(copy_from_user(data, buf, len))) {
+ ret = -EFAULT;
goto error;
+ }
+ }
- /*
-* We're called from user space, we can use _irq rather then
-* _irqsave
-*/
- spin_lock_irq(epfile-ffs-eps_lock);
+ /* We will be using request */
+ ret = ffs_mutex_lock(epfile-mutex, file-f_flags O_NONBLOCK);
+ if (unlikely(ret))
+ goto error;
- /*
-* While we were acquiring mutex endpoint got disabled
-* or changed?
-*/
- } while (unlikely(epfile-ep != ep));
+ spin_lock_irq(epfile-ffs-eps_lock);
- /* Halt */
- if (unlikely(halt)) {
+ if (epfile-ep != ep) {
+ /* In the meantime, endpoint got disabled or changed. */
+ ret = -ESHUTDOWN;
+ spin_unlock_irq(epfile-ffs-eps_lock);
+ } else if (halt) {
+ /* Halt */
if (likely(epfile-ep == ep) !WARN_ON(!ep-ep))
usb_ep_set_halt(ep-ep);
spin_unlock_irq(epfile-ffs-eps_lock);
--
1.8.4.1
--
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
[PATCHv5.1 4/5] check quirk to pad epout buf size when not aligned to maxpacketsize
Check gadget.quirk_ep_out_aligned_size to decide if buffer size requires
to be aligned to maxpacketsize of an out endpoint. ffs_epfile_io() needs
to pad epout buffer to match above condition if quirk is found.
Signed-off-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/f_fs.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
On Tue, Nov 12 2013, David Cohen wrote:
One curiosity here. This patch prints the following warning:
In file included from (...)/drivers/usb/gadget/g_ffs.c:55:0:
(...)/drivers/usb/gadget/f_fs.c: In function 'ffs_epfile_io.isra.18':
(...)/drivers/usb/gadget/f_fs.c:837:15: warning: 'data_len' may be used
uninitialized in this function [-Wmaybe-uninitialized]
With the below code, this should no longer be a problem.
Also fixes issues pointed out by Alan.
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 6cb0b22..9aa3200 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -753,6 +753,7 @@ static ssize_t ffs_epfile_io(struct file *file,
char __user *buf, size_t len, int read)
{
struct ffs_epfile *epfile = file-private_data;
+ struct usb_gadget *gadget = epfile-ffs-gadget;
struct ffs_ep *ep;
char *data = NULL;
ssize_t ret;
@@ -788,7 +789,14 @@ static ssize_t ffs_epfile_io(struct file *file,
/* Allocate copy */
if (!halt) {
- data = kmalloc(len, GFP_KERNEL);
+ /*
+* Controller requires buffer size to be aligned to
+* maxpacketsize of an out endpoint.
+*/
+ size_t data_len = read gadget-quirk_ep_out_aligned_size ?
+ usb_ep_align_maxpacketsize(ep-ep, len) : len;
+
+ data = kmalloc(data_len, GFP_KERNEL);
if (unlikely(!data))
return -ENOMEM;
--
1.8.4.1
--
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 v5 2/5] usb: gadget: add quirk_ep_out_aligned_size field to struct usb_gadget
On 11/11/2013 03:55 PM, Michal Nazarewicz wrote:
On Mon, Nov 11 2013, David Cohen wrote:
Due to USB controllers may have different restrictions, usb gadget layer
needs to provide a generic way to inform gadget functions to complain
with non-standard requirements.
This patch adds 'quirk_ep_out_aligned_size' field to struct usb_gadget
to inform when controller's epout requires buffer size to be aligned to
MaxPacketSize. A helper is also provided to align buffer size when
necessary.
Signed-off-by: David Cohen david.a.co...@linux.intel.com
Acked-by: Alan Stern st...@rowland.harvard.edu
Acked-by: Michal Nazarewicz min...@mina86.com
---
Michal,
I added prefix 'usb: f_fs: ' to patch's subject. I did not add 'usb: gadget:
f_fs' due to it would be too long.
include/linux/usb/gadget.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 23b3bfd0a842..41e8834af57d 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -441,6 +441,19 @@ static inline void usb_ep_fifo_flush(struct usb_ep *ep)
ep-ops-fifo_flush(ep);
}
+/**
+ * usb_ep_align_maxpacketsize - returns @len aligned to ep's maxpacketsize
+ * @ep: the endpoint whose maxpacketsize is used to align @len
+ * @len: buffer size's length to align to @ep's maxpacketsize
+ *
+ * This helper is used in case it's required for any reason to align buffer's
+ * size to an ep's maxpacketsize.
+ */
+static inline size_t usb_ep_align_maxpacketsize(struct usb_ep *ep, size_t len)
+{
+ return round_up(len, (size_t)ep-desc-wMaxPacketSize);
+}
+
Come to think of it, perhaps even better helper would be:
static inline size_t usb_ep_align_maybe(
struct usb_gadget *gadget, struct usb_ep *ep, size_t len) {
return gadget-quir_ep_out_aligned_size ?
round_up(len, (size_t)ep-desc-wMaxPacketSize) : len;
}
The CPU time to check unsigned:1 and possibly jump is about the same as
round_up() itself. For readability matters, we can round_up() directly.
Br, David
--
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: [PATCHv5.1 4/5] check quirk to pad epout buf size when not aligned to maxpacketsize
Hi Michal, On 11/11/2013 03:58 PM, Michal Nazarewicz wrote: Check gadget.quirk_ep_out_aligned_size to decide if buffer size requires to be aligned to maxpacketsize of an out endpoint. ffs_epfile_io() needs to pad epout buffer to match above condition if quirk is found. Signed-off-by: Michal Nazarewicz min...@mina86.com --- drivers/usb/gadget/f_fs.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) On Tue, Nov 12 2013, David Cohen wrote: One curiosity here. This patch prints the following warning: In file included from (...)/drivers/usb/gadget/g_ffs.c:55:0: (...)/drivers/usb/gadget/f_fs.c: In function 'ffs_epfile_io.isra.18': (...)/drivers/usb/gadget/f_fs.c:837:15: warning: 'data_len' may be used uninitialized in this function [-Wmaybe-uninitialized] With the below code, this should no longer be a problem. Also fixes issues pointed out by Alan. You need to update req-length otherwise it's going to crash DWC3. I'd rather to keep your previous version. Br, David -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] usb: ehci: add freescale imx28 special write register method
On Mon, Nov 11, 2013 at 10:32:51PM +0100, Marc Kleine-Budde wrote:
On 10/30/2013 04:06 AM, Peter Chen wrote:
According to Freescale imx28 Errata, ENGR119653 USB: ARM to USB
register error issue, All USB register write operations must
use the ARM SWP instruction. So, we implement a special ehci_write
for imx28.
Discussion for it at below:
http://marc.info/?l=linux-usbm=137996395529294w=2
Signed-off-by: Peter Chen peter.c...@freescale.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci.h | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index e8f41c5..535aa8b 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -225,6 +225,7 @@ struct ehci_hcd { /* one per
controller */
unsignedhas_synopsys_hc_bug:1; /* Synopsys HC */
unsignedframe_index_bug:1; /* MosChip (AKA NetMos) */
unsignedneed_oc_pp_cycle:1; /* MPC834X port power */
+ unsignedimx28_write_fix:1; /* For Freescale i.MX28 */
/* required for usb32 quirk */
#define OHCI_CTRL_HCFS (3 6)
@@ -728,6 +729,13 @@ static inline unsigned int ehci_readl(const struct
ehci_hcd *ehci,
#endif
}
+#ifdef CONFIG_SOC_IMX28
+static inline void imx28_ehci_writel(u32 val32, volatile u32 *addr)
You should annotate the addr pointer with __iomem, or better use the
signature of ehci_writel():
static inline void imx28_ehci_writel(const unsinged int val32, __u32
__iomem *addr)
I agree, but volatile is needed as it needs to read/write from io address.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] usb: chipidea: imx: set CI_HDRC_IMX28_WRITE_FIX for imx28
On Mon, Nov 11, 2013 at 10:37:07PM +0100, Marc Kleine-Budde wrote:
On 10/30/2013 04:06 AM, Peter Chen wrote:
Due to imx28 needs ARM swp instruction for writing, we set
CI_HDRC_IMX28_WRITE_FIX for imx28.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/ci_hdrc_imx.c | 32 ++--
1 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 023d3cb..68f7f5e 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -23,6 +23,26 @@
#include ci.h
#include ci_hdrc_imx.h
+#define CI_HDRC_IMX_IMX28_WRITE_FIX BIT(0)
+
+struct ci_hdrc_imx_platform_flag {
+ unsigned int flags;
+};
+
+static const struct ci_hdrc_imx_platform_flag imx27_usb_data = {
+};
+
+static const struct ci_hdrc_imx_platform_flag imx28_usb_data = {
+ .flags = CI_HDRC_IMX_IMX28_WRITE_FIX,
+};
+
+static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
+ { .compatible = fsl,imx28-usb, .data = imx28_usb_data},
+ { .compatible = fsl,imx27-usb, .data = imx27_usb_data},
^^^
Nitpick, please add , or a single space.
Thanks, will change.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: chipidea: udc: first start device on pullup
On Mon, Nov 11, 2013 at 04:37:26PM +0100, Michael Grzeschik wrote:
On Mon, Nov 11, 2013 at 09:42:35PM +0800, Peter Chen wrote:
On Mon, Nov 11, 2013 at 12:39:30PM +0100, Michael Grzeschik wrote:
Don't pullup the resistors on hw_device_state. The gadget framework has
the prepared callback for this. This is necessary if we use gadgets
which need to be enabled after an userspace application got prepared, or
other delayed conditiions have passed.
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
---
drivers/usb/chipidea/udc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index b34c819..976153f 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -84,10 +84,8 @@ static int hw_device_state(struct ci_hdrc *ci, u32 dma)
/* interrupt, error, port change, reset, sleep/suspend */
hw_write(ci, OP_USBINTR, ~0,
USBi_UI|USBi_UEI|USBi_PCI|USBi_URI|USBi_SLI);
- hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
} else {
hw_write(ci, OP_USBINTR, ~0, 0);
- hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
}
return 0;
}
Hi Michael, you submitted a similar patch before to fix uvc problem,
but you can't simply delete it, it will cause the udc can't work
if we load gadget first, then plug in the usb cable.
Yes, you also mentioned this the last time. But here, when the
gadget was loaded first and plugged in afterwarts works as well.
It can't work at my place, how it can work? There is no place to
set usbcmd.rs, you can read the register usbcmd after load gadget module.
Did you see when the pullup function get called? I did also send a
patch that is changing the pullup call inside the gadget drivers.
Current, usbcmd.rs is only set by two places at udc.c
- hw_device_state
- ci_duc_pullup (if vbus is there)
If you delete it at hw_device_state, the usb_gadget_connect can't
set it without vbus. I don't know why it can work at your place
since there is no place to set USBCMD_RS if we load gadget first, then
plug in usb cable.
Besides, if the port support dual role switch, if the gadget is loaded
first, then do peripheral-host and host-peripheral,(the usbcmd.rs is cleared
at that time), then connect vbus, no place to pull up dp.
To fix it, it is better mark that gadget as defer_connect, and
introduce such condition at udc driver.
No, I don't see why this needs to be specially handled inside this
driver. We have the framework for this. USBCMD_RS does pullup the
DP resistor.
The datasheet says, that we have to ensure that the device needs to be
properly setup before touching this bit. As the framework does call
usb_gadget_connect after the gadget has started and connected to the udc
this should be the case.
We all hope all things can be done at udc core, but it still has lots
of work to do, we had a discussion it before, see below thread:
http://marc.info/?l=linux-usbm=136335043303602w=2
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/16] usb/gadget: FunctionFS: Remove VLAIS usage from gadget code
W dniu 08.11.2013 16:38, Sebastian Andrzej Siewior pisze: On 11/08/2013 04:01 PM, Andrzej Pietrasiewicz wrote: Hello Sebastian, Hallo Andrzej, Please correct me if I'm wrong but I think it is not possible to use usb_gstrings_attach(). Basically, usb_gstrings_attach() requires struct usb_gadget_strings **sp on input, then it does copy_gadget_strings(sp, n_gstrings, n_strings); and then does its job. So actually to do usb_gstrings_attach() you need to _already_ have struct usb_gadget_strings **sp. FunctionFS is different in that it takes data to _build_ usb_gadget_strings **stringtabs from userspace (the char *const _data). In other words, the string descriptors are provided from userspace as a character buffer which needs to be parsed and it is what __ffs_data_got_strings() does. You are right. So you would have to assume sane upper values for str_count and lang_count or allocate the three arrays separately. Later you need to parse that buffer anyway so there is not much win except that the strings are handled the same way like in other places. We don't need to copy the strings again with usb_gstrings_attach() because each FunctionFS instance uses its own copy by design: ffs-stringtabs Andrzej -- 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: chipidea: udc: first start device on pullup
On Mon, Nov 11, 2013 at 02:00:36PM -0600, Felipe Balbi wrote: On Mon, Nov 11, 2013 at 12:39:30PM +0100, Michael Grzeschik wrote: Don't pullup the resistors on hw_device_state. The gadget framework has the prepared callback for this. This is necessary if we use gadgets which need to be enabled after an userspace application got prepared, or other delayed conditiions have passed. s/conditiions/conditions other than that, Acked-by: Felipe Balbi ba...@ti.com As Peter mentioned, this Patch can not work this way. So for now we have to NAK it. -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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
