Re: [RFC 0/9] OS Descriptors support

2014-05-04 Thread Andrzej Pietrasiewicz 

Hi Felipe,

W dniu 30.04.2014 18:24, Felipe Balbi pisze:

On Thu, Apr 24, 2014 at 11:17:11AM +0200, Andrzej Pietrasiewicz wrote:

There is a custom (non-USB IF) extension to the USB standard:

http://msdn.microsoft.com/library/windows/hardware/gg463182





are you sure there isn't some crappy patent from MS which would prevent
us from implementing this ?



Under the link mentioned above there is a scrollable area under the heading
"Please read the license agreement before continuing".
In the said "license agreement" there is Section 2, "GRANT OF LICENSE",
where letter (b) reads:

"Patent license.  Microsoft hereby grants to You a nonexclusive,
royalty-free, nontransferable, worldwide license under Microsoft’s
patents embodied solely within the Specification and that are owned
or licensable by Microsoft to make, use, import, offer to sell,
sell and distribute directly or indirectly to Your Licensees
Your Implementation. You may sublicense this patent license
to Your Licensees under the same terms and conditions."

I am not a native speaker nor a lawyer, but it seems to me that
they do grant a royalty-free license to their patents used in the
specification, for the purpose of (among others) making
"Our Implementation" and distributing it to "Our Licensees".
And "We" do have "Our Licensees", who are anyone using Linux -
anyone using Linux agrees to the GPL.

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

Clarification regarding USB Data Card (3G Dongle) enumeration in Linux udev

2014-05-04 Thread Suresh Kumar N. 
Hi,

I am new to udev and device enumeration.

I am interested to know how USB Data Card would get enumerated.

Based on my understanding Data Card can get enumerated below 2 possible ways -
  1. As a modem
  2. As a Network Interface Card (NIC)

Is there a Standard defining the way a Data Card should be enumerated?

Please correct if my understanding is not correct or incomplete.

Thanks in advance for your clarifications.

Warm Regards,
Suresh
--
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 v4 2/4] usb: ehci-exynos: Use struct device instead of platform_device

2014-05-04 Thread Vivek Gautam 
Change to use struct device instead of struct platform_device
for some static functions.

Signed-off-by: Vivek Gautam 
Acked-by: Alan Stern 
Acked-by: Jingoo Han 
Acked-by: Kukjin Kim 
---

