Re: JMicron 20337 (152d:2338) and 3TB

[Alon Bar-Lev]

On Sun, Sep 2, 2012 at 11:57 PM, Alan Stern st...@rowland.harvard.edu wrote:
 On Sun, 2 Sep 2012, Alon Bar-Lev wrote:

  This shows the computer asking the drive to read 8 blocks starting at
  block 0.  The drive (actually the JMicron USB interface, not the drive
  itself) returns an error code indicating that it thinks the command
  was not sent properly -- even though it was.
 
  I don't understand why the JMicron unit doesn't accept this command.
  It simply appears to be broken.  Does it work if you plug it into a
  computer running Windows or Mac OS X?
 
  Alan Stern
 

 Hi,

 I don't know... I don't use these... and the disk is ext4...

 I have XP in qemu, I mapped the device and took usbmon (attached), so
 you probably see plugin within Linux, the plugout, then windows takes
 charge.

 I see the disk in device manager, but not in disk manager... don't know why.

 Maybe this will help...

 Yes, this shows what the problem is.  It's a bug in the JMicron device.

 The usbmon trace shows that Windows uses READ FORMAT CAPACITIES and
 READ CAPACITY(10) commands to determine the size of the drive.  These
 commands are not capable of reporting sizes larger than 2 TB, but they
 also say what the drive's block size is.  They both say that the block
 size is 4096 bytes.

 Without your patch, Linux would also use READ CAPACITY(10).  When it
 sees that the size is larger than 2 TB, it issues a READ CAPACITY(16)
 command, which _is_ capable of reporting the correct size of the drive.
 (With your patch, Linux tries READ CAPACITY(16) right away.)  At any
 rate, it accepts the READ CAPACITY(16) results.

 But...  READ CAPACITY(16) reports that the block size is 512 bytes, not
 4096!  Linux believes this value, and so when it wants to read 4096
 bytes, it asks for 8 blocks.  That's why the JMicron refused to carry
 out the read -- it realized that 8 blocks would be 32768 bytes, not
 4096 bytes.

 Windows, on the other hand, believes the results from the other two
 commands and therefore knows that the block size is 4096.  Therefore it
 is able to use the drive properly (although the usbmon trace doesn't
 show any place where Windows determines the drive's actual size).

 I can't see any reasonable way of fixing this problem.  Even if Linux
 did settle for the READ CAPACITY(10) value, it would then think that
 the drive was only 2 TB.

 Alan Stern


Thank you so much for the information!

I guess I return this device.

Alon.
--
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: some questions about xhci bandwidth

[loody]

hi Andiry:

2012/9/3 Andiry Xu and...@gmail.com:
 On Wed, Aug 29, 2012 at 6:53 AM, loody milo...@gmail.com wrote:
 hi all:
 I saw there are 2 trbs about bandwidth as below:

 #define TRB_GET_BW  21
 #define TRB_BANDWIDTH_EVENT 35

 Would any one tell me where I can see driver use these 2 trbs for
 bandwidth checking,
 since I cannot grep the implementation in the driver.


 It's defined by xHCI spec but currently not used by driver. They're
 less important.
from the protocol type, it seems to implement split transaction.
if it is, when I plug a HS hub with FS device on its downstream ports,
the driver need these packets to know whether it is ok to schedule
traffic for this device.
If I guest wrong, please let me know.

Thanks for your help,
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net] net: usbnet: fix softirq storm on suspend

[Bjørn Mork]

Suspending an open usbnet device results in constant
rescheduling of usbnet_bh.

commit 65841fd5 usbnet: handle remote wakeup asap
refactored the usbnet_bh code to allow sharing the
urb allocate and submit code with usbnet_resume. In
this process, a test for, and immediate return on,
ENOLINK from rx_submit was unintentionally dropped.

The rx queue will not grow if rx_submit fails,
making usbnet_bh reschedule itself.  This results
in a softirq storm if the error is persistent.
rx_submit translates the usb_submit_urb error
EHOSTUNREACH into ENOLINK, so this is an expected
and persistent error for a suspended device. The
old code tested for this condition and avoided
rescheduling.  Putting this test back.

Cc: sta...@vger.kernel.org # v3.5
Cc: Ming Lei ming@canonical.com
Cc: Oliver Neukum oneu...@suse.de
Signed-off-by: Bjørn Mork bj...@mork.no
---
Sorry for not noticing this before, but commit 65841fd5
makes usbnet autosuspend completely unusable.  The device
is suspended fine, but burning one CPU core at full load
uses a tiny bit more power making the power saving 
negative...

I hope this can go into 3.6 and 3.5-stable ASAP. It is
a hard to notice regression, but all the same a serious
one.


Thanks,
Bjørn


 drivers/net/usb/usbnet.c |   16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index fd4b26d..fc9f578 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1201,19 +1201,26 @@ deferred:
 }
 EXPORT_SYMBOL_GPL(usbnet_start_xmit);
 
-static void rx_alloc_submit(struct usbnet *dev, gfp_t flags)
+static int rx_alloc_submit(struct usbnet *dev, gfp_t flags)
 {
struct urb  *urb;
int i;
+   int ret = 0;
 
/* don't refill the queue all at once */
for (i = 0; i  10  dev-rxq.qlen  RX_QLEN(dev); i++) {
urb = usb_alloc_urb(0, flags);
if (urb != NULL) {
-   if (rx_submit(dev, urb, flags) == -ENOLINK)
-   return;
+   ret = rx_submit(dev, urb, flags);
+   if (ret)
+   goto err;
+   } else {
+   ret = -ENOMEM;
+   goto err;
}
}
+err:
+   return ret;
 }
 
 /*-*/
@@ -1257,7 +1264,8 @@ static void usbnet_bh (unsigned long param)
int temp = dev-rxq.qlen;
 