Changes since v1:
 - none

 drivers/usb/host/ehci-exynos.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 7f425ac..4d763dc 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -50,9 +50,8 @@ struct exynos_ehci_hcd {
 
 #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv)
 
-static void exynos_setup_vbus_gpio(struct platform_device *pdev)
+static void exynos_setup_vbus_gpio(struct device *dev)
 {
-   struct device *dev = &pdev->dev;
int err;
int gpio;
 
@@ -88,7 +87,7 @@ static int exynos_ehci_probe(struct platform_device *pdev)
if (err)
return err;
 
-   exynos_setup_vbus_gpio(pdev);
+   exynos_setup_vbus_gpio(&pdev->dev);
 
hcd = usb_create_hcd(&exynos_ehci_hc_driver,
 &pdev->dev, dev_name(&pdev->dev));
-- 
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 v4 1/4] usb: ohci-exynos: Use struct device instead of platform_device

2014-05-04 Thread Vivek Gautam 
Change to use struct device instead of struct platform_device
for some static functions.

Signed-off-by: Vivek Gautam 
Acked-by: Alan Stern 
Acked-by: Jingoo Han 
Acked-by: Kukjin Kim 
---

Changes since v1:
 - none

 drivers/usb/host/ohci-exynos.c |   20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 9cf80cb..05f00e3 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -39,18 +39,18 @@ struct exynos_ohci_hcd {
struct usb_otg *otg;
 };
 
-static void exynos_ohci_phy_enable(struct platform_device *pdev)
+static void exynos_ohci_phy_enable(struct device *dev)
 {
-   struct usb_hcd *hcd = platform_get_drvdata(pdev);
+   struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
 
if (exynos_ohci->phy)
usb_phy_init(exynos_ohci->phy);
 }
 
-static void exynos_ohci_phy_disable(struct platform_device *pdev)
+static void exynos_ohci_phy_disable(struct device *dev)
 {
-   struct usb_hcd *hcd = platform_get_drvdata(pdev);
+   struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
 
if (exynos_ohci->phy)
@@ -139,7 +139,7 @@ skip_phy:
 
platform_set_drvdata(pdev, hcd);
 
-   exynos_ohci_phy_enable(pdev);
+   exynos_ohci_phy_enable(&pdev->dev);
 
err = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (err) {
@@ -150,7 +150,7 @@ skip_phy:
return 0;
 
 fail_add_hcd:
-   exynos_ohci_phy_disable(pdev);
+   exynos_ohci_phy_disable(&pdev->dev);
 fail_io:
clk_disable_unprepare(exynos_ohci->clk);
 fail_clk:
@@ -168,7 +168,7 @@ static int exynos_ohci_remove(struct platform_device *pdev)
if (exynos_ohci->otg)
exynos_ohci->otg->set_host(exynos_ohci->otg, &hcd->self);
 
-   exynos_ohci_phy_disable(pdev);
+   exynos_ohci_phy_disable(&pdev->dev);
 
clk_disable_unprepare(exynos_ohci->clk);
 
@@ -190,7 +190,6 @@ static int exynos_ohci_suspend(struct device *dev)
 {
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
-   struct platform_device *pdev = to_platform_device(dev);
bool do_wakeup = device_may_wakeup(dev);
int rc = ohci_suspend(hcd, do_wakeup);
 
@@ -200,7 +199,7 @@ static int exynos_ohci_suspend(struct device *dev)
if (exynos_ohci->otg)
exynos_ohci->otg->set_host(exynos_ohci->otg, &hcd->self);
 
-   exynos_ohci_phy_disable(pdev);
+   exynos_ohci_phy_disable(dev);
 
clk_disable_unprepare(exynos_ohci->clk);
 
@@ -211,14 +210,13 @@ static int exynos_ohci_resume(struct device *dev)
 {
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
-   struct platform_device *pdev= to_platform_device(dev);
 
clk_prepare_enable(exynos_ohci->clk);
 
if (exynos_ohci->otg)
exynos_ohci->otg->set_host(exynos_ohci->otg, &hcd->self);
 
-   exynos_ohci_phy_enable(pdev);
+   exynos_ohci_phy_enable(dev);
 
ohci_resume(hcd, false);
 
-- 
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 v6 3/4] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework

2014-05-04 Thread Vivek Gautam 
Add support to consume phy provided by Generic phy framework.
Keeping the support for older usb-phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ohci-exynos.
Once we move to new phy in the device nodes for ohci, we can
remove the support for older phys.

Signed-off-by: Vivek Gautam 
Cc: Jingoo Han 
Acked-by: Alan Stern 
Acked-by: Kukjin Kim 
---

Changes from v5:
 - Removed setting phy explicitly to error pointer.
 - Changed error check to '-ENOSYS' instead of '-ENXIO' in failure case of
   devm_of_phy_get().

Changes from v4:
 - Removed 'phy-names' property from the bindings since we don't need it.
 - Restructured exynos_ohci_get_phy() function to handle error codes as
   well as return relevant error codes effectively.
 - Added IS_ERR() check for PHYs in exynos_ohci_phy_enable()/disable().

Changes from v3:
 - Calling usb_phy_shutdown() when exynos_ohci_phy_enable() is failing.
 - Made exynos_ohci_phy_disable() return void, since its return value
   did not serve any purpose.
 - Calling clk_disable_unprepare() in exynos_ohci_resume() when
   exynos_ohci_phy_enable() is failed.

 .../devicetree/bindings/usb/exynos-usb.txt |   16 +++
 drivers/usb/host/ohci-exynos.c |  118 +---
 2 files changed, 118 insertions(+), 16 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index d967ba1..49a9c6f 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -38,6 +38,13 @@ Required properties:
  - interrupts: interrupt number to the cpu.
  - clocks: from common clock binding: handle to usb clock.
  - clock-names: from common clock binding: Shall be "usbhost".
+ - port: if in the SoC there are OHCI phys, they should be listed here.
+   One phy per port. Each port should have following entries:
+   - reg: port number on OHCI controller, e.g
+  On Exynos5250, port 0 is USB2.0 otg phy
+ port 1 is HSIC phy0
+ port 2 is HSIC phy1
+   - phys: from the *Generic PHY* bindings, specifying phy used by port.
 
 Example:
usb@1212 {
@@ -47,6 +54,15 @@ Example:
 
clocks = <&clock 285>;
clock-names = "usbhost";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   phys = <&usb2phy 1>;
+   status = "disabled";
+   };
+
};
 
 DWC3
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 05f00e3..32f2ff1 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -33,28 +34,110 @@ static struct hc_driver __read_mostly 
exynos_ohci_hc_driver;
 
 #define to_exynos_ohci(hcd) (struct exynos_ohci_hcd *)(hcd_to_ohci(hcd)->priv)
 
+#define PHY_NUMBER 3
+
 struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+   struct phy *phy_g[PHY_NUMBER];
 };
 
-static void exynos_ohci_phy_enable(struct device *dev)
+static int exynos_ohci_get_phy(struct device *dev,
+   struct exynos_ohci_hcd *exynos_ohci)
+{
+   struct device_node *child;
+   struct phy *phy;
+   int phy_number;
+   int ret = 0;
+
+   exynos_ohci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+   if (IS_ERR(exynos_ohci->phy)) {
+   ret = PTR_ERR(exynos_ohci->phy);
+   if (ret != -ENXIO && ret != -ENODEV) {
+   dev_err(dev, "no usb2 phy configured\n");
+   return ret;
+   }
+   dev_dbg(dev, "Failed to get usb2 phy\n");
+   } else {
+   exynos_ohci->otg = exynos_ohci->phy->otg;
+   }
+
+   /*
+* Getting generic phy:
+* We are keeping both types of phys as a part of transiting OHCI
+* to generic phy framework, so as to maintain backward compatibilty
+* with old DTB.
+* If there are existing devices using DTB files built from them,
+* to remove the support for old bindings in this driver,
+* we need to make sure that such devices have their DTBs
+* updated to ones built from new DTS.
+*/
+   for_each_available_child_of_node(dev->of_node, child) {
+   ret = of_property_read_u32(child, "reg", &phy_number);
+   if (ret) {
+   dev_err(dev, "Failed to parse device tree\n");
+   of_node_put(child);
+   return ret;
+   }
+
+   if (phy_number >= PHY_NUMBER) {
+   dev_err(dev, "Invalid number of PHYs\n");
+

[PATCH v12 4/4] usb: ehci-exynos: Change to use phy provided by the generic phy framework

2014-05-04 Thread Vivek Gautam 
From: Kamil Debski 

Add the phy provider, supplied by new Exynos-usb2phy using
Generic phy framework.
Keeping the support for older USB phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ehci-exynos.
Once we move to new phy in the device nodes for ehci, we can
remove the support for older phys.

Signed-off-by: Kamil Debski 
[gautam.vi...@samsung.com: Addressed review comments from mailing list]
[gautam.vi...@samsung.com: Kept the code for old usb-phy, and just
added support for new exynos5-usb2phy in generic phy framework]
[gautam.vi...@samsung.com: Edited the commit message]
Signed-off-by: Vivek Gautam 
Cc: Jingoo Han 
Acked-by: Alan Stern 
Acked-by: Kukjin Kim 
---

Changes from v11:
 - Removed setting phy explicitly to error pointer.
 - Changed error check to '-ENOSYS' instead of '-ENXIO' in failure case of
   devm_of_phy_get().

Changes from v10:
 - Removed 'phy-names' property from the bindings since we don't need it.
 - Restructured exynos_ehci_get_phy() function to handle error codes as
   well as return relevant error codes effectively.
 - Added IS_ERR() check for PHYs in exynos_ehci_phy_enable()/disable().

Changes from v9:
 - Calling usb_phy_shutdown() when exynos_ehci_phy_enable() is failing.
 - Made exynos_ehci_phy_disable() return void, since its return value
   did not serve any purpose.
 - Calling clk_disable_unprepare() in exynos_ehci_resume() when
   exynos_ehci_phy_enable() is failed.

 .../devicetree/bindings/usb/exynos-usb.txt |   15 +++
 drivers/usb/host/ehci-exynos.c |  129 +---
 2 files changed, 124 insertions(+), 20 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index 49a9c6f..a3b5990 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -12,6 +12,13 @@ Required properties:
  - interrupts: interrupt number to the cpu.
  - clocks: from common clock binding: handle to usb clock.
  - clock-names: from common clock binding: Shall be "usbhost".
+ - port: if in the SoC there are EHCI phys, they should be listed here.
+   One phy per port. Each port should have following entries:
+   - reg: port number on EHCI controller, e.g
+  On Exynos5250, port 0 is USB2.0 otg phy
+ port 1 is HSIC phy0
+ port 2 is HSIC phy1
+   - phys: from the *Generic PHY* bindings; specifying phy used by port.
 
 Optional properties:
  - samsung,vbus-gpio:  if present, specifies the GPIO that
@@ -27,6 +34,14 @@ Example:
 
clocks = <&clock 285>;
clock-names = "usbhost";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   phys = <&usb2phy 1>;
+   status = "disabled";
+   };
};
 
 OHCI
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 4d763dc..c7081c7 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -42,14 +43,104 @@
 static const char hcd_name[] = "ehci-exynos";
 static struct hc_driver __read_mostly exynos_ehci_hc_driver;
 
+#define PHY_NUMBER 3
+
 struct exynos_ehci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+   struct phy *phy_g[PHY_NUMBER];
 };
 
 #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv)
 
+static int exynos_ehci_get_phy(struct device *dev,
+   struct exynos_ehci_hcd *exynos_ehci)
+{
+   struct device_node *child;
+   struct phy *phy;
+   int phy_number;
+   int ret = 0;
+
+   exynos_ehci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+   if (IS_ERR(exynos_ehci->phy)) {
+   ret = PTR_ERR(exynos_ehci->phy);
+   if (ret != -ENXIO && ret != -ENODEV) {
+   dev_err(dev, "no usb2 phy configured\n");
+   return ret;
+   }
+   dev_dbg(dev, "Failed to get usb2 phy\n");
+   } else {
+   exynos_ehci->otg = exynos_ehci->phy->otg;
+   }
+
+   for_each_available_child_of_node(dev->of_node, child) {
+   ret = of_property_read_u32(child, "reg", &phy_number);
+   if (ret) {
+   dev_err(dev, "Failed to parse device tree\n");
+   of_node_put(child);
+   return ret;
+   }
+
+   if (phy_number >= PHY_NUMBER) {
+   dev_err(dev, "Invalid number of PHYs\n");
+   of_node_put(child);
+   return -EINVAL;
+   }
+
+   phy = devm_of_phy_ge

[PATCH 1/1] usb: gadget: configfs: fix typo

2014-05-04 Thread Peter Chen 
%s/atleast/at least

Signed-off-by: Peter Chen 
---
 drivers/usb/gadget/configfs.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 7d1cc01..c823d59 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -793,7 +793,7 @@ static int configfs_composite_bind(struct usb_gadget 
*gadget,
ret = -EINVAL;
 
if (list_empty(&gi->cdev.configs)) {
-   pr_err("Need atleast one configuration in %s.\n",
+   pr_err("Need at least one configuration in %s.\n",
gi->composite.name);
goto err_comp_cleanup;
}
@@ -804,7 +804,7 @@ static int configfs_composite_bind(struct usb_gadget 
*gadget,
 
cfg = container_of(c, struct config_usb_cfg, c);
if (list_empty(&cfg->func_list)) {
-   pr_err("Config %s/%d of %s needs atleast one 
function.\n",
+   pr_err("Config %s/%d of %s needs at least one 
function.\n",
  c->label, c->bConfigurationValue,
  gi->composite.name);
goto err_comp_cleanup;
-- 
1.7.8

--
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 1/1] usb: chipidea: udc: delete useless code

2014-05-04 Thread Peter Chen 
Delete useless code

Signed-off-by: Peter Chen 
---

- Changes for v2:
%s/usbless/useless

 drivers/usb/chipidea/udc.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index d683968..69425b3 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -825,7 +825,6 @@ __acquires(hwep->lock)
if ((setup->bRequestType & USB_RECIP_MASK) == USB_RECIP_DEVICE) {
/* Assume that device is bus powered for now. */
*(u16 *)req->buf = ci->remote_wakeup << 1;
-   retval = 0;
} else if ((setup->bRequestType & USB_RECIP_MASK) \
   == USB_RECIP_ENDPOINT) {
dir = (le16_to_cpu(setup->wIndex) & USB_ENDPOINT_DIR_MASK) ?
-- 
1.7.8

--
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: Bugs in xhci-hcd isochronous support

2014-05-04 Thread Russel Hughes 
> The audio data is contained in the lines that have a 'Z'.  Just search
> for the first such line and then go back twenty or so lines before that
> to provide some context.
>
> Alan Stern

This OK?

BR

Russel



fff880211c1e000 2991052997 S Ii:2:002:3 -115:32 2 <
880036d09480 2991060964 C Ii:2:003:2 0:8 7 = 02f0 ff
880036d09480 2991060996 S Ii:2:003:2 -115:8 20 <
880211c1e000 2991084868 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991084875 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991116869 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991116886 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991148920 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991148934 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991180881 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991180891 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991212916 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991212930 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991244869 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991244882 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991276888 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991276896 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991308916 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991308929 S Ii:2:002:3 -115:32 2 <
880036d09480 2991333025 C Ii:2:003:2 0:8 7 = 0201 00
880036d09480 2991333061 S Ii:2:003:2 -115:8 20 <
880211c1e000 2991340916 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991340929 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991372916 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991372929 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991404885 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991404894 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991436915 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991436928 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991468853 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991468862 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991500915 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991500929 S Ii:2:002:3 -115:32 2 <
880036d09480 2991524964 C Ii:2:003:2 0:8 7 = 0200 00
880036d09480 2991524999 S Ii:2:003:2 -115:8 20 <
8800c5551300 2991527066 S Co:2:002:0 s 01 0b 0001 0002  0
8800c5551300 2991527480 C Co:2:002:0 0 0
8800c5551540 2991527571 S Co:2:002:0 s 22 01 0100 0001 0003 3 = 44ac00
8800c5551540 2991527939 C Co:2:002:0 0 3 >
8800c5551540 2991527947 S Ci:2:002:0 s a2 81 0100 0001 0003 3 <
8800c5551540 2991530030 C Ci:2:002:0 -32 0
8801fe291c00 2991530052 S Zo:2:002:1 -115:1:0 6 -18:0:264
-18:264:264 -18:528:264 -18:792:264 -18:1056:264 1584 = 
      
8801fe291000 2991530059 S Zo:2:002:1 -115:1:0 6 -18:0:264
-18:264:264 -18:528:264 -18:792:270 -18:1062:264 1590 = 
      
8801fe290c00 2991530061 S Zo:2:002:1 -115:1:0 6 -18:0:264
-18:264:264 -18:528:264 -18:792:264 -18:1056:264 1584 = 
      
880211833700 2991530062 S Zi:2:002:1 -115:32:0 1 -18:0:3 4 <
88020360b000 2991530065 S Zi:2:002:1 -115:32:0 1 -18:0:3 4 <
88020360be00 2991530066 S Zi:2:002:1 -115:32:0 1 -18:0:3 4 <
8802010e4f00 2991530067 S Zi:2:002:1 -115:32:0 1 -18:0:3 4 <
8800c5551540 2991530074 S Co:2:002:0 s 22 01 0100 0001 0003 3 = 44ac00
8800c5551540 2991530618 C Co:2:002:0 0 3 >
8800c5551540 2991530626 S Ci:2:002:0 s a2 81 0100 0001 0003 3 <
880211833700 2991531065 C Zi:2:002:1 0:1:1406:0 1 0:0:3 4 = 00030b00
880211833700 2991531069 S Zi:2:002:1 -115:1:1406 1 -18:0:3 4 <
88020360b000 2991532030 C Zi:2:002:1 0:1:1407:0 1 0:0:3 4 = 00030b00
88020360b000 2991532033 S Zi:2:002:1 -115:1:1407 1 -18:0:3 4 <
8800c5551540 2991532523 C Ci:2:002:0 -32 0
88020360be00 2991533035 C Zi:2:002:1 0:1:1408:0 1 0:0:3 4 = 00030b00
88020360be00 2991533040 S Zi:2:002:1 -115:1:1408 1 -18:0:3 4 <
880211c1e000 2991533045 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991533047 S Ii:2:002:3 -115:32 2 <
8802010e4f00 2991534022 C Zi:2:002:1 0:1:1409:0 1 0:0:3 4 = 00030b00
8802010e4f00 2991534026 S Zi:2:002:1 -115:1:1409 1 -18:0:3 4 <
880211833700 2991535024 C Zi:2:002:1 0:1:1410:0 1 0:0:3 4 = 00030b00
880211833700 2991535029 S Zi:2:002:1 -115:1:1410 1 -18:0:3 4 <
8801fe291c00 2991536017 C Zo:2:002:1 0:1:1406:0 6 0:0:264
0:264:264 0:528:264 0:792:264 0:1056:264 1584 >
8801fe291c00 2991536026 S Zo:2:002:1 -115:1:1406 6 -18:0:264
-18:264:264 -18:528:264 -18:792:264 -18:1056:270 1590 = 8dedd084
ecd387b1 d29165cf 7058daa1 2cca618d dfb1d6c4 6cc3dbbb 5bc17a4a
88020360b000 2991536031 C Zi:2:002:1 0:1:1411:0 1 0:0:3 4 = 00030b00
88020360b000 2991536032 S Zi:2:002:1 -115:1:1411 1 -18:0:3 4 <
88020360be00 2991537025 C Zi:2:002:1 0:1:1412:0 1 0:0:3 4 = 00030b00
88020360be00 2991537029 S Zi:2:002:1 -115:1:1412 1 -18:0:3 4 <
8802010e4f00 2991538033 C Zi:2:002:1 0:1:1413:0 1 0:0:3 4

Re: Bugs in xhci-hcd isochronous support

2014-05-04 Thread Alan Stern 
On Sun, 4 May 2014, Russel Hughes wrote:

> > It looks like you started the usbmon trace after the audio data
> > transfer was running.  I need to see what happens when the audio data
> > transfer begins.
> >
> > Also, is there any way you can turn off the audio-in channel while
> > running the test, so that only the audio-out is active?
> >
> > Alan Stern
> The NUC does not have anything connected to the audio input but for
> this test the input volume is muted, I do not know how to disable it,
> I will have a look. Here is the data, its a few thousand lines long as
> I was not sure when the audio data started. I can send the full file
> if you wish, its 4.7Mbyte

The audio data is contained in the lines that have a 'Z'.  Just search 
for the first such line and then go back twenty or so lines before that 
to provide some context.

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: Bugs in xhci-hcd isochronous support

2014-05-04 Thread Alan Stern 
On Sat, 3 May 2014, Russel Hughes wrote:

>  sudo cat /sys/kernel/debug/usb/usbmon/2u > /tmp/1.mon.out
> 
> first few hundred lines
> 
> 880200adef00 2596394321 C Zi:2:004:1 0:1:1833:0 1 0:0:3 4 = 00030b00
> 880200adef00 2596394330 S Zi:2:004:1 -115:1:1833 1 -18:0:3 4 <
> 8801f3c8e600 2596395313 C Zo:2:004:1 0:1:1830:0 5 0:0:264

It looks like you started the usbmon trace after the audio data
transfer was running.  I need to see what happens when the audio data
transfer begins.

Also, is there any way you can turn off the audio-in channel while 
running the test, so that only the audio-out is active?

Alan Stern


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

Re: [PATCH 2/2] usb: chipidea: udc: delete useless code

2014-05-04 Thread Sergei Shtylyov 

Hello.

On 04-05-2014 9:31, Peter Chen wrote:


Delete usbless code


   You probably wanted to type "useless"?


Signed-off-by: Peter Chen 
---
  drivers/usb/chipidea/udc.c |1 -
  1 files changed, 0 insertions(+), 1 deletions(-)



diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index d683968..69425b3 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -825,7 +825,6 @@ __acquires(hwep->lock)
if ((setup->bRequestType & USB_RECIP_MASK) == USB_RECIP_DEVICE) {
/* Assume that device is bus powered for now. */
*(u16 *)req->buf = ci->remote_wakeup << 1;
-   retval = 0;
} else if ((setup->bRequestType & USB_RECIP_MASK) \
   == USB_RECIP_ENDPOINT) {
dir = (le16_to_cpu(setup->wIndex) & USB_ENDPOINT_DIR_MASK) ?


WBR, Sergei

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

Re: [PATCH] USB: ehci-hub: wait for RESUME finished when hub try to clear SUSPEND

2014-05-04 Thread Xiao Jin 

On 05/04/2014 08:26 AM, Peter Chen wrote:

On Sat, May 03, 2014 at 11:52:25AM +0800, xiao jin wrote:

We use usb ehci to connect with modem and run stress test on ehci
remote wake. Sometimes usb disconnect. We add more debug ftrace
(Kernel version: 3.10) and list the key log to show how problem
happened.

-0 [000] d.h2 26879.385095: ehci_irq: irq status 1008c PPCE FLR PCD
-0 [000] d.h2 26879.385099: ehci_irq: rh_state[2] hcd->state[132] 
pstatus[0][238014c5] suspended_ports[1] reset_done[0]
<...>-12873 [000] d..1 26879.393536: ehci_hub_control: GetStatus port:1 status 
238014c5 17  ERR POWER sig=k SUSPEND RESUME PE CONNECT
<...>-12873 [000] d..1 26879.393549: ehci_hub_control: typeReq [2301] wIndex[1] 
wValue[2]
<...>-12873 [000] d..1 26879.393553: ehci_hub_control: [ehci_hub_control]line[891] 
 port[0] hostpc_reg [44000202]->[44000202]
-0 [001] ..s. 26879.403122: ehci_hub_status_data: 
wgq[ehci_hub_status_data] ignore_oc[0] resuming_ports[1]
<...>-12873 [000] d..1 26879.413379: ehci_hub_control: 
[ehci_hub_control]line[907]  port[0] write portsc_reg[238014c5] reset_done[2105769]
<...>-12873 [000] d..1 26879.453173: ehci_hub_control: GetStatus port:1 status 
23801885 17  ERR POWER sig=j SUSPEND PE CONNECT
<...>-12873 [000]  26879.473158: check_port_resume_type: port 1 status 
.0507 after resume, -19
<...>-12873 [000]  26879.473160: usb_port_resume: status = -19 after 
check_port_resume_type
<...>-12873 [000]  26879.473161: usb_port_resume: can't resume, status -19
<...>-12873 [000]  26879.473162: hub_port_logical_disconnect: logical 
disconnect on port 1

There is a in-band remote wakeup and controller run in k-state. Then kernel
driver(ClearPortFeature/USB_PORT_FEAT_SUSPEND) write RESUME|LS(k-state) bit
into controller. It makes controller status weird. It's defined in EHCI


Are you sure you are at this path? If there is a remote wakeup, the
sending resume signal from host controller will be skipped
(USB_PORT_FEAT_SUSPEND), see usb_port_resume at drivers/usb/core/hub.c.



Yes, I abstract more debug log to explain.

<...>-12873 [000]  26879.393496: usb_port_resume: wgq[usb_port_resume]
<...>-12873 [000]  26879.393544: usb_port_resume: status = 0 after 
hub_port_status
<...>-12873 [000] d..1 26879.393549: ehci_hub_control: 
typeReq [2301] wIndex[1] wValue[2]
   <...>-12873 [000] d..1 26879.413379: ehci_hub_control: 
[ehci_hub_control]line[907]  port[0] write portsc_reg[238014c5] 
reset_done[2105769]
   <...>-12873 [000]  26879.413401: usb_port_resume: status 
= 0 after clear_port_feature



controller spec(Revision 1.0), "If it has enabled remote wake-up, a K-state
on the bus will turn the transceiver clock and generate an interrupt. The
software will then have to wait 20 ms for the resume to complete and the
port to go back to an active state." In this case Kernel should wait for
the wakeup finished, then judge what should do next step.


Do you use a chipidea core? Try to do not clear run/stop to see if this
problem is fixed or not.



I have explained more about the problem in another mail. Please have a 
look if there still need more info.


Jin

--
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: ehci-hub: wait for RESUME finished when hub try to clear SUSPEND

2014-05-04 Thread Xiao Jin 


On 05/03/2014 11:20 PM, Alan Stern wrote:

On Sat, 3 May 2014, xiao jin wrote:


We use usb ehci to connect with modem and run stress test on ehci
remote wake. Sometimes usb disconnect. We add more debug ftrace
(Kernel version: 3.10) and list the key log to show how problem
happened.

-0 [000] d.h2 26879.385095: ehci_irq: irq status 1008c PPCE FLR PCD
-0 [000] d.h2 26879.385099: ehci_irq: rh_state[2] hcd->state[132] 
pstatus[0][238014c5] suspended_ports[1] reset_done[0]

=> kernel receive a remote wakeup irq from controller

<...>-12873 [000] d..1 26879.393536: ehci_hub_control: GetStatus port:1 status 
238014c5 17  ERR POWER sig=k SUSPEND RESUME PE CONNECT
=> PORTSC = 238014c5 (line status = K-state, suspend = 1, force port 
resume = 1, J-to-K transition is detected)

<...>-12873 [000] d..1 26879.393549: ehci_hub_control: typeReq [2301] wIndex[1] 
wValue[2]
<...>-12873 [000] d..1 26879.393553: ehci_hub_control: [ehci_hub_control]line[891] 
 port[0] hostpc_reg [44000202]->[44000202]
-0 [001] ..s. 26879.403122: ehci_hub_status_data: 
wgq[ehci_hub_status_data] ignore_oc[0] resuming_ports[1]
<...>-12873 [000] d..1 26879.413379: ehci_hub_control: 
[ehci_hub_control]line[907]  port[0] write portsc_reg[238014c5] reset_done[2105769]

=> kernel write 238014c5 to PORTSC

<...>-12873 [000] d..1 26879.453173: ehci_hub_control: GetStatus port:1 status 
23801885 17  ERR POWER sig=j SUSPEND PE CONNECT
=> PORTSC = 23801885 (line status = J-state, suspend = 1), is the status 
weird?

<...>-12873 [000]  26879.473158: check_port_resume_type: port 1 status 
.0507 after resume, -19
<...>-12873 [000]  26879.473160: usb_port_resume: status = -19 after 
check_port_resume_type
<...>-12873 [000]  26879.473161: usb_port_resume: can't resume, status -19
<...>-12873 [000]  26879.473162: hub_port_logical_disconnect: logical 
disconnect on port 1


This is a little difficult to understand...



We add some debug log manually, please let me explain a little more. See 
above "=>".



There is a in-band remote wakeup and controller run in k-state. Then kernel


What do you mean by "in-band"?



We use EHCI as host and have two kinds of mechanism to remote wakeup 
event, "in-band" is ehci controller self wakeup, sorry to make you 
misunderstanding.



driver(ClearPortFeature/USB_PORT_FEAT_SUSPEND) write RESUME|LS(k-state) bit
into controller.


Why did it do that?  Did the kernel try to resume the port at the same
time as the device issued a remote wakeup request?  In other words, was
there a race between resume and remote wakeup?



Yes, I mean a race between kernel driver resume and controller remote 
wakeup.



  It makes controller status weird.


Why?  Your log shows that the RESUME bit was already turned on, so
writing a 1 to it shouldn't make any difference.  (And the LS(k-state)
bit is RO, so writing a 1 to it shouldn't matter.)



Here the problem is, after remote wakeup, the controller still is in 
SUSPEND and kernel report disconnect finally. Could kernel write 
"SUSPEND" or "Force Port Resume" bit be related to the problem we meet with?



  It's defined in EHCI
controller spec(Revision 1.0), "If it has enabled remote wake-up, a K-state
on the bus will turn the transceiver clock and generate an interrupt. The
software will then have to wait 20 ms for the resume to complete and the
port to go back to an active state."


Where in the spec did you find that quote?  It's not present in my copy
of the EHCI Rev 1.0 spec.



I am sorry to make a mistake, I quote it from controller reference 
manual. I can find the similar definition in EHCI Rev 1.0,

4.3.1 Port Suspend/Resume.

"When Force Port Resume bit is a one, the host controller sends resume 
signaling down the port. System software times the duration of the 
resume (nominally 20 milliseconds) then sets the Force Port Resume bit 
to a zero."




  In this case Kernel should wait for
the wakeup finished, then judge what should do next step.

We have some thought and give a patch. This patch is to wait for controller
RESUME finished when hub try to clear port SUSPEND feature.





This is definitely wrong.  For one thing, you mustn't have a 20-ms
delay with interrupts disabled.  For another, the spec states (Table
2-16, the entry for bits 11:10) that the Line Status value is valid
only when the port enable bit is 0, so you shouldn't rely on it.
Lastly, there really is no need to do anything, because the remote
wakeup will finish all by itself.



I agree disable irq for maximum 20-ms is not good, but I can find 
another case when ehci_hub_control() deal with GetPortStatus.


I have no idea how controller run, from both EHCI spec and reference 
manual, I can only deduce that it's better kernel driver don't touch 
PORTSC until resume finished. Otherwise how to explain the problem we 
meet with? (After remote wakeup, the controller still is in SUSPEND and 
kernel report disconnect finally.)


When we try the original change in the mail, we never see

Re: About gadget configfs

2014-05-04 Thread Peter Stuge 
Hi Peter,

Peter Chen wrote:
> The step at the board:
> 
> root@freescale ~$ modprobe libcomposite

I guess this step is unneccessary, and that all neccessary modules
are loaded automatically on demand.


> root@freescale ~$ mount none /sys/kernel/config/ -t configfs
> root@freescale ~$ mkdir /sys/kernel/config/usb_gadget/g1
> root@freescale ~$ cd /sys/kernel/config/usb_gadget/g1/
> root@freescale /sys/kernel/config/usb_gadget/g1$ echo 0x15a2 > idVendor
> root@freescale /sys/kernel/config/usb_gadget/g1$ echo 0x0054 > idProduct 
> root@freescale /sys/kernel/config/usb_gadget/g1$ mkdir strings/0x409
> root@freescale /sys/kernel/config/usb_gadget/g1$ echo 123456ABCDEF > 
> strings/0x409/serialnumber
> root@freescale /sys/kernel/config/usb_gadget/g1$ echo Freescale > 
> strings/0x409/manufacturer
> root@freescale /sys/kernel/config/usb_gadget/g1$ echo "FSL i.mx6q sabreSD 
> Board" > strings/0x409/product

I guess you also did a "mkdir configs/c.1" step here?


> root@freescale /sys/kernel/config/usb_gadget/g1$ echo 5 > 
> configs/c.1/MaxPower 
> root@freescale /sys/kernel/config/usb_gadget/g1$ mkdir 
> functions/mass_storage.1
>   Number of LUNs=8
>   Mass Storage Function, version: 2009/09/11
>   LUN: removable file: (no medium)
> root@freescale /sys/kernel/config/usb_gadget/g1$ echo "/dev/mmcblk0p1" > 
> functions/mass_storage.1/lun.0/file 
> 
> root@freescale /sys/kernel/config/usb_gadget/g1$ mkdir functions/gser.1
> root@freescale /sys/kernel/config/usb_gadget/g1$ cat 
> functions/gser.1/port_num 
>   0

So far so good! You've created two functions in the gadget, following
gadget_configfs.txt up to and including section 3.

Section 4. comes next, which wasn't included in your list of commands.
"Associating the functions with their configurations"

ln -s functions/. configs/.

I assume that this results in having only a single configuration with
two interfaces.


> - Why mass storage has been chosen at PC, but not gserial?

Probably because the host (PC) doesn't have a driver for gserial with
your chosen vid+pid.


> - Is it possible both two configurations can be seen at PC?
> If possible, how to do?

Both configurations *are* seen by the host - but only one
configuration of a USB device can be selected at any one time.

If you want both functions available simultaneously then they must be
two different interfaces within a single configuration. I believe the
symlink described in gadget_configfs.txt section 4. accomplishes that.


> - How to choose gserial? I tried to remove the configuration
> of mass storage, but both of configurations have been removed

I guess that you will need to add your vid+pid to the host driver.


> root@freescale /sys/kernel/config/usb_gadget/g1$ rm -rf 
> configs/c.2/mass_storage.1/

Where does configs/c.2 come from? It wasn't mentioned before in your steps?


Best regards

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

About gadget configfs

2014-05-04 Thread Peter Chen 
Hi Sebastian & Andrzej,

I have tried configfs today, and have some puzzled about its
behaviour, hope I can get answers from your both, thanks.

I am running the latest usb-next tree (3.15-rc3), and build
configfs as module, and enabled mass storage and serial, I follow
the instruction of ocumentation/usb/gadget_configfs.txt

The step at the board:

root@freescale ~$ modprobe libcomposite
root@freescale ~$ mount none /sys/kernel/config/ -t configfs
root@freescale ~$ mkdir /sys/kernel/config/usb_gadget/g1
root@freescale ~$ cd /sys/kernel/config/usb_gadget/g1/
root@freescale /sys/kernel/config/usb_gadget/g1$ echo 0x15a2 > idVendor
root@freescale /sys/kernel/config/usb_gadget/g1$ echo 0x0054 > idProduct 
root@freescale /sys/kernel/config/usb_gadget/g1$ mkdir strings/0x409
root@freescale /sys/kernel/config/usb_gadget/g1$ echo 123456ABCDEF >
strings/0x4
09/serialnumber
root@freescale /sys/kernel/config/usb_gadget/g1$ echo Freescale >
strings/0x409/
manufacturer
root@freescale /sys/kernel/config/usb_gadget/g1$ echo "FSL i.mx6q
sabreSD Board"
 > strings/0x409/product

root@freescale /sys/kernel/config/usb_gadget/g1$ echo 5 >
configs/c.1/MaxPower 
root@freescale /sys/kernel/config/usb_gadget/g1$ mkdir
functions/mass_storage.1
Number of LUNs=8
Mass Storage Function, version: 2009/09/11
LUN: removable file: (no medium)
root@freescale /sys/kernel/config/usb_gadget/g1$ echo
"/dev/mmcblk0p1" > functio
ns/mass_storage.1/lun.0/file 

root@freescale /sys/kernel/config/usb_gadget/g1$ mkdir
functions/gser.1
root@freescale /sys/kernel/config/usb_gadget/g1$ cat
functions/gser.1/port_num 
0

root@freescale /sys/kernel/config/usb_gadget/g1$ lsmod
Module  Size  Used by
usb_f_serial2974  2 
u_serial   10032  1 usb_f_serial
usb_f_mass_storage 38373  2 
libcomposite   37503 10 usb_f_serial,usb_f_mass_storage

root@freescale /sys/kernel/config/usb_gadget/g1$ ls /sys/class/udc/
ci_hdrc.0
root@freescale /sys/kernel/config/usb_gadget/g1$ echo "ci_hdrc.0" > UDC
root@freescale /sys/kernel/config/usb_gadget/g1$ configfs-gadget gadget:
high-speed config #2: c

At Linux PC:

b29397@nchen-desktop:~$ lsusb -d 15a2:0054 -v

Bus 001 Device 064: ID 15a2:0054 Freescale Semiconductor, Inc. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   0.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x15a2 Freescale Semiconductor, Inc.
  idProduct  0x0054 
  bcdDevice3.15
  iManufacturer   1 Freescale
  iProduct2 FSL i.mx6q sabreSD Board
  iSerial 3 123456ABCDEF
  bNumConfigurations  2
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   32
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower6mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   32
bNumInterfaces  1
bConfigurationValue 2
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower2mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 8 Mass Storage
  bInterfaceSubClass  6 SCSI
  bInterfaceProtocol 80 Bulk (Zip)
  iInterface  5 Mass Storage
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP

[PATCH] usb: musb: tusb: remove dead code

2014-05-04 Thread Paul Bolle 
musb_in_tusb() is always set to 0, because CONFIG_USB_TUSB6010 is never
set (it should have been CONFIG_USB_MUSB_TUSB6010). But musb_in_tusb()
is unused anyway, so remove a few lines of dead code.

Signed-off-by: Paul Bolle 
---
Usb, musb, and tusb! Is somebody sneaking nursery rhymes in the kernel
tree? Anyhow, this patch is tested with git grep only.

 drivers/usb/musb/tusb6010.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/usb/musb/tusb6010.h b/drivers/usb/musb/tusb6010.h
index 35c933a5d991..1864e24ac965 100644
--- a/drivers/usb/musb/tusb6010.h
+++ b/drivers/usb/musb/tusb6010.h
@@ -14,12 +14,6 @@
 
 extern u8 tusb_get_revision(struct musb *musb);
 
-#ifdef CONFIG_USB_TUSB6010
-#define musb_in_tusb() 1
-#else
-#define musb_in_tusb() 0
-#endif
-
 #ifdef CONFIG_USB_TUSB_OMAP_DMA
 #define tusb_dma_omap()1
 #else
-- 
1.9.0

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

Re: [PATCH v3 5/5] usb: qcserial: remove interface number matching

2014-05-04 Thread Johan Hovold 
On Sun, Apr 27, 2014 at 04:47:46PM +0200, Bjørn Mork wrote:
> From: Bjørn Mork 
> 
> Matching on interface numbers was not such a good idea
> for multi-function serial devices after all. It is much
> better do create well defined device layouts, allowing
> a single match entry per device.
> 
> Remove this now unused code.
> 
> Signed-off-by: Bjørn Mork 

Signed-off-by: Johan Hovold 

> ---
>  drivers/usb/serial/qcserial.c | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
> index 91e7bb515398..ca7b43092439 100644
> --- a/drivers/usb/serial/qcserial.c
> +++ b/drivers/usb/serial/qcserial.c
> @@ -190,13 +190,6 @@ static int qcprobe(struct usb_serial *serial, const 
> struct usb_device_id *id)
>  
>   }
>  
> - /* allow any number of interfaces when doing direct interface match */
> - if (id->match_flags & USB_DEVICE_ID_MATCH_INT_NUMBER) {
> - dev_dbg(dev, "Generic Qualcomm serial interface found\n");
> - altsetting = 0;
> - goto done;
> - }
> -
>   /* default to enabling interface */
>   altsetting = 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/5] usb: qcserial: define and use Sierra Wireless layout

2014-05-04 Thread Johan Hovold 
On Sun, Apr 27, 2014 at 04:47:45PM +0200, Bjørn Mork wrote:
> From: Bjørn Mork 
> 
> All the "non Gobi" Qualcomm based devices handled by this
> driver share a common standard Sierra Wireless specific
> layout. Adding code specifically for this layout allow
> us to reduce the number of match entries per device from
> three to one.
> 
> This change will result in a penalty wrt stable backports,
> but simplifies new Sierra device addtitions in the long
> term.
> 
> Signed-off-by: Bjørn Mork 

Signed-off-by: Johan Hovold 

> ---
>  drivers/usb/serial/qcserial.c | 98 
> +++
>  1 file changed, 53 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
> index 217e29ccde52..91e7bb515398 100644
> --- a/drivers/usb/serial/qcserial.c
> +++ b/drivers/usb/serial/qcserial.c
> @@ -26,10 +26,13 @@
>  enum qcserial_layouts {
>   QCSERIAL_G2K = 0,   /* Gobi 2000 */
>   QCSERIAL_G1K = 1,   /* Gobi 1000 */
> + QCSERIAL_SWI = 2,   /* Sierra Wireless */
>  };
>  
>  #define DEVICE_G1K(v, p) \
>   USB_DEVICE(v, p), .driver_info = QCSERIAL_G1K
> +#define DEVICE_SWI(v, p) \
> + USB_DEVICE(v, p), .driver_info = QCSERIAL_SWI
>  
>  static const struct usb_device_id id_table[] = {
>   /* Gobi 1000 devices */
> @@ -132,46 +135,20 @@ static const struct usb_device_id id_table[] = {
>   {USB_DEVICE(0x12D1, 0x14F1)},   /* Sony Gobi 3000 Composite */
>   {USB_DEVICE(0x0AF0, 0x8120)},   /* Option GTM681W */
>  
> - /* non Gobi Qualcomm serial devices */
> - {USB_DEVICE_INTERFACE_NUMBER(0x0f3d, 0x68a2, 0)},   /* Sierra 
> Wireless MC7700 Device Management */
> - {USB_DEVICE_INTERFACE_NUMBER(0x0f3d, 0x68a2, 2)},   /* Sierra 
> Wireless MC7700 NMEA */
> - {USB_DEVICE_INTERFACE_NUMBER(0x0f3d, 0x68a2, 3)},   /* Sierra 
> Wireless MC7700 Modem */
> - {USB_DEVICE_INTERFACE_NUMBER(0x114f, 0x68a2, 0)},   /* Sierra 
> Wireless MC7750 Device Management */
> - {USB_DEVICE_INTERFACE_NUMBER(0x114f, 0x68a2, 2)},   /* Sierra 
> Wireless MC7750 NMEA */
> - {USB_DEVICE_INTERFACE_NUMBER(0x114f, 0x68a2, 3)},   /* Sierra 
> Wireless MC7750 Modem */
> - {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68a2, 0)},   /* Sierra 
> Wireless MC7710 Device Management */
> - {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68a2, 2)},   /* Sierra 
> Wireless MC7710 NMEA */
> - {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68a2, 3)},   /* Sierra 
> Wireless MC7710 Modem */
> - {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68c0, 0)},   /* Sierra 
> Wireless MC73xx Device Management */
> - {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68c0, 2)},   /* Sierra 
> Wireless MC73xx NMEA */
> - {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68c0, 3)},   /* Sierra 
> Wireless MC73xx Modem */
> - {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901c, 0)},   /* Sierra 
> Wireless EM7700 Device Management */
> - {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901c, 2)},   /* Sierra 
> Wireless EM7700 NMEA */
> - {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901c, 3)},   /* Sierra 
> Wireless EM7700 Modem */
> - {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901f, 0)},   /* Sierra 
> Wireless EM7355 Device Management */
> - {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901f, 2)},   /* Sierra 
> Wireless EM7355 NMEA */
> - {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901f, 3)},   /* Sierra 
> Wireless EM7355 Modem */
> - {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9041, 0)},   /* Sierra 
> Wireless MC7305/MC7355 Device Management */
> - {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9041, 2)},   /* Sierra 
> Wireless MC7305/MC7355 NMEA */
> - {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9041, 3)},   /* Sierra 
> Wireless MC7305/MC7355 Modem */
> - {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 0)},   /* Netgear 
> AirCard 340U Device Management */
> - {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 2)},   /* Netgear 
> AirCard 340U NMEA */
> - {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 3)},   /* Netgear 
> AirCard 340U Modem */
> - {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a2, 0)},   /* Dell 
> Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card Device Management */
> - {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a2, 2)},   /* Dell 
> Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card NMEA */
> - {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a2, 3)},   /* Dell 
> Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card Modem */
> - {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a3, 0)},   /* Dell 
> Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card Device Management */
> - {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a3, 2)},   /* Dell 
> Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card NMEA */
> - {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a3, 3)},   /* Dell 
> Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card Modem */
> - {USB_DEVICE_INTE

Re: [PATCH v3 3/5] usb: qcserial: refactor device layout selection

2014-05-04 Thread Johan Hovold 
On Sun, Apr 27, 2014 at 04:47:44PM +0200, Bjørn Mork wrote:
> From: Bjørn Mork 
> 
> Preparing for more supported standard device layouts. Keeping
> the matching macros unchanged to avoid breaking stable
> backporting of new device additions.
> 
> Signed-off-by: Bjørn Mork 

Signed-off-by: Johan Hovold 

> ---
>  drivers/usb/serial/qcserial.c | 22 --
>  1 file changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
> index e282155dd4a1..217e29ccde52 100644
> --- a/drivers/usb/serial/qcserial.c
> +++ b/drivers/usb/serial/qcserial.c
> @@ -22,8 +22,14 @@
>  #define DRIVER_AUTHOR "Qualcomm Inc"
>  #define DRIVER_DESC "Qualcomm USB Serial driver"
>  
> +/* standard device layouts supported by this driver */
> +enum qcserial_layouts {
> + QCSERIAL_G2K = 0,   /* Gobi 2000 */
> + QCSERIAL_G1K = 1,   /* Gobi 1000 */
> +};
> +
>  #define DEVICE_G1K(v, p) \
> - USB_DEVICE(v, p), .driver_info = 1
> + USB_DEVICE(v, p), .driver_info = QCSERIAL_G1K
>  
>  static const struct usb_device_id id_table[] = {
>   /* Gobi 1000 devices */
> @@ -178,11 +184,8 @@ static int qcprobe(struct usb_serial *serial, const 
> struct usb_device_id *id)
>   int retval = -ENODEV;
>   __u8 nintf;
>   __u8 ifnum;
> - bool is_gobi1k = id->driver_info ? true : false;
>   int altsetting = -1;
>  
> - dev_dbg(dev, "Is Gobi 1000 = %d\n", is_gobi1k);
> -
>   nintf = serial->dev->actconfig->desc.bNumInterfaces;
>   dev_dbg(dev, "Num Interfaces = %d\n", nintf);
>   ifnum = intf->desc.bInterfaceNumber;
> @@ -230,7 +233,8 @@ static int qcprobe(struct usb_serial *serial, const 
> struct usb_device_id *id)
>* gets handled by other drivers.
>*/
>  
> - if (is_gobi1k) {
> + switch (id->driver_info) {
> + case QCSERIAL_G1K:
>   /*
>* Gobi 1K USB layout:
>* 0: DM/DIAG (use libqcdm from ModemManager for communication)
> @@ -245,7 +249,8 @@ static int qcprobe(struct usb_serial *serial, const 
> struct usb_device_id *id)
>   dev_dbg(dev, "Modem port found\n");
>   else
>   altsetting = -1;
> - } else {
> + break;
> + case QCSERIAL_G2K:
>   /*
>* Gobi 2K+ USB layout:
>* 0: QMI/net
> @@ -273,6 +278,11 @@ static int qcprobe(struct usb_serial *serial, const 
> struct usb_device_id *id)
>   dev_dbg(dev, "Gobi 2K+ NMEA GPS interface found\n");
>   break;
>   }
> + break;
> + default:
> + dev_err(dev, "unsupported device layout type: %lu\n",
> + id->driver_info);
> + break;
>   }
>  
>  done:
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/5] usb: qcserial: fix multiline comment coding style

2014-05-04 Thread Johan Hovold 
On Sun, Apr 27, 2014 at 04:47:43PM +0200, Bjørn Mork wrote:
> From: Bjørn Mork 
> 
> Use a consistent style for all multiline comments.
> 
> Signed-off-by: Bjørn Mork 

Signed-off-by: Johan Hovold 

> ---
>  drivers/usb/serial/qcserial.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
> index 6c0a542e8ec1..e282155dd4a1 100644
> --- a/drivers/usb/serial/qcserial.c
> +++ b/drivers/usb/serial/qcserial.c
> @@ -225,12 +225,14 @@ static int qcprobe(struct usb_serial *serial, const 
> struct usb_device_id *id)
>   /* default to enabling interface */
>   altsetting = 0;
>  
> - /* Composite mode; don't bind to the QMI/net interface as that
> + /*
> +  * Composite mode; don't bind to the QMI/net interface as that
>* gets handled by other drivers.
>*/
>  
>   if (is_gobi1k) {
> - /* Gobi 1K USB layout:
> + /*
> +  * Gobi 1K USB layout:
>* 0: DM/DIAG (use libqcdm from ModemManager for communication)
>* 1: serial port (doesn't respond)
>* 2: AT-capable modem port
> @@ -244,7 +246,8 @@ static int qcprobe(struct usb_serial *serial, const 
> struct usb_device_id *id)
>   else
>   altsetting = -1;
>   } else {
> - /* Gobi 2K+ USB layout:
> + /*
> +  * Gobi 2K+ USB layout:
>* 0: QMI/net
>* 1: DM/DIAG (use libqcdm from ModemManager for communication)
>* 2: AT-capable modem port
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/5] usb: qcserial: add a number of Dell devices

2014-05-04 Thread Johan Hovold 
On Sun, Apr 27, 2014 at 04:47:42PM +0200, Bjørn Mork wrote:
> From: Bjørn Mork 
> 
> Dan writes:
> 
> "The Dell drivers use the same configuration for PIDs:
> 
> 81A2: Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card
> 81A3: Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card
> 81A4: Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card
> 81A8: Dell Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card
> 81A9: Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card
> 
> These devices are all clearly Sierra devices, but are also definitely
> Gobi-based.  The A8 might be the MC7700/7710 and A9 is likely a MC7750.
> 
> From DellGobi5kSetup.exe from the Dell drivers:
> 
> usbif0: serial/firmware loader?
> usbif2: nmea
> usbif3: modem/ppp
> usbif8: net/QMI"
> 
> Cc: 
> Reported-by: AceLan Kao 
> Reported-by: Dan Williams 
> Signed-off-by: Bjørn Mork 

Signed-off-by: Johan Hovold 

Greg, this is series is for usb-next, but this first patch could go into
v3.15-final if you prefer.

Thanks,
Johan

> ---
>  drivers/usb/serial/qcserial.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
> index 7ed681a714a5..6c0a542e8ec1 100644
> --- a/drivers/usb/serial/qcserial.c
> +++ b/drivers/usb/serial/qcserial.c
> @@ -151,6 +151,21 @@ static const struct usb_device_id id_table[] = {
>   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 0)},   /* Netgear 
> AirCard 340U Device Management */
>   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 2)},   /* Netgear 
> AirCard 340U NMEA */
>   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 3)},   /* Netgear 
> AirCard 340U Modem */
> + {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a2, 0)},   /* Dell 
> Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card Device Management */
> + {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a2, 2)},   /* Dell 
> Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card NMEA */
> + {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a2, 3)},   /* Dell 
> Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card Modem */
> + {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a3, 0)},   /* Dell 
> Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card Device Management */
> + {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a3, 2)},   /* Dell 
> Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card NMEA */
> + {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a3, 3)},   /* Dell 
> Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card Modem */
> + {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a4, 0)},   /* Dell 
> Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card Device Management */
> + {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a4, 2)},   /* Dell 
> Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card NMEA */
> + {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a4, 3)},   /* Dell 
> Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card Modem */
> + {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a8, 0)},   /* Dell 
> Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card Device Management */
> + {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a8, 2)},   /* Dell 
> Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card NMEA */
> + {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a8, 3)},   /* Dell 
> Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card Modem */
> + {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a9, 0)},   /* Dell 
> Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card Device Management */
> + {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a9, 2)},   /* Dell 
> Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card NMEA */
> + {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a9, 3)},   /* Dell 
> Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card Modem */
>  
>   { } /* Terminating entry */
>  };
--
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