if (temp  RX_QLEN(dev)) {
-   rx_alloc_submit(dev, GFP_ATOMIC);
+   if (rx_alloc_submit(dev, GFP_ATOMIC) == -ENOLINK)
+   return;
if (temp != dev-rxq.qlen)
netif_dbg(dev, link, dev-net,
  rxqlen %d -- %d\n,
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

OMAP: USB: EHCI: usbhost suspend/resume

[Karol Wrona]

Hi,

I'm facing some problems with USB power management on OMAP3 (Beagleboard-Xm).
Lately I have tried kernel 3.6-rc3 for omap but usb bus suspend/resume is 
switched off there due to some problems with clocks:
This is described in:
[PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
(http://thread.gmane.org/gmane.linux.usb.general/66239/focus=66866)

Does anyone know if usb pm has worked in any kernel version from 2.6.37 for
omap.

I know that 2.6.37 is quite old as concerns usb pm but partially it works
there - there are some problems with clocks to usbhost which are managed 
form ehci driver level (not system pm). I would prefer to fix this in 
2.6.37 because of other android related issues. The problem occurs when 
sleep_when_idle is on and core, usbhost power domains hit retention 
and usb device (with autosuspend) is connected to host port. The clocks 
to usbhost are enabled/disabled but sometimes usbhost_48m_fck can't be 
enabled (randomly) and whole usbhost register operations are unstable.

Other thing is that when sleep_when_idle is 0 (disabled) and usb pm is 
enabled it always fail and I can see cm: Module associated with clock
usbhost_48m_fck didn't enable in 10 tries clk reg is fa005420 but
I can't figure out which other thing is related with usbhost_48m_fck that it
fails to enable the clock.

Karol 


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next] net: cx82310_eth: use common match macro

[Bjørn Mork]

Signed-off-by: Bjørn Mork bj...@mork.no
---
 drivers/net/usb/cx82310_eth.c |   11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/net/usb/cx82310_eth.c b/drivers/net/usb/cx82310_eth.c
index 49ab45e..1e207f0 100644
--- a/drivers/net/usb/cx82310_eth.c
+++ b/drivers/net/usb/cx82310_eth.c
@@ -302,18 +302,9 @@ static const struct driver_infocx82310_info = {
.tx_fixup   = cx82310_tx_fixup,
 };
 
-#define USB_DEVICE_CLASS(vend, prod, cl, sc, pr) \
-   .match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
-  USB_DEVICE_ID_MATCH_DEV_INFO, \
-   .idVendor = (vend), \
-   .idProduct = (prod), \
-   .bDeviceClass = (cl), \
-   .bDeviceSubClass = (sc), \
-   .bDeviceProtocol = (pr)
-
 static const struct usb_device_id products[] = {
{
-   USB_DEVICE_CLASS(0x0572, 0xcb01, 0xff, 0, 0),
+   USB_DEVICE_AND_INTERFACE_INFO(0x0572, 0xcb01, 0xff, 0, 0),
.driver_info = (unsigned long) cx82310_info
},
{ },
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next 1/2] net: sierra_net: make private symbols static

[Bjørn Mork]

Signed-off-by: Bjørn Mork bj...@mork.no
---
 drivers/net/usb/sierra_net.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c
index 7be49ea..596ddaa 100644
--- a/drivers/net/usb/sierra_net.c
+++ b/drivers/net/usb/sierra_net.c
@@ -560,7 +560,7 @@ static void sierra_net_defer_kevent(struct usbnet *dev, int 
work)
 /*
  * Sync Retransmit Timer Handler. On expiry, kick the work queue
  */
-void sierra_sync_timer(unsigned long syncdata)
+static void sierra_sync_timer(unsigned long syncdata)
 {
struct usbnet *dev = (struct usbnet *)syncdata;
 
@@ -866,8 +866,8 @@ static int sierra_net_rx_fixup(struct usbnet *dev, struct 
sk_buff *skb)
 }
 
 /*  Transmit data path --*/
-struct sk_buff *sierra_net_tx_fixup(struct usbnet *dev, struct sk_buff *skb,
-   gfp_t flags)
+static struct sk_buff *sierra_net_tx_fixup(struct usbnet *dev,
+  struct sk_buff *skb, gfp_t flags)
 {
struct sierra_net_data *priv = sierra_net_get_private(dev);
u16 len;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next 2/2] net: sierra_net: rx_urb_size is constant

[Bjørn Mork]

The rx_urb_size is set to the same value for every device
supported by this driver.  No need to keep a per-device
data structure to do that. Replacing with a macro constant.

This was the last device specific info, and removing it
allows us to delete the sierra_net_info_data struct.

Signed-off-by: Bjørn Mork bj...@mork.no
---
 drivers/net/usb/sierra_net.c |   17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c
index 596ddaa..7ae70e9 100644
--- a/drivers/net/usb/sierra_net.c
+++ b/drivers/net/usb/sierra_net.c
@@ -68,9 +68,8 @@ staticatomic_t iface_counter = ATOMIC_INIT(0);
  */
 #define SIERRA_NET_USBCTL_BUF_LEN  1024
 
-struct sierra_net_info_data {
-   u16 rx_urb_size;
-};
+/* Overriding the default usbnet rx_urb_size */
+#define SIERRA_NET_RX_URB_SIZE (8 * 1024)
 
 /* Private data structure */
 struct sierra_net_data {
@@ -678,9 +677,6 @@ static int sierra_net_bind(struct usbnet *dev, struct 
usb_interface *intf)
static const u8 shdwn_tmplate[sizeof(priv-shdwn_msg)] = {
0x00, 0x00, SIERRA_NET_HIP_SHUTD_ID, 0x00};
 
-   struct sierra_net_info_data *data =
-   (struct sierra_net_info_data *)dev-driver_info-data;
-
dev_dbg(dev-udev-dev, %s, __func__);
 
ifacenum = intf-cur_altsetting-desc.bInterfaceNumber;
@@ -725,9 +721,9 @@ static int sierra_net_bind(struct usbnet *dev, struct 
usb_interface *intf)
sierra_net_set_ctx_index(priv, 0);
 
/* decrease the rx_urb_size and max_tx_size to 4k on USB 1.1 */
-   dev-rx_urb_size  = data-rx_urb_size;
+   dev-rx_urb_size  = SIERRA_NET_RX_URB_SIZE;
if (dev-udev-speed != USB_SPEED_HIGH)
-   dev-rx_urb_size  = min_t(size_t, 4096, data-rx_urb_size);
+   dev-rx_urb_size  = min_t(size_t, 4096, SIERRA_NET_RX_URB_SIZE);
 
dev-net-hard_header_len += SIERRA_NET_HIP_EXT_HDR_LEN;
dev-hard_mtu = dev-net-mtu + dev-net-hard_header_len;
@@ -918,10 +914,6 @@ static struct sk_buff *sierra_net_tx_fixup(struct usbnet 
*dev,
return NULL;
 }
 
-static const struct sierra_net_info_data sierra_net_info_data_direct_ip = {
-   .rx_urb_size = 8 * 1024,
-};
-
 static const struct driver_info sierra_net_info_direct_ip = {
.description = Sierra Wireless USB-to-WWAN Modem,
.flags = FLAG_WWAN | FLAG_SEND_ZLP,
@@ -930,7 +922,6 @@ static const struct driver_info sierra_net_info_direct_ip = 
{
.status = sierra_net_status,
.rx_fixup = sierra_net_rx_fixup,
.tx_fixup = sierra_net_tx_fixup,
-   .data = (unsigned long)sierra_net_info_data_direct_ip,
 };
 
 #define DIRECT_IP_DEVICE(vend, prod) \
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] usb: gadget: s3c-hsudc: Use devm_* functions

[Sachin Kamat]

devm_* functions are used to replace kzalloc, request_mem_region, ioremap
clk_get and request_irq functions in probe call. With the usage of devm_*
functions explicit freeing and unmapping is not required.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
 drivers/usb/gadget/s3c-hsudc.c |   41 ---
 1 files changed, 9 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c
index e26a4e7..fe4a461 100644
--- a/drivers/usb/gadget/s3c-hsudc.c
+++ b/drivers/usb/gadget/s3c-hsudc.c
@@ -135,7 +135,6 @@ struct s3c_hsudc_req {
  * @dev: The device reference used by probe function.
  * @lock: Lock to synchronize the usage of Endpoints (EP's are indexed).
  * @regs: Remapped base address of controller's register space.
- * @mem_rsrc: Device memory resource used for remapping device register space.
  * irq: IRQ number used by the controller.
  * uclk: Reference to the controller clock.
  * ep0state: Current state of EP0.
@@ -150,7 +149,6 @@ struct s3c_hsudc {
struct regulator_bulk_data supplies[ARRAY_SIZE(s3c_hsudc_supply_names)];
spinlock_t lock;
void __iomem *regs;
-   struct resource *mem_rsrc;
int irq;
struct clk *uclk;
int ep0state;
@@ -1271,7 +1269,7 @@ static int __devinit s3c_hsudc_probe(struct 
platform_device *pdev)
struct s3c24xx_hsudc_platdata *pd = pdev-dev.platform_data;
int ret, i;
 
-   hsudc = kzalloc(sizeof(struct s3c_hsudc) +
+   hsudc = devm_kzalloc(pdev-dev, sizeof(struct s3c_hsudc) +
sizeof(struct s3c_hsudc_ep) * pd-epnum,
GFP_KERNEL);
if (!hsudc) {
@@ -1296,25 +1294,12 @@ static int __devinit s3c_hsudc_probe(struct 
platform_device *pdev)
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res) {
-   dev_err(dev, unable to obtain driver resource data\n);
-   ret = -ENODEV;
-   goto err_res;
-   }
-
-   hsudc-mem_rsrc = request_mem_region(res-start, resource_size(res),
-   dev_name(pdev-dev));
-   if (!hsudc-mem_rsrc) {
-   dev_err(dev, failed to reserve register area\n);
-   ret = -ENODEV;
-   goto err_res;
-   }
 
-   hsudc-regs = ioremap(res-start, resource_size(res));
+   hsudc-regs = devm_request_and_ioremap(pdev-dev, res);
if (!hsudc-regs) {
dev_err(dev, error mapping device register area\n);
ret = -EBUSY;
-   goto err_remap;
+   goto err_res;
}
 
spin_lock_init(hsudc-lock);
@@ -1337,21 +1322,22 @@ static int __devinit s3c_hsudc_probe(struct 
platform_device *pdev)
ret = platform_get_irq(pdev, 0);
if (ret  0) {
dev_err(dev, unable to obtain IRQ number\n);
-   goto err_irq;
+   goto err_res;
}
hsudc-irq = ret;
 
-   ret = request_irq(hsudc-irq, s3c_hsudc_irq, 0, driver_name, hsudc);
+   ret = devm_request_irq(pdev-dev, hsudc-irq, s3c_hsudc_irq, 0,
+   driver_name, hsudc);
if (ret  0) {
dev_err(dev, irq request failed\n);
-   goto err_irq;
+   goto err_res;
}
 
-   hsudc-uclk = clk_get(pdev-dev, usb-device);
+   hsudc-uclk = devm_clk_get(pdev-dev, usb-device);
if (IS_ERR(hsudc-uclk)) {
dev_err(dev, failed to find usb-device clock source\n);
ret = PTR_ERR(hsudc-uclk);
-   goto err_clk;
+   goto err_res;
}
clk_enable(hsudc-uclk);
 
@@ -1377,21 +1363,12 @@ err_add_udc:
device_unregister(hsudc-gadget.dev);
 err_add_device:
clk_disable(hsudc-uclk);
-   clk_put(hsudc-uclk);
-err_clk:
-   free_irq(hsudc-irq, hsudc);
-err_irq:
-   iounmap(hsudc-regs);
-
-err_remap:
-   release_mem_region(res-start, resource_size(res));
 err_res:
if (!IS_ERR_OR_NULL(hsudc-transceiver))
usb_put_phy(hsudc-transceiver);
 
regulator_bulk_free(ARRAY_SIZE(hsudc-supplies), hsudc-supplies);
 err_supplies:
-   kfree(hsudc);
return ret;
 }
 
-- 
1.7.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

[PATCH 2/3] usb: gadget: s3c-hsudc: Add missing braces around sizeof

[Sachin Kamat]

Silences the following checkpatch warning:
WARNING: sizeof *hsreq should be sizeof(*hsreq)

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
 drivers/usb/gadget/s3c-hsudc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c
index fe4a461..35cdc6a 100644
--- a/drivers/usb/gadget/s3c-hsudc.c
+++ b/drivers/usb/gadget/s3c-hsudc.c
@@ -833,7 +833,7 @@ static struct usb_request *s3c_hsudc_alloc_request(struct 
usb_ep *_ep,
 {
struct s3c_hsudc_req *hsreq;
 
-   hsreq = kzalloc(sizeof *hsreq, gfp_flags);
+   hsreq = kzalloc(sizeof(*hsreq), gfp_flags);
if (!hsreq)
return 0;
 
-- 
1.7.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

[PATCH 3/3] usb: gadget: s3c-hsudc: Replace 0 with NULL for pointers

[Sachin Kamat]

Silences the following type of sparse warnings:
warning: Using plain integer as NULL pointer

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
 drivers/usb/gadget/s3c-hsudc.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c
index 35cdc6a..d8e785d 100644
--- a/drivers/usb/gadget/s3c-hsudc.c
+++ b/drivers/usb/gadget/s3c-hsudc.c
@@ -835,7 +835,7 @@ static struct usb_request *s3c_hsudc_alloc_request(struct 
usb_ep *_ep,
 
hsreq = kzalloc(sizeof(*hsreq), gfp_flags);
if (!hsreq)
-   return 0;
+   return NULL;
 
INIT_LIST_HEAD(hsreq-queue);
return hsreq-req;
@@ -904,16 +904,16 @@ static int s3c_hsudc_queue(struct usb_ep *_ep, struct 
usb_request *_req,
csr = readl((u32)hsudc-regs + offset);
if (!(csr  S3C_ESR_TX_SUCCESS) 
(s3c_hsudc_write_fifo(hsep, hsreq) == 1))
-   hsreq = 0;
+   hsreq = NULL;
} else {
csr = readl((u32)hsudc-regs + offset);
if ((csr  S3C_ESR_RX_SUCCESS)
(s3c_hsudc_read_fifo(hsep, hsreq) == 1))
-   hsreq = 0;
+   hsreq = NULL;
}
}
 
-   if (hsreq != 0)
+   if (hsreq)
list_add_tail(hsreq-queue, hsep-queue);
 
spin_unlock_irqrestore(hsudc-lock, flags);
-- 
1.7.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

[PATCH] usb: gadget: s3c-hsotg: Use devm_clk_get function

[Sachin Kamat]

devm_* functions are already used in this file. Hence
convert clk_get to devm_clk_get for completeness.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
 drivers/usb/gadget/s3c-hsotg.c |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index 0bb617e..1c8789a 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -3516,7 +3516,7 @@ static int __devinit s3c_hsotg_probe(struct 
platform_device *pdev)
hsotg-dev = dev;
hsotg-plat = plat;
 
-   hsotg-clk = clk_get(pdev-dev, otg);
+   hsotg-clk = devm_clk_get(pdev-dev, otg);
if (IS_ERR(hsotg-clk)) {
dev_err(dev, cannot get otg clock\n);
return PTR_ERR(hsotg-clk);
@@ -3667,7 +3667,6 @@ err_supplies:
 
 err_clk:
clk_disable_unprepare(hsotg-clk);
-   clk_put(hsotg-clk);
 
return ret;
 }
@@ -3693,7 +3692,6 @@ static int __devexit s3c_hsotg_remove(struct 
platform_device *pdev)
regulator_bulk_free(ARRAY_SIZE(hsotg-supplies), hsotg-supplies);
 
clk_disable_unprepare(hsotg-clk);
-   clk_put(hsotg-clk);
 
device_unregister(hsotg-gadget.dev);
return 0;
-- 
1.7.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 3/3] usb: gadget: s3c-hsudc: Replace 0 with NULL for pointers

[ABRAHAM, KISHON VIJAY]

Hi,

On Mon, Sep 3, 2012 at 3:48 PM, Sachin Kamat sachin.ka...@linaro.org wrote:
 Silences the following type of sparse warnings:
 warning: Using plain integer as NULL pointer

 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 ---
  drivers/usb/gadget/s3c-hsudc.c |8 
  1 files changed, 4 insertions(+), 4 deletions(-)

 diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c
 index 35cdc6a..d8e785d 100644
 --- a/drivers/usb/gadget/s3c-hsudc.c
 +++ b/drivers/usb/gadget/s3c-hsudc.c
 @@ -835,7 +835,7 @@ static struct usb_request *s3c_hsudc_alloc_request(struct 
 usb_ep *_ep,

 hsreq = kzalloc(sizeof(*hsreq), gfp_flags);
 if (!hsreq)
 -   return 0;
 +   return NULL;

shouldn't this be -ENOMEM?

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

Re: [PATCH 3/3] usb: gadget: s3c-hsudc: Replace 0 with NULL for pointers

[Sachin Kamat]

Hi

On 3 September 2012 16:37, ABRAHAM, KISHON VIJAY kis...@ti.com wrote:
 Hi,

 On Mon, Sep 3, 2012 at 3:48 PM, Sachin Kamat sachin.ka...@linaro.org wrote:
 Silences the following type of sparse warnings:
 warning: Using plain integer as NULL pointer

 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 ---
  drivers/usb/gadget/s3c-hsudc.c |8 
  1 files changed, 4 insertions(+), 4 deletions(-)

 diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c
 index 35cdc6a..d8e785d 100644
 --- a/drivers/usb/gadget/s3c-hsudc.c
 +++ b/drivers/usb/gadget/s3c-hsudc.c
 @@ -835,7 +835,7 @@ static struct usb_request 
 *s3c_hsudc_alloc_request(struct usb_ep *_ep,

 hsreq = kzalloc(sizeof(*hsreq), gfp_flags);
 if (!hsreq)
 -   return 0;
 +   return NULL;

 shouldn't this be -ENOMEM?

That should have been the obvious return value. However, I thought
probably it was made so with some reasoning and did not change it as I
am not familiar with this driver.


 Thanks
 Kishon



-- 
With warm regards,
Sachin
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] How to handle delays in isochronous transfers?

[Clemens Ladisch]

Alan Stern wrote:
 How should the lower USB layers handle delays in transferring
 isochronous data?  [...] when this happens the endpoint's queue
 drains completely.

 Clearly this will cause a glitch in the data stream.  The question is:
 What should we do to recover and re-synchronize?

The ALSA API promises that the samples in a stream run at a fixed clock,
i.e., samples are never delayed or accelerated.

 We could pretend nothing happened and continue to handle URBs normally,
 scheduling each submission for the next available slot.  But for an
 isochronous-OUT transfer, this would mean that all the future data
 values are delayed by some 40 ms relative to the earlier data.  If
 another glitch occurs then the following data will be delayed by even
 more.  For some applications this might not matter, but for others
 (real-time things like voice) it could be quite bad.  Similar problems
 arise with IN transfers.

This would not be acceptable; future samples must be scheduled for the
same frame for which they would have been scheduled without the delay.

 Alternatively, the host controller driver could fail the next 40 ms
 worth of isochronous URBs, so that the higher-level client catches up
 to where it should be.  The failure could occur during submission, or
 the URBs could be accepted and then forced to complete immediately,
 with no data transferred.

Both would be possible.  At the moment, a submission failure would cause
the driver to stop the stream and report an error to the application.

In this kind of situation (where it's known that multiple packets have
not been transferred), it would be somewhat preferrable to report the
error instead of ignoring it.

 What's the right thing to do?  My feeling is that the behavior
 should be decided not by the host controller driver but rather by the
 higher-level client.

Yeah, schedule directly after the previous packet, or fail and
schedule for the next possible frame might be useful.  (But the
audio driver would always use the first option.)


Regards,
Clemens
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] How to handle delays in isochronous transfers?

[Clemens Ladisch]

Peter Chen wrote:
 How should the lower USB layers handle delays in transferring
 isochronous data?
 I have seen reports from users where URB completion interrupts were
 delayed by as much as 50 ms.

 What should we do to recover and re-synchronize?

 I am not sure if feedback endpoint is implemented at our ISO-transfer
 class driver.
 If it is implemented, the class driver will take responsible to speed up/slow
 down transferring according to the device's feedback information.

In such a situation, the delay is much bigger than the device's buffer,
so just sending more samples afterwards will not help.

Furthermore, if packets are lost, frequency feedback becomes impossible
because the device doesn't know how many samples were lost.


Regards,
Clemens

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC ebeam PATCH v4 2/2] input: misc: New USB eBeam input driver.

[Oliver Neukum]

On Friday 24 August 2012 16:42:20 Yann Cantin wrote:
 Hi,
 
 Le 24/08/2012 13:41, Oliver Neukum a écrit :
  On Friday 24 August 2012 11:37:45 Yann Cantin wrote:
  Hi,
 
  Le 23/08/2012 09:23, Oliver Neukum a écrit :
  On Thursday 23 August 2012 00:11:54 Yann Cantin wrote:
  
  These functions are identical. You should unify them.
 
  Removed reset_resume from the driver (optional, and not needed
  for this hardware).
  
  Why did you do that? It is always better to have reset_resume().
  And you cannot tell whether it will be needed.
 
 This function was used in usbtouchscreen (which this driver is based on)
 for some hardware specific init after reset. eBeam devices doesn't need that,
 and i didn't mention the similarity of the 2 functions after stripping the 
 code.
 
 According to power-management.txt, reset_resume is optional, and lot of input
 driver lack it. Anyway, if you think it's worth the code, i'll re-add a 
 reset_resume function proxing resume like wacom_sys.c do.

It is always better to have reset_resume() if it can be easily done.

Regards
Oliver

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH resend] Input: usbtouchscreen - initialize eGalax devices

[Sergey Vlasov]

On Fri, Aug 31, 2012 at 08:37:26PM -0400, Forest Bond wrote:
 From: Forest Bond forest.b...@rapidrollout.com
 
 Certain eGalax devices expose an interface with class HID and protocol
 None.  Some work with usbhid and some work with usbtouchscreen, but
 there is no easy way to differentiate.  Sending an eGalax diagnostic
 packet seems to kick them all into using the right protocol for
 usbtouchscreen, so we can continue to bind them all there (as opposed to
 handing some off to usbhid).
 
 This fixes a regression for devices that were claimed by (and worked
 with) usbhid prior to commit 139ebe8dc80dd74cb2ac9f5603d18fbf5cff049f
 (Input: usbtouchscreen - fix eGalax HID ignoring), which made
 usbtouchscreen claim them instead.  With this patch they will still be
 claimed by usbtouchscreen, but they will actually report events
 usbtouchscreen can understand.  Note that these devices will be limited
 to the usbtouchscreen feature set so e.g. dual touch features are not
 supported.
 
 I have the distinct pleasure of needing to support devices of both types
 and have tested accordingly.
 
 Signed-off-by: Forest Bond forest.b...@rapidrollout.com
 ---
  drivers/input/touchscreen/usbtouchscreen.c |   36 
 
  1 files changed, 36 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/input/touchscreen/usbtouchscreen.c 
 b/drivers/input/touchscreen/usbtouchscreen.c
 index e32709e..64b4b17 100644
 --- a/drivers/input/touchscreen/usbtouchscreen.c
 +++ b/drivers/input/touchscreen/usbtouchscreen.c
 @@ -304,6 +304,41 @@ static int e2i_read_data(struct usbtouch_usb *dev, 
 unsigned char *pkt)
  #define EGALAX_PKT_TYPE_REPT 0x80
  #define EGALAX_PKT_TYPE_DIAG 0x0A
  
 +static int egalax_init(struct usbtouch_usb *usbtouch)
 +{
 + int ret, i;
 + unsigned char *buf;
 + struct usb_device *udev = interface_to_usbdev(usbtouch-interface);
 +
 + /* An eGalax diagnostic packet kicks the device into using the right
 +  * protocol.  We send a check active packet.  The response will be
 +  * read later and ignored.
 +  */
 +
 + buf = kmalloc(3, GFP_KERNEL);

if (!buf)
return -ENOMEM;

 + buf[0] = EGALAX_PKT_TYPE_DIAG;
 + buf[1] = 1; /* length */
 + buf[2] = 'A';   /* command - check active */
 +
 + for (i = 0; i  3; i++) {
 + ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
 +   0,
 +   USB_DIR_OUT | USB_TYPE_VENDOR | 
 USB_RECIP_DEVICE,
 +   0, 0, buf, 3,
 +   USB_CTRL_SET_TIMEOUT);
 + if (ret = 0) {
 + ret = 0;
 + break;
 + }
 + if (ret != -EPIPE)
 + break;
 + }
 +
 + kfree(buf);
 +
 + return ret;
 +}


signature.asc
Description: Digital signature

Re: [PATCH 3/3] usb: gadget: s3c-hsudc: Replace 0 with NULL for pointers

[Felipe Balbi]

On Mon, Sep 03, 2012 at 05:00:44PM +0530, Sachin Kamat wrote:
 Hi
 
 On 3 September 2012 16:37, ABRAHAM, KISHON VIJAY kis...@ti.com wrote:
  Hi,
 
  On Mon, Sep 3, 2012 at 3:48 PM, Sachin Kamat sachin.ka...@linaro.org 
  wrote:
  Silences the following type of sparse warnings:
  warning: Using plain integer as NULL pointer
 
  Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
  ---
   drivers/usb/gadget/s3c-hsudc.c |8 
   1 files changed, 4 insertions(+), 4 deletions(-)
 
  diff --git a/drivers/usb/gadget/s3c-hsudc.c 
  b/drivers/usb/gadget/s3c-hsudc.c
  index 35cdc6a..d8e785d 100644
  --- a/drivers/usb/gadget/s3c-hsudc.c
  +++ b/drivers/usb/gadget/s3c-hsudc.c
  @@ -835,7 +835,7 @@ static struct usb_request 
  *s3c_hsudc_alloc_request(struct usb_ep *_ep,
 
  hsreq = kzalloc(sizeof(*hsreq), gfp_flags);
  if (!hsreq)
  -   return 0;
  +   return NULL;
 
  shouldn't this be -ENOMEM?
 
 That should have been the obvious return value. However, I thought
 probably it was made so with some reasoning and did not change it as I
 am not familiar with this driver.

it's just the way the API was designed. If we fail to allocate a
usb_request, we must return NULL so function/gadget drivers can check if
it was successful or not.

Of course it could be changed into ERR_PTR(-ENOMEM) or something, but
that's an API change... ;-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2] usb: otg: Move phy interface to separate file.

[Felipe Balbi]

Hi,

On Wed, Aug 29, 2012 at 12:17:01PM +0530, Venu Byravarasu wrote:
 As otg.h is containing lots of phy interface related
 stuff, moving all phy interface related stuff to new
 file named phy.h
 
 Signed-off-by: Venu Byravarasu vbyravar...@nvidia.com

this doesn't apply to my xceiv branch. Please rebase there so I don't
cause any issues to your patch ;-)

-- 
balbi


signature.asc
Description: Digital signature

[PATCH RFC] USB: EHCI on imx53

[Roland Stigge]

Hi,

this is my first try on activating EHCI on imx53 (primarily via dt). However,
probe() still hangs on the first ehci_writel() l.189. I guess some
clock/enabling is still missing?

Sascha, do you already have EHCI running on imx53?

Any hint would be very much appreciated.

Thanks in advance,

Roland

---
 arch/arm/boot/dts/imx53.dtsi  |8 
 arch/arm/mach-imx/Kconfig |1 +
 arch/arm/mach-imx/devices-imx53.h |4 
 arch/arm/mach-imx/imx53-dt.c  |7 +++
 drivers/usb/host/ehci-mxc.c   |   12 
 5 files changed, 32 insertions(+)

--- linux-2.6.orig/arch/arm/boot/dts/imx53.dtsi
+++ linux-2.6/arch/arm/boot/dts/imx53.dtsi
@@ -135,6 +135,14 @@
};
};
 
+   ehci@53f8 {
+   compatible = fsl,mxc-ehci;
+   interrupt-parent = tzic;
+   interrupts = 14;
+   reg = 0x53f8 0x4000;
+   status = disabled;
+   };
+
gpio1: gpio@53f84000 {
compatible = fsl,imx53-gpio, fsl,imx35-gpio;
reg = 0x53f84000 0x4000;
--- linux-2.6.orig/arch/arm/mach-imx/Kconfig
+++ linux-2.6/arch/arm/mach-imx/Kconfig
@@ -799,6 +799,7 @@ config MACH_MX53_DIMM
select IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
select IMX_HAVE_PLATFORM_SPI_IMX
select IMX_HAVE_PLATFORM_MXC_NAND
+   select IMX_HAVE_PLATFORM_MXC_EHCI
select LEDS_GPIO_REGISTER
help
  Include support for DIMM MX53 platform. This includes specific
--- linux-2.6.orig/arch/arm/mach-imx/devices-imx53.h
+++ linux-2.6/arch/arm/mach-imx/devices-imx53.h
@@ -45,4 +45,8 @@ extern const struct imx_pata_imx_data im
 #define imx53_add_pata_imx() \
imx_add_pata_imx(imx53_pata_imx_data)
 
+extern const struct imx_mxc_ehci_data imx53_mxc_ehci_data;
+#define imx53_add_mxc_ehci(pdata) \
+   imx_add_mxc_ehci(imx53_mxc_ehci_data, pdata)
+
 extern struct platform_device *__init imx53_add_ahci_imx(void);
--- linux-2.6.orig/arch/arm/mach-imx/imx53-dt.c
+++ linux-2.6/arch/arm/mach-imx/imx53-dt.c
@@ -23,6 +23,12 @@
 #include mach/common.h
 #include mach/mx53.h
 
+#include mach/mxc_ehci.h
+
+static struct mxc_usbh_platform_data otg_pdata __initdata = {
+   .portsc = MXC_EHCI_MODE_SERIAL,
+};
+
 /*
  * Lookup table for attaching a specific name and platform_data pointer to
  * devices as they get created by of_platform_populate().  Ideally this table
@@ -48,6 +54,7 @@ static const struct of_dev_auxdata imx53
OF_DEV_AUXDATA(fsl,imx53-i2c, MX53_I2C3_BASE_ADDR, imx-i2c.2, NULL),
OF_DEV_AUXDATA(fsl,imx53-sdma, MX53_SDMA_BASE_ADDR, imx35-sdma, 
NULL),
OF_DEV_AUXDATA(fsl,imx53-wdt, MX53_WDOG1_BASE_ADDR, imx2-wdt.0, 
NULL),
+   OF_DEV_AUXDATA(fsl,mxc-ehci, MX53_OTG_BASE_ADDR, mxc-ehci.0, 
otg_pdata),
{ /* sentinel */ }
 };
 
--- linux-2.6.orig/drivers/usb/host/ehci-mxc.c
+++ linux-2.6/drivers/usb/host/ehci-mxc.c
@@ -18,6 +18,8 @@
  */
 
 #include linux/platform_device.h
+#include linux/of.h
+#include linux/of_platform.h
 #include linux/clk.h
 #include linux/delay.h
 #include linux/usb/otg.h
@@ -311,11 +313,21 @@ static void ehci_mxc_drv_shutdown(struct
 
 MODULE_ALIAS(platform:mxc-ehci);
 
+#ifdef CONFIG_OF
+static const struct of_device_id mxc_ehci_dt_ids[] = {
+   { .compatible = fsl,mxc-ehci },
+   { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, mxc_ehci_dt_ids);
+#endif
+
 static struct platform_driver ehci_mxc_driver = {
.probe = ehci_mxc_drv_probe,
.remove = __exit_p(ehci_mxc_drv_remove),
.shutdown = ehci_mxc_drv_shutdown,
.driver = {
   .name = mxc-ehci,
+  .of_match_table = of_match_ptr(mxc_ehci_dt_ids),
},
 };
--
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] USB: EHCI on imx53

[Sascha Hauer]

Hi Roland,

On Mon, Sep 03, 2012 at 04:27:57PM +0200, Roland Stigge wrote:
 Hi,
 
 this is my first try on activating EHCI on imx53 (primarily via dt). However,
 probe() still hangs on the first ehci_writel() l.189. I guess some
 clock/enabling is still missing?
 
 Sascha, do you already have EHCI running on imx53?

I'm sorry to say that you are sitting on a dead end. Please google for
chipidea, Richard Zhao, Marc Kleine-Budde. They are regularly dropping
large patch bombs on linux-usb. I have no idea how to merge the patches
together to some working state. Maybe Marc can give you a pointer.

Sascha

-- 
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: [PATCH RFC] USB: EHCI on imx53

[Marc Kleine-Budde]

On 09/03/2012 04:37 PM, Sascha Hauer wrote:
 Hi Roland,
 
 On Mon, Sep 03, 2012 at 04:27:57PM +0200, Roland Stigge wrote:
 Hi,

 this is my first try on activating EHCI on imx53 (primarily via dt). However,
 probe() still hangs on the first ehci_writel() l.189. I guess some
 clock/enabling is still missing?

 Sascha, do you already have EHCI running on imx53?
 
 I'm sorry to say that you are sitting on a dead end. Please google for
 chipidea, Richard Zhao, Marc Kleine-Budde. They are regularly dropping
 large patch bombs on linux-usb. I have no idea how to merge the patches
 together to some working state. Maybe Marc can give you a pointer.

We've a running version of mx53 here, the patches are not ready for
posting. However several other chipidea related patches are still under
review.

Marc
-- 
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

[RFC PATCH V2 1/2] usb: usb port power off mechanism add auto option

[Lan Tianyu]

This patch is to add auto option to attribute portX/control.
When echo auto, the port's feature PORT_POWER would be clear
if the port's connect type was mark not-used(connectability and
visibility are both cleared) and with no device attached.

Signed-off-by: Lan Tianyu tianyu@intel.com
---
This patchset is based on the following patchset
http://marc.info/?l=linux-usbm=134517695007182w=2
  usb: make usb port a real device
  usb: move children to struct usb_port
  usb/acpi: Bind ACPI node to USB port, not usb_device.
  usb/acpi: Store info on device removability.
  xhci: Handle clear PORT_POWER feature.
  usb/acpi: Use ACPI methods to power off ports.
  usb: Fail a get config when the port is powered off.
  usb : Add sysfs files to control port power.

v2: add auto option process in the hub_power_on()
---
 drivers/usb/core/hub.c |   35 +--
 1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 3def91e..07c62dd 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -42,6 +42,7 @@
 enum port_power_policy {
USB_PORT_POWER_ON = 0,
USB_PORT_POWER_OFF,
+   USB_PORT_POWER_AUTO,
 };
 
 struct usb_port {
@@ -101,6 +102,7 @@ struct usb_hub {
 
 static const char on_string[] = on;
 static const char off_string[] = off;
+static const char auto_string[] = auto;
 static const struct attribute_group *port_dev_group[];
 
 static inline int hub_is_superspeed(struct usb_device *hdev)
@@ -842,6 +844,7 @@ static unsigned hub_power_on(struct usb_hub *hub, bool 
do_delay)
unsigned delay;
u16 wHubCharacteristics =
le16_to_cpu(hub-descriptor-wHubCharacteristics);
+   struct usb_port *pport;
 
/* Enable power on each port.  Some hubs have reserved values
 * of LPSM ( 2) in their descriptors, even though they are
@@ -854,13 +857,18 @@ static unsigned hub_power_on(struct usb_hub *hub, bool 
do_delay)
else
dev_dbg(hub-intfdev, trying to enable port power on 
non-switchable hub\n);
-   for (port1 = 1; port1 = hub-descriptor-bNbrPorts; port1++)
-   if (hub-ports[port1 - 1]-port_power_policy
-   == USB_PORT_POWER_ON)
-   set_port_feature(hub-hdev, port1, USB_PORT_FEAT_POWER);
-   else
+   for (port1 = 1; port1 = hub-descriptor-bNbrPorts; port1++) {
+   pport = hub-ports[port1 - 1];
+
+   if (pport-port_power_policy == USB_PORT_POWER_OFF ||
+   (pport-port_power_policy == USB_PORT_POWER_AUTO
+ pport-connect_type == USB_PORT_NOT_USED
+ !pport-child))
clear_port_feature(hub-hdev, port1,
-   USB_PORT_FEAT_POWER);
+   USB_PORT_FEAT_POWER);
+   else
+   set_port_feature(hub-hdev, port1, USB_PORT_FEAT_POWER);
+   }
 
/* Wait at least 100 msec for power to become stable */
delay = max(pgood_delay, (unsigned) 100);
@@ -4703,6 +4711,9 @@ static ssize_t show_port_power_control(struct device *dev,
case USB_PORT_POWER_OFF:
result = off_string;
break;
+   case USB_PORT_POWER_AUTO:
+   result = auto_string;
+   break;
default:
return -EINVAL;
}
@@ -4741,6 +4752,18 @@ static ssize_t store_port_power_control(struct device 
*dev,
usb_autopm_put_interface(intf);
if (ret  0)
return -EIO;
+   } else if (len == sizeof(auto_string) - 1
+strncmp(buf, auto_string, len) == 0) {
+   hub_port-port_power_policy = USB_PORT_POWER_AUTO;
+   if (hub_port-connect_type
+   == USB_PORT_NOT_USED  !hub_port-child) {
+   usb_autopm_get_interface(intf);
+   ret = clear_port_feature(hdev, port1,
+   USB_PORT_FEAT_POWER);
+   usb_autopm_put_interface(intf);
+   if (ret  0)
+   return -EIO;
+   }
} else
return -EINVAL;
 
-- 
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

[RFC PATCH V2 2/2] USB: Set usb port's DevicerRemovable according acpi information in EHCI

[Lan Tianyu]

ACPI provide _PLD and _UPC aml methods to describe usb port
visibility and connectability. This patch is to use those information
to set usb port's DeviceRemovable.

Signed-off-by: Lan Tianyu tianyu@intel.com
---
v2: Set DeviceRemovable according acpi infomation in the hub_configure()
instead of calling get_hub_descriptor().
---
 drivers/usb/core/hub.c  |   22 ++
 drivers/usb/core/usb.h  |4 
 drivers/usb/host/ehci-hub.c |9 +
 include/linux/usb.h |4 
 4 files changed, 35 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 07c62dd..a411a36 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1566,6 +1566,25 @@ static int hub_configure(struct usb_hub *hub,
dev_err(hub-intfdev,
couldn't create port%d device.\n, i + 1);
 
+   if (hub_is_superspeed(hdev)) {
+   for (i = 1; i = hdev-maxchild; i++)
+   if (hub-ports[i - 1]-connect_type
+   == USB_PORT_CONNECT_TYPE_HARD_WIRED)
+   hub-descriptor-u.hs.DeviceRemovable[i/8]
+   |= 1  (i%8);
+   } else  {
+   u16 port_removable = 0;
+
+   for (i = i; i = hdev-maxchild; i++)
+   if (hub-ports[i - 1]-connect_type
+   == USB_PORT_CONNECT_TYPE_HARD_WIRED)
+   port_removable |= 1  i;
+
+   memset(hub-descriptor-u.ss.DeviceRemovable,
+   (__force __u16) cpu_to_le16(port_removable),
+   sizeof(__u16));
+   }
+
hub_activate(hub, HUB_INIT);
return 0;
 
@@ -5260,6 +5279,9 @@ usb_get_hub_port_connect_type(struct usb_device *hdev, 
int port1)
 {
struct usb_hub *hub = hdev_to_hub(hdev);
 
+   if (!hub)
+   return USB_PORT_CONNECT_TYPE_UNKNOWN;
+
return hub-ports[port1 - 1]-connect_type;
 }
 
diff --git a/drivers/usb/core/usb.h b/drivers/usb/core/usb.h
index 1c528c1..1633f6e 100644
--- a/drivers/usb/core/usb.h
+++ b/drivers/usb/core/usb.h
@@ -169,10 +169,6 @@ extern void usb_notify_add_device(struct usb_device *udev);
 extern void usb_notify_remove_device(struct usb_device *udev);
 extern void usb_notify_add_bus(struct usb_bus *ubus);
 extern void usb_notify_remove_bus(struct usb_bus *ubus);
-extern enum usb_port_connect_type
-   usb_get_hub_port_connect_type(struct usb_device *hdev, int port1);
-extern void usb_set_hub_port_connect_type(struct usb_device *hdev, int port1,
-   enum usb_port_connect_type type);
 
 #ifdef CONFIG_ACPI
 extern int usb_acpi_register(void);
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index c788022..5ad3a11 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -636,6 +636,7 @@ ehci_hub_descriptor (
struct usb_hub_descriptor   *desc
 ) {
int ports = HCS_N_PORTS (ehci-hcs_params);
+   int i;
u16 temp;
 
desc-bDescriptorType = 0x29;
@@ -650,6 +651,14 @@ ehci_hub_descriptor (
memset(desc-u.hs.DeviceRemovable[0], 0, temp);
memset(desc-u.hs.DeviceRemovable[temp], 0xff, temp);
 
+   for (i = 1; i = ports; i++) {
+   if (usb_get_hub_port_connect_type(
+   ehci_to_hcd(ehci)-self.root_hub, i)
+   == USB_PORT_CONNECT_TYPE_HARD_WIRED)
+   desc-u.hs.DeviceRemovable[i/8] |= 1  (i%8);
+   }
+
+
temp = 0x0008;  /* per-port overcurrent reporting */
if (HCS_PPC (ehci-hcs_params))
temp |= 0x0001; /* per-port power control */
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 07915a3..0928f2a 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -575,6 +575,10 @@ static inline struct usb_device 
*interface_to_usbdev(struct usb_interface *intf)
return to_usb_device(intf-dev.parent);
 }
 
+extern enum usb_port_connect_type
+   usb_get_hub_port_connect_type(struct usb_device *hdev, int port1);
+extern void usb_set_hub_port_connect_type(struct usb_device *hdev, int port1,
+   enum usb_port_connect_type type);
 extern struct usb_device *usb_get_dev(struct usb_device *dev);
 extern void usb_put_dev(struct usb_device *dev);
 extern struct usb_device *usb_hub_find_child(struct usb_device *hdev,
-- 
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

Re: [PATCH RFC] USB: EHCI on imx53

[Marc Kleine-Budde]

On 09/03/2012 05:39 PM, Roland Stigge wrote:
 Hi Marc and Sascha,
 
 On 09/03/2012 04:49 PM, Marc Kleine-Budde wrote:
 On Mon, Sep 03, 2012 at 04:27:57PM +0200, Roland Stigge wrote:
 Hi,

 this is my first try on activating EHCI on imx53 (primarily via
 dt). However, probe() still hangs on the first ehci_writel()
 l.189. I guess some clock/enabling is still missing?

 Sascha, do you already have EHCI running on imx53?

 I'm sorry to say that you are sitting on a dead end. Please
 google for chipidea, Richard Zhao, Marc Kleine-Budde. They are
 regularly dropping large patch bombs on linux-usb. I have no idea
 how to merge the patches together to some working state. Maybe
 Marc can give you a pointer.

 We've a running version of mx53 here, the patches are not ready
 for posting.
 
 Maybe I can already test sth. and give feedback?
 
 Or is it reasonable to use some patches you posted previously (the
 ones Sascha mentioned)? (Which one?)

I think I can prepare something for you tomorrow.

Marc

-- 
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: [RFC] How to handle delays in isochronous transfers?

[Alan Stern]

On Mon, 3 Sep 2012, Clemens Ladisch wrote:

 Alan Stern wrote:
  How should the lower USB layers handle delays in transferring
  isochronous data?  [...] when this happens the endpoint's queue
  drains completely.
 
  Clearly this will cause a glitch in the data stream.  The question is:
  What should we do to recover and re-synchronize?
 
 The ALSA API promises that the samples in a stream run at a fixed clock,
 i.e., samples are never delayed or accelerated.
 
  We could pretend nothing happened and continue to handle URBs normally,
  scheduling each submission for the next available slot.  But for an
  isochronous-OUT transfer, this would mean that all the future data
  values are delayed by some 40 ms relative to the earlier data.  If
  another glitch occurs then the following data will be delayed by even
  more.  For some applications this might not matter, but for others
  (real-time things like voice) it could be quite bad.  Similar problems
  arise with IN transfers.
 
 This would not be acceptable; future samples must be scheduled for the
 same frame for which they would have been scheduled without the delay.

I suspected as much.  It's good to have the suspicions confirmed.

  Alternatively, the host controller driver could fail the next 40 ms
  worth of isochronous URBs, so that the higher-level client catches up
  to where it should be.  The failure could occur during submission, or
  the URBs could be accepted and then forced to complete immediately,
  with no data transferred.
 
 Both would be possible.  At the moment, a submission failure would cause
 the driver to stop the stream and report an error to the application.

A submission failure is cleaner than an immediate completion, because
we could then avoid making a whole series of doomed submissions (and
using up a lot of stack space).  On the other hand, it would be
necessary to tell the client how many slots have to be skipped.  Any
idea how to do that?

And of course, it would be necessary to change the clients to take this
new information and new failure mode into account.

 In this kind of situation (where it's known that multiple packets have
 not been transferred), it would be somewhat preferrable to report the
 error instead of ignoring it.

That's a good idea.  I can add a warning message to ehci-hcd.  Should 
it trigger when any packets have been skipped, or only when the number 
of skipped packets is so large that an entire URB has to be rejected?

  What's the right thing to do?  My feeling is that the behavior
  should be decided not by the host controller driver but rather by the
  higher-level client.
 
 Yeah, schedule directly after the previous packet, or fail and
 schedule for the next possible frame might be useful.  (But the
 audio driver would always use the first option.)

I'll use URB_ISO_ASAP to mean the next possible slot.  Leaving that 
flag turned off will mean the slot after the previous packet.

I can do this for ehci-hcd, ohci-hcd, and uhci-hcd.  I don't know if 
xhci-hcd will be able to support this, however.

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: [RFC] How to handle delays in isochronous transfers?

[Jassi Brar]

On Fri, Aug 31, 2012 at 11:56 PM, Alan Stern st...@rowland.harvard.edu wrote:
 Clemens and Laurent (and anyone else who's interested):

 How should the lower USB layers handle delays in transferring
 isochronous data?  I'm asking you because the most common usages of
 isochronous transfers are for audio and video.

 Here's an example to illustrate what I mean.  Typically an audio or
 video driver will keep a queue of around 10 ms of data submitted to an
 isochronous endpoint.  I have seen reports from users where URB
 completion interrupts were delayed by as much as 50 ms.  In one case
 the delay was caused by a bug in a wireless drivers that left
 interrupts disabled; in another case the cause was unknown -- it might
 have been a hardware problem.  At any rate, when this happens the
 endpoint's queue drains completely.

 Clearly this will cause a glitch in the data stream.  The question is:
 What should we do to recover and re-synchronize?

How about effectively increasing the queue length from 10ms to 50ms
(max anticipated latency) ?
--
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 resend2] Input: usbtouchscreen - initialize eGalax devices

[Forest Bond]

From: Forest Bond forest.b...@rapidrollout.com

Certain eGalax devices expose an interface with class HID and protocol
None.  Some work with usbhid and some work with usbtouchscreen, but
there is no easy way to differentiate.  Sending an eGalax diagnostic
packet seems to kick them all into using the right protocol for
usbtouchscreen, so we can continue to bind them all there (as opposed to
handing some off to usbhid).

This fixes a regression for devices that were claimed by (and worked
with) usbhid prior to commit 139ebe8dc80dd74cb2ac9f5603d18fbf5cff049f
(Input: usbtouchscreen - fix eGalax HID ignoring), which made
usbtouchscreen claim them instead.  With this patch they will still be
claimed by usbtouchscreen, but they will actually report events
usbtouchscreen can understand.  Note that these devices will be limited
to the usbtouchscreen feature set so e.g. dual touch features are not
supported.

I have the distinct pleasure of needing to support devices of both types
and have tested accordingly.

Signed-off-by: Forest Bond forest.b...@rapidrollout.com
---
 drivers/input/touchscreen/usbtouchscreen.c |   39 
 1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/drivers/input/touchscreen/usbtouchscreen.c 
b/drivers/input/touchscreen/usbtouchscreen.c
index e32709e..c5f4dc0 100644
--- a/drivers/input/touchscreen/usbtouchscreen.c
+++ b/drivers/input/touchscreen/usbtouchscreen.c
@@ -304,6 +304,44 @@ static int e2i_read_data(struct usbtouch_usb *dev, 
unsigned char *pkt)
 #define EGALAX_PKT_TYPE_REPT   0x80
 #define EGALAX_PKT_TYPE_DIAG   0x0A
 
+static int egalax_init(struct usbtouch_usb *usbtouch)
+{
+   int ret, i;
+   unsigned char *buf;
+   struct usb_device *udev = interface_to_usbdev(usbtouch-interface);
+
+   /* An eGalax diagnostic packet kicks the device into using the right
+* protocol.  We send a check active packet.  The response will be
+* read later and ignored.
+*/
+
+   buf = kmalloc(3, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   buf[0] = EGALAX_PKT_TYPE_DIAG;
+   buf[1] = 1; /* length */
+   buf[2] = 'A';   /* command - check active */
+
+   for (i = 0; i  3; i++) {
+   ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
+ 0,
+ USB_DIR_OUT | USB_TYPE_VENDOR | 
USB_RECIP_DEVICE,
+ 0, 0, buf, 3,
+ USB_CTRL_SET_TIMEOUT);
+   if (ret = 0) {
+   ret = 0;
+   break;
+   }
+   if (ret != -EPIPE)
+   break;
+   }
+
+   kfree(buf);
+
+   return ret;
+}
+
 static int egalax_read_data(struct usbtouch_usb *dev, unsigned char *pkt)
 {
if ((pkt[0]  EGALAX_PKT_TYPE_MASK) != EGALAX_PKT_TYPE_REPT)
@@ -1056,6 +1094,7 @@ static struct usbtouch_device_info usbtouch_dev_info[] = {
.process_pkt= usbtouch_process_multi,
.get_pkt_len= egalax_get_pkt_len,
.read_data  = egalax_read_data,
+   .init   = egalax_init,
},
 #endif
 
-- 
1.7.0.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 net] net: usbnet: fix softirq storm on suspend

[David Miller]

From: Bjørn Mork bj...@mork.no
Date: Mon,  3 Sep 2012 10:26:18 +0200

 Suspending an open usbnet device results in constant
 rescheduling of usbnet_bh.
 
 commit 65841fd5 usbnet: handle remote wakeup asap
 refactored the usbnet_bh code to allow sharing the
 urb allocate and submit code with usbnet_resume. In
 this process, a test for, and immediate return on,
 ENOLINK from rx_submit was unintentionally dropped.
 
 The rx queue will not grow if rx_submit fails,
 making usbnet_bh reschedule itself.  This results
 in a softirq storm if the error is persistent.
 rx_submit translates the usb_submit_urb error
 EHOSTUNREACH into ENOLINK, so this is an expected
 and persistent error for a suspended device. The
 old code tested for this condition and avoided
 rescheduling.  Putting this test back.
 
 Cc: sta...@vger.kernel.org # v3.5
 Cc: Ming Lei ming@canonical.com
 Cc: Oliver Neukum oneu...@suse.de
 Signed-off-by: Bjørn Mork bj...@mork.no

Applied, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next] net: cx82310_eth: use common match macro

[David Miller]

From: Bjørn Mork bj...@mork.no
Date: Mon,  3 Sep 2012 11:20:31 +0200

 Signed-off-by: Bjørn Mork bj...@mork.no

Applied.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next 1/2] net: sierra_net: make private symbols static

[David Miller]

From: Bjørn Mork bj...@mork.no
Date: Mon,  3 Sep 2012 11:20:32 +0200

 Signed-off-by: Bjørn Mork bj...@mork.no

Applied.
--
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: PLAT_ORION fulfils USB_ARCH_HAS_EHCI

[Andrew Lunn]

The various Orion SoCs, i.e. orion5x, kirkwood, dove, mv78xx0
and 370/XP have EHCI. Make sure USB_ARCH_HAS_EHCI reflects this.

Reported-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Signed-off-by: Andrew Lunn and...@lunn.ch
---
 drivers/usb/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index a7773a3..723efcc 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -48,6 +48,7 @@ config USB_ARCH_HAS_EHCI
default y if SPARC_LEON
default y if ARCH_MMP
default y if MACH_LOONGSON1
+   default y if PLAT_ORION
default PCI
 
 # some non-PCI HCDs implement xHCI
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] USB: PLAT_ORION fulfils USB_ARCH_HAS_EHCI

[Jason]

Andrew Lunn and...@lunn.ch wrote:

The various Orion SoCs, i.e. orion5x, kirkwood, dove, mv78xx0
and 370/XP have EHCI. Make sure USB_ARCH_HAS_EHCI reflects this.

Reported-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Signed-off-by: Andrew Lunn and...@lunn.ch
---
 drivers/usb/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index a7773a3..723efcc 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -48,6 +48,7 @@ config USB_ARCH_HAS_EHCI
   default y if SPARC_LEON
   default y if ARCH_MMP
   default y if MACH_LOONGSON1
+  default y if PLAT_ORION

PLAT_ORION_LEGACY?

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] How to handle delays in isochronous transfers?

[Clemens Ladisch]

Alan Stern wrote:
 On Mon, 3 Sep 2012, Clemens Ladisch wrote:
 Alan Stern wrote:
 Alternatively, the host controller driver could fail the next 40 ms
 worth of isochronous URBs, so that the higher-level client catches up
 to where it should be.  The failure could occur during submission, or
 the URBs could be accepted and then forced to complete immediately,
 with no data transferred.

 Both would be possible.  At the moment, a submission failure would cause
 the driver to stop the stream and report an error to the application.

 A submission failure is cleaner than an immediate completion, because
 we could then avoid making a whole series of doomed submissions (and
 using up a lot of stack space).  On the other hand, it would be
 necessary to tell the client how many slots have to be skipped.

The audio driver wouldn't care.  Logically, it starts a new stream.

 In this kind of situation (where it's known that multiple packets have
 not been transferred), it would be somewhat preferrable to report the
 error instead of ignoring it.

 That's a good idea.  I can add a warning message to ehci-hcd.

I meant report to the client as an error, instead of silently dropping
packets.


Regards,
Clemens
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] How to handle delays in isochronous transfers?

[Alan Stern]

On Mon, 3 Sep 2012, Jassi Brar wrote:

 On Fri, Aug 31, 2012 at 11:56 PM, Alan Stern st...@rowland.harvard.edu 
 wrote:
  Clemens and Laurent (and anyone else who's interested):
 
  How should the lower USB layers handle delays in transferring
  isochronous data?  I'm asking you because the most common usages of
  isochronous transfers are for audio and video.
 
  Here's an example to illustrate what I mean.  Typically an audio or
  video driver will keep a queue of around 10 ms of data submitted to an
  isochronous endpoint.  I have seen reports from users where URB
  completion interrupts were delayed by as much as 50 ms.  In one case
  the delay was caused by a bug in a wireless drivers that left
  interrupts disabled; in another case the cause was unknown -- it might
  have been a hardware problem.  At any rate, when this happens the
  endpoint's queue drains completely.
 
  Clearly this will cause a glitch in the data stream.  The question is:
  What should we do to recover and re-synchronize?
 
 How about effectively increasing the queue length from 10ms to 50ms
 (max anticipated latency) ?

There are two problems with that approach.  First, 50 ms isn't really
the max anticipated latency; it's merely the largest that I've seen so
far.  (In fact, the max anticipated latency is probably  10 ms; these 
50-ms delays were definitely exceptional.)

Second, people involved in real-time programming (such as audio or
video) generally want to keep latency to a minimum.

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: [RFC] How to handle delays in isochronous transfers?

[Alan Stern]

On Mon, 3 Sep 2012, Clemens Ladisch wrote:

 Alan Stern wrote:
  On Mon, 3 Sep 2012, Clemens Ladisch wrote:
  Alan Stern wrote:
  Alternatively, the host controller driver could fail the next 40 ms
  worth of isochronous URBs, so that the higher-level client catches up
  to where it should be.  The failure could occur during submission, or
  the URBs could be accepted and then forced to complete immediately,
  with no data transferred.
 
  Both would be possible.  At the moment, a submission failure would cause
  the driver to stop the stream and report an error to the application.
 
  A submission failure is cleaner than an immediate completion, because
  we could then avoid making a whole series of doomed submissions (and
  using up a lot of stack space).  On the other hand, it would be
  necessary to tell the client how many slots have to be skipped.
 
 The audio driver wouldn't care.  Logically, it starts a new stream.

Really?  Why not just skip a few packets and carry on with the existing
stream?  Does the behavior vary (or need to vary) according to the
stream's direction?

Logically, the situation isn't very different from what happens when
packets are lost in transit (except for the fact that outgoing packets
can be lost without the host's knowledge).  Isochronous makes no
guarantees about packet delivery, and never retries.

  In this kind of situation (where it's known that multiple packets have
  not been transferred), it would be somewhat preferrable to report the
  error instead of ignoring it.
 
  That's a good idea.  I can add a warning message to ehci-hcd.
 
 I meant report to the client as an error, instead of silently dropping
 packets.

In fact this missing data is already reported.  The status member of
the usb_iso_packet_descriptor structure returns -EXDEV if a packet was
submitted too late for its scheduled time slot.  (The error-codes.txt
documentation file says partially completed, which isn't a very good
description.)

My reason for bringing this up is because I want to improve the way
ehci-hcd handles such things.  Right now it doesn't do a very good job;
when faced with delays longer than the built-in slop setting
(currently 10 ms) it completely loses track of what's happening.  It
thinks the late submissions are actually far too early (it's dealing
with a hardware schedule arranged as a ring buffer with length 512 or
1024 ms) and never gets back on track.

I've got a patch ready for testing that improves this behavior, but it
fixes only part of the problem.  Resynchronization afterward remains an
issue.

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

[PATCH RESEND] usb: ohci: Fix Kconfig dependency on USB_ISP1301

[Roland Stigge]

With select USB_ISP1301 ..., it could happen that I2C isn't selected although
USB_ISP1301 depends on it. Fixing with depends on ... and emulating the
condition via || !().

Signed-off-by: Roland Stigge sti...@antcom.de
Acked-by: Alan Stern st...@rowland.harvard.edu
---
 drivers/usb/host/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.orig/drivers/usb/host/Kconfig
+++ linux-2.6/drivers/usb/host/Kconfig
@@ -292,7 +292,7 @@ config USB_OHCI_HCD
depends on USB  USB_ARCH_HAS_OHCI
select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3
select USB_OTG_UTILS if ARCH_OMAP
-   select USB_ISP1301 if ARCH_LPC32XX
+   depends on USB_ISP1301 || !ARCH_LPC32XX
---help---
  The Open Host Controller Interface (OHCI) is a standard for accessing
  USB 1.1 host controller hardware.  It does more in hardware than 
Intel's
--
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: loosing data on usb?

[Marek Floriańczyk]

Dnia sobota, 1 września 2012 o 22:51:42 Alan Stern napisał(a):
 On Sat, 1 Sep 2012, Marek Floriańczyk wrote:
   It's possible that data is getting lost, but it's pretty unlikely.  The
   only way to get more detailed debugging information is to use a USB bus
   analyzer.
  
  HI,
  
  You mean hardware device that is connected into the usb bus something
  like this: http://www.fte.com/products/FTS4USB.aspx
 
 Yes, that or something like it.  For example:
 http://www.totalphase.com/products/beagle_usb480
 
  Or do you mean some software that I can use on linux, if so could you
  please recommend any, all I can find is for windows :(
 
 No, not software.  No Linux software will be able to display any more
 information than usbmon.
 
   You could do more testing.  For example, run the same program but
   comment out the parts that talk to the device on bus 3.  Or plug the
   devices into each other's ports, or swap the serial numbers in the
   program.
  
  I can send commands separately to each device, and then there is no
  problem. Changing serial numbers won't work, application has class
  usb-manager that during start creates objects MyUsb and each object is
  given device id vendor id and serial number, to connect to CKOZ gateway.
 
 You could change the order of which device you send the command to
 first.

HI,

Debian testing, kernel 3.2.0-3 and results are the same. Order in which I call 
devices is important, first device I call always gives reply, second one almost 
never, no matter on what bus number they are. When I insert some delay between 
commands  (500 ms) everything works fine - i got reply from both devices, 
always.
Unfortunately I don't have usb tester, but maybe I will try to do test app on 
windows, so I will get some confirmation.

regards
Marek



 
 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: loosing data on usb?

[Alan Stern]

On Mon, 3 Sep 2012, Marek Floriańczyk wrote:

 HI,
 
 Debian testing, kernel 3.2.0-3 and results are the same. Order in which I 
 call 
 devices is important, first device I call always gives reply, second one 
 almost 
 never, no matter on what bus number they are. When I insert some delay 
 between 
 commands  (500 ms) everything works fine - i got reply from both devices, 
 always.
 Unfortunately I don't have usb tester, but maybe I will try to do test app on 
 windows, so I will get some confirmation.

This is puzzling.  Since the devices are on different buses, they
should be totally independent, right?  Unless they can communicate over
some other medium (not USB).

Can you try running the program on a different computer, to help rule 
out USB hardware problems on the motherboard?

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: loosing data on usb?

[Marek Floriańczyk]

Dnia poniedziałek, 3 września 2012 o 22:00:03 Alan Stern napisał(a):
 On Mon, 3 Sep 2012, Marek Floriańczyk wrote:
  HI,
  
  Debian testing, kernel 3.2.0-3 and results are the same. Order in which I
  call devices is important, first device I call always gives reply,
  second one almost never, no matter on what bus number they are. When I
  insert some delay between commands  (500 ms) everything works fine - i
  got reply from both devices, always.
  Unfortunately I don't have usb tester, but maybe I will try to do test
  app on windows, so I will get some confirmation.
 
 This is puzzling.  Since the devices are on different buses, they
 should be totally independent, right?  Unless they can communicate over
 some other medium (not USB).
 
 Can you try running the program on a different computer, to help rule
 out USB hardware problems on the motherboard?

I did this today, I installed new system on different machine to test new 
kernel, and they behave identically.

But you know, devices are communicating with remote actuators by radio 
frequency, and remote actuators are sending status by radiograms. I was told 
that devices have some system to distinguish between commands that are 
directed to them or to other device, but there is always a chance that 
radiograms somehow interfere with each other.

I can always write to manufacturer of this devices and ask for confirmation, 
and I probably will.

regards.
Marek

 
 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: [RFC] How to handle delays in isochronous transfers?

[Clemens Ladisch]

Alan Stern wrote:
 On Mon, 3 Sep 2012, Clemens Ladisch wrote:
 The audio driver wouldn't care.  Logically, it starts a new stream.

 Really?  Why not just skip a few packets and carry on with the existing
 stream?
 Logically, the situation isn't very different from what happens when
 packets are lost in transit (except for the fact that outgoing packets
 can be lost without the host's knowledge).

A few lost packets do not affect the timing of completion interrupts/
callbacks.  However, when the queuing is broken, the completions arrive
in a way that makes the stream to appear to slow down, and then to speed
up when the HCD is trying to resynchronize.

Some jitter in the reported stream progress is acceptable (and USB audio
already is infamous for that, due to the 1 ms frame granularity and the
fact that URBs often span many frames).  But when the timing errors
become too big, synchronization with other real-time events gets lost.

Where exactly the boundary between small errors to be ignored and big
fatal errors lies is of course rather fuzzy.  However, by selecting
a particular queue length, drivers have control over this boundary.

 Does the behavior vary (or need to vary) according to the stream's
 direction?

Oh well.  There are no sample counters, so if any capture packet is
dropped, we do not know how many samples are missing.  (I've never
heard of this happening in practice though.)

 My reason for bringing this up is because I want to improve the way
 ehci-hcd handles such things.  Right now it doesn't do a very good job;
 when faced with delays longer than the built-in slop setting
 (currently 10 ms) it completely loses track of what's happening.  It
 thinks the late submissions are actually far too early (it's dealing
 with a hardware schedule arranged as a ring buffer with length 512 or
 1024 ms) and never gets back on track.

 I've got a patch ready for testing that improves this behavior, but it
 fixes only part of the problem.  Resynchronization afterward remains an
 issue.

From the audio driver's point of view, resynchronization by the HCD is
not even necessary.


Regards,
Clemens
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] How to handle delays in isochronous transfers?

[Alan Stern]

On Mon, 3 Sep 2012, Clemens Ladisch wrote:

 Alan Stern wrote:
  On Mon, 3 Sep 2012, Clemens Ladisch wrote:
  The audio driver wouldn't care.  Logically, it starts a new stream.
 
  Really?  Why not just skip a few packets and carry on with the existing
  stream?
  Logically, the situation isn't very different from what happens when
  packets are lost in transit (except for the fact that outgoing packets
  can be lost without the host's knowledge).
 
 A few lost packets do not affect the timing of completion interrupts/
 callbacks.  However, when the queuing is broken, the completions arrive
 in a way that makes the stream to appear to slow down, and then to speed
 up when the HCD is trying to resynchronize.

...

 From the audio driver's point of view, resynchronization by the HCD is
 not even necessary.

There are two possibilities to consider when an URB containing several 
packets of data is submitted:

 1. The slots for the first few packets have already expired, but
the remaining packets will be transferred okay.

 2. The slots for all the packets in the URB have expired.

In case 1 there is data loss but the queuing remains intact.  In case 2 
the queuing is broken.

It sounds like you're saying that case 1 submissions should succeed
(and return -EXDEV status for the statuses of the missed packets), 
whereas case 2 submissions should fail outright (say with an -EXDEV
error, which is currently not used for URB submission).  Then
resynchronization becomes the audio driver's problem entirely.

Would that be okay?

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: surfstick K5006-Z in 3.6.0-rc4

[Thomas Schäfer]

Despite the patch

{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1018, 0xff, 0xff, 
0xff),
  .driver_info = (kernel_ulong_t)net_intf3_blacklist },

is included in option, it has no effect.

[ 1109.116127] usb 1-4: new high-speed USB device number 3 using ehci_hcd
[ 1109.251733] usb 1-4: New USB device found, idVendor=19d2, idProduct=1017
[ 1109.251750] usb 1-4: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[ 1109.251764] usb 1-4: Product: ZTE LTE Technologies MSM
[ 1109.251777] usb 1-4: Manufacturer: ZTE,Incorporated
[ 1109.251788] usb 1-4: SerialNumber: MF821VVDFS02
[ 1109.298493] usbcore: registered new interface driver uas
[ 1109.305952] Initializing USB Mass Storage driver...
[ 1109.312239] scsi4 : usb-storage 1-4:1.0
[ 1109.312541] usbcore: registered new interface driver usb-storage
[ 1109.312547] USB Mass Storage support registered.
[ 1112.473337] usb 1-4: USB disconnect, device number 3
[ 1116.932128] usb 1-4: new high-speed USB device number 4 using ehci_hcd
[ 1117.067894] usb 1-4: New USB device found, idVendor=19d2, idProduct=1018
[ 1117.067908] usb 1-4: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[ 1117.067918] usb 1-4: Product: ZTE LTE Technologies MSM
[ 1117.067926] usb 1-4: Manufacturer: ZTE,Incorporated
[ 1117.067934] usb 1-4: SerialNumber: MF821VVDFS02
[ 1117.073642] scsi5 : usb-storage 1-4:1.4
[ 1117.116156] usbcore: registered new interface driver cdc_wdm
[ 1117.125924] qmi_wwan 1-4:1.3: cdc-wdm0: USB WDM device
[ 1117.126454] qmi_wwan 1-4:1.3: wwan0: register 'qmi_wwan' at 
usb-:00:1d.7-4, WWAN/QMI device, 46:91:ff:c8:e6:8e
[ 1117.126558] usbcore: registered new interface driver qmi_wwan
[ 1118.073723] scsi 5:0:0:0: CD-ROMVodafone USB SCSI CD-ROM  2.31 
PQ: 0 ANSI: 0
[ 1118.074384] scsi 5:0:0:0: Attached scsi generic sg1 type 5
[ 1118.075607] scsi 5:0:0:1: Direct-Access Vodafone Storage  2.31 
PQ: 0 ANSI: 0
[ 1118.077038] sd 5:0:0:1: Attached scsi generic sg2 type 0
[ 1118.083514] sd 5:0:0:1: [sdb] Attached SCSI removable disk
[ 1118.100971] sr0: scsi-1 drive
[ 1118.100980] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 1118.101388] sr 5:0:0:0: Attached scsi CD-ROM sr0


I don't have the module option blacklisted.

All other devices I have (two from huawei, two from zte ) with the combination 
option/qmi still work.

echo-ing  to new_id works too.

Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] How to handle delays in isochronous transfers?

[Peter Chen]

 In such a situation, the delay is much bigger than the device's buffer,
 so just sending more samples afterwards will not help.

It is ISO transfer, if the delay is too much, and the buffer at device side is
empty, it is normal the screen is stopped like we watch movie on Internet
(buffering).

So if the delay is too much, I don't think there is a way can deal with it as
host does not send any data to device.

 Furthermore, if packets are lost, frequency feedback becomes impossible
 because the device doesn't know how many samples were lost.
Where the packets are lost?
If the packets are lost at class driver/usb driver, class driver will
know it and
should take the responsible to re-send it.
If the packets are lost on the USB bus (during the transfer), as it is
ISO transfer,
then the data should be lost, and host doesn't know the data is lost,  how can
it re-sends the packet?



 Regards,
 Clemens

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] How to handle delays in isochronous transfers?

[Jassi Brar]

[CC'ing an USB audio heavyweight - Daniel Mack]

On Tue, Sep 4, 2012 at 12:39 AM, Alan Stern st...@rowland.harvard.edu wrote:
 On Mon, 3 Sep 2012, Jassi Brar wrote:

 On Fri, Aug 31, 2012 at 11:56 PM, Alan Stern st...@rowland.harvard.edu 
 wrote:
  Clemens and Laurent (and anyone else who's interested):
 
  How should the lower USB layers handle delays in transferring
  isochronous data?  I'm asking you because the most common usages of
  isochronous transfers are for audio and video.
 
  Here's an example to illustrate what I mean.  Typically an audio or
  video driver will keep a queue of around 10 ms of data submitted to an
  isochronous endpoint.  I have seen reports from users where URB
  completion interrupts were delayed by as much as 50 ms.  In one case
  the delay was caused by a bug in a wireless drivers that left
  interrupts disabled; in another case the cause was unknown -- it might
  have been a hardware problem.  At any rate, when this happens the
  endpoint's queue drains completely.
 
  Clearly this will cause a glitch in the data stream.  The question is:
  What should we do to recover and re-synchronize?
 
 How about effectively increasing the queue length from 10ms to 50ms
 (max anticipated latency) ?

 There are two problems with that approach.  First, 50 ms isn't really
 the max anticipated latency; it's merely the largest that I've seen so
 far.  (In fact, the max anticipated latency is probably  10 ms; these
 50-ms delays were definitely exceptional.)

It doesn't have to be hardcoded - maybe USB audio/video code could get
the hint via some module parameter?

 Second, people involved in real-time programming (such as audio or
 video) generally want to keep latency to a minimum.

If we progress the h/w pointer of ALSA ring buffer at URB completion
(and not at URB submission), this shouldn't affect the latency. And
IIRC, USB isn't anyway recommended for real-time usage.

cheers.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net] net: usbnet: fix softirq storm on suspend

[Ming Lei]

On Mon, Sep 3, 2012 at 4:26 PM, Bjørn Mork bj...@mork.no wrote:
 Suspending an open usbnet device results in constant
 rescheduling of usbnet_bh.

 commit 65841fd5 usbnet: handle remote wakeup asap
 refactored the usbnet_bh code to allow sharing the
 urb allocate and submit code with usbnet_resume. In
 this process, a test for, and immediate return on,
 ENOLINK from rx_submit was unintentionally dropped.

 The rx queue will not grow if rx_submit fails,
 making usbnet_bh reschedule itself.  This results
 in a softirq storm if the error is persistent.
 rx_submit translates the usb_submit_urb error
 EHOSTUNREACH into ENOLINK, so this is an expected
 and persistent error for a suspended device. The
 old code tested for this condition and avoided
 rescheduling.  Putting this test back.

 Cc: sta...@vger.kernel.org # v3.5
 Cc: Ming Lei ming@canonical.com
 Cc: Oliver Neukum oneu...@suse.de
 Signed-off-by: Bjørn Mork bj...@mork.no
 ---
 Sorry for not noticing this before, but commit 65841fd5
 makes usbnet autosuspend completely unusable.  The device
 is suspended fine, but burning one CPU core at full load
 uses a tiny bit more power making the power saving
 negative...

I am wondering how you can reproduce the issue.

usbnet_terminate_urbs is called inside usbnet_suspend to
consume all URBs and SKBs, and rx_alloc_submit can't be
called during the period because of !netif_device_present().
Once usbnet_terminate_urbs and netif_device_attach() are
completed, who will schedule tasklet to trigger rx_alloc_submit?


 I hope this can go into 3.6 and 3.5-stable ASAP. It is
 a hard to notice regression, but all the same a serious
 one.

Thanks,
--
Ming Lei
--
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: phy: add R-Car R8A7779 USB phy driver.

[Kuninori Morimoto]

This patch adds Renesas R-Car USB phy driver.
It supports R8A7779 chip at this point.

Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
 drivers/usb/phy/Kconfig|   11 
 drivers/usb/phy/Makefile   |1 +
 drivers/usb/phy/rcar-phy.c |  137 
 3 files changed, 149 insertions(+)
 create mode 100644 drivers/usb/phy/rcar-phy.c

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 2838adb..f55b6f6 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -23,3 +23,14 @@ config MV_U3D_PHY
help
  Enable this to support Marvell USB 3.0 phy controller for Marvell
  SoC.
+
+config USB_RCAR_PHY
+   tristate Renesas R-Car USB phy support
+   depends on (USB || USB_GADGET)  ARCH_R8A7779
+   help
+ Say Y here to add support for the Renesas R-Car USB phy driver.
+ This chip is typically used as USB phy for USB host, gadget.
+ This driver supports: R8A7779
+
+ To compile this driver as a module, choose M here: the
+ module will be called rcar-phy.
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index cf38f08..9af83f0 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -6,3 +6,4 @@ ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
 
 obj-$(CONFIG_USB_ISP1301)  += isp1301.o
 obj-$(CONFIG_MV_U3D_PHY)   += mv_u3d_phy.o
+obj-$(CONFIG_USB_RCAR_PHY) += rcar-phy.o
diff --git a/drivers/usb/phy/rcar-phy.c b/drivers/usb/phy/rcar-phy.c
new file mode 100644
index 000..deec078
--- /dev/null
+++ b/drivers/usb/phy/rcar-phy.c
@@ -0,0 +1,137 @@
+/*
+ * Renesas R-Car USB phy driver
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Kuninori Morimoto kuninori.morimoto...@renesas.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/io.h
+#include linux/platform_device.h
+#include linux/module.h
+
+/* USBH common register */
+#define USBPCTRL0  0x0800
+#define USBPCTRL1  0x0804
+#define USBST  0x0808
+#define USBEH0 0x080C
+#define USBOH0 0x081C
+#define USBCTL00x0858
+#define EIIBC1 0x0094
+#define EIIBC2 0x009C
+
+#ifdef CONFIG_ARCH_SUPPORTS_BIG_ENDIAN
+# define PHY_ENDIAN BIG
+# define PHY_NO_SWAP 0x0003
+#else
+# define PHY_ENDIAN LITTLE
+# define PHY_NO_SWAP 0x
+#endif
+
+/*
+ * USB initial/install operation.
+ *
+ * This function setup USB phy.
+ * The used value and setting order came from
+ * [USB :: Initial setting] on datasheet.
+ */
+static int rcar_phy_probe(struct platform_device *pdev)
+{
+   struct resource *res0, *res1;
+   void __iomem *reg0, *reg1;
+   int i, ret = 0;
+   u32 val;
+
+   res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   if (!res0 || !res1) {
+   dev_err(pdev-dev, Not enough platform resources\n);
+   return -ENODEV;
+   }
+
+   reg0 = ioremap_nocache(res0-start, resource_size(res0));
+   reg1 = ioremap_nocache(res1-start, resource_size(res1));
+   if (!reg0 || !reg1) {
+   dev_err(pdev-dev, ioremap error.\n);
+   ret = -ENOMEM;
+   goto end;
+   }
+
+   /**
+* USB phy start-up
+**/
+
+   /* (1) USB-PHY standby release */
+   iowrite32(0x0001, (reg0 + USBPCTRL1));
+
+   /* (2) start USB-PHY internal PLL */
+   iowrite32(0x0003, (reg0 + USBPCTRL1));
+
+   /* (3) USB module status check */
+   for (i = 0; i  1024; i++) {
+   udelay(10);
+   val = ioread32(reg0 + USBST);
+   if (0xc000 == val)
+   goto usb_module_is_working;
+   }
+   dev_err(pdev-dev, USB module not ready\n);
+   ret = -EIO;
+   goto end;
+
+usb_module_is_working:
+   /* (4) USB-PHY reset clear */
+   iowrite32(0x0007, (reg0 + USBPCTRL1));
+
+   /* set platform specific port settings */
+   iowrite32(0x, (reg0 + USBPCTRL0));
+
+   /**
+* EHCI IP Internal Buffer Setting
+**/
+
+   /* (1) EHCI IP internal buffer setting */
+   iowrite32(0x00ff0040, (reg0 + EIIBC1));
+   iowrite32(0x00ff0040, (reg1 + EIIBC1));
+
+   /* (2) EHCI IP internal buffer enable */
+   iowrite32(0x0001, (reg0 + EIIBC2));
+   iowrite32(0x0001, (reg1 + EIIBC2));
+
+   /**
+* Bus alignment settings
+**/
+
+   /* (1) EHCI bus alignment */