usb: gadget: net2280: CONFIG_USB_GADGET_PDEBUG_FILES?

2014-07-04 Thread Paul Bolle
Commit e56e69cc0ff4 ("usb: gadget: net2280: Use pr_* function") is
included in today's linux-next (ie, next-20140704).

It contains this odd chunk:
@@ -1566,7 +1563,7 @@ static const struct usb_gadget_ops net2280_ops = {
 
 
/*-*/
 
-#ifdef CONFIG_USB_GADGET_DEBUG_FILES
+#ifdef CONFIG_USB_GADGET_PDEBUG_FILES
 
 /* FIXME move these into procfs, and use seq_file.
  * Sysfs _still_ doesn't behave for arbitrarily sized files,

(Commit b7ca96655ddd ("usb: gadget: Gadget directory cleanup - group UDC
drivers"), also included in today's linux-next, moved that new check for
CONFIG_USB_GADGET_PDEBUG_FILES to drivers/usb/gadget/udc/net2280.c.)

Using CONFIG_USB_GADGET_PDEBUG_FILES appears to be just an editing
mistake. Would Ricardo like to submit the trivial patch to clean it up
or should I do that?


Paul Bolle

--
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: zerocopy support for usbfs

2014-07-04 Thread Oliver Neukum
On Wed, 2014-07-02 at 17:53 +0200, Stefan Klug wrote:

> @@ -1471,6 +1526,57 @@ static int proc_do_submiturb(struct
> usb_dev_state 
> *ps, struct usbdevfs_urb *uurb
>   }
>   totlen -= u;
>   }
> +} else if(num_pages) {
> +pages = kmalloc(num_pages*sizeof(struct page*), GFP_KERNEL);
> +if(!pages) {
> +ret = -ENOMEM;
> +goto error;
> +}
> +
> +//create the scatterlist
> +as->urb->sg = kmalloc(num_pages * sizeof(struct
> scatterlist), 
> GFP_KERNEL);
> +if (!as->urb->sg) {
> +ret = -ENOMEM;
> +goto error;
> +}
> +
> +ret = get_user_pages_fast((unsigned long)buf_aligned,
> +   num_pages,
> +   is_in,
> +   pages);
> +
> +if(ret < 0) {
> +printk("get_user_pages failed %i\n", ret);
> +goto error;
> +}
> +
> +//did we get all pages?
> +if(ret < num_pages) {
> +printk("get_user_pages didn't deliver all pages %i\n",
> ret);
> +//free the pages and error out
> +for(i=0; i +page_cache_release(pages[i]);
> +}
> +ret = -ENOMEM;
> +goto error;
> +}
> +
> +as->is_user_mem = 1;
> +as->urb->num_sgs = num_pages;
> +sg_init_table(as->urb->sg, as->urb->num_sgs);
> +
> +totlen = uurb->buffer_length + buf_offset;
> +o = buf_offset;
> +for (i = 0; i < as->urb->num_sgs; i++) {
> +u = (totlen > PAGE_SIZE) ? PAGE_SIZE : totlen;
> +u-= o;
> +sg_set_page(&as->urb->sg[i], pages[i], u, o);
> +totlen -= u + o;
> +o = 0;
> +}
> +
> +kfree(pages);
> +pages = NULL;
>   } else if (uurb->buffer_length > 0) {
>   as->urb->transfer_buffer = kmalloc(uurb->buffer_length,
>   GFP_KERNEL)


One more thing: Where do you check that the memory the user has passed
a pointer to is actually writable? It seems to me that for zerocopy you
must do the check before you submit the URB to the HCD.

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 v2 0/4] Tegra USB probe order issue fix

2014-07-04 Thread Mark Rutland
On Fri, Jul 04, 2014 at 02:09:35AM +0100, Tuomas Tynkkynen wrote:
> Hi all,
> 
> Here's a second version of the probe order issue series. This time I've
> added the USB1 resets to the PHYs, thus replacing the really ugly parts
> with something slightly better. Old device trees will still probe
> successfully, but instead of this bugfix they'll get a dev_warn().

Given the binding looks sane and doesn't unnecessarily break existing
DTBs, for patches 1-3:

Acked-by: Mark Rutland 

Thanks,
Mark.
--
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: net2280: Fix typo on #ifdef

2014-07-04 Thread Ricardo Ribalda Delgado
Commit e56e69cc0ff4 ("usb: gadget: net2280: Use pr_* function")
includes a editing mistake on one of the #ifdef.

This patch fixes it.

Reported-by: Paul Bolle 
Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/usb/gadget/udc/net2280.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
index ce8bc86..248dccb 100644
--- a/drivers/usb/gadget/udc/net2280.c
+++ b/drivers/usb/gadget/udc/net2280.c
@@ -1562,7 +1562,7 @@ static const struct usb_gadget_ops net2280_ops = {
 
 /*-*/
 
-#ifdef CONFIG_USB_GADGET_PDEBUG_FILES
+#ifdef CONFIG_USB_GADGET_DEBUG_FILES
 
 /* FIXME move these into procfs, and use seq_file.
  * Sysfs _still_ doesn't behave for arbitrarily sized files,
-- 
2.0.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: usb: gadget: net2280: CONFIG_USB_GADGET_PDEBUG_FILES?

2014-07-04 Thread Ricardo Ribalda Delgado
My fault. Thank you very much for reporting it. I have just posted the patch


Regards

On Fri, Jul 4, 2014 at 9:37 AM, Paul Bolle  wrote:
> Commit e56e69cc0ff4 ("usb: gadget: net2280: Use pr_* function") is
> included in today's linux-next (ie, next-20140704).
>
> It contains this odd chunk:
> @@ -1566,7 +1563,7 @@ static const struct usb_gadget_ops net2280_ops = {
>
>  
> /*-*/
>
> -#ifdef CONFIG_USB_GADGET_DEBUG_FILES
> +#ifdef CONFIG_USB_GADGET_PDEBUG_FILES
>
>  /* FIXME move these into procfs, and use seq_file.
>   * Sysfs _still_ doesn't behave for arbitrarily sized files,
>
> (Commit b7ca96655ddd ("usb: gadget: Gadget directory cleanup - group UDC
> drivers"), also included in today's linux-next, moved that new check for
> CONFIG_USB_GADGET_PDEBUG_FILES to drivers/usb/gadget/udc/net2280.c.)
>
> Using CONFIG_USB_GADGET_PDEBUG_FILES appears to be just an editing
> mistake. Would Ricardo like to submit the trivial patch to clean it up
> or should I do that?
>
>
> Paul Bolle
>



-- 
Ricardo Ribalda
--
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: Chipidea gadget unplug/disconnect event

2014-07-04 Thread Michael Grzeschik
On Fri, Jul 04, 2014 at 01:39:08AM +, Peter Chen wrote:
>  
> > > >
> > >
> > > Yes, it has already implemented at ci_usc_vbus_session.
> > >
> > > > I see the code path in ci_udc_vbus_session of udc.c to trigger such
> > > > an event, but unfortunately it was never possible to run into that
> > code.
> > > >
> > > > The function ci_otg_work in otg.c is prepared to do that in case the
> > > > irq got triggered by OTGSC_BSVIS bit change.
> > > >
> > > > This is true for plugging, but never happened to be called on
> > unplugging.
> > > > Is there anything missing to get this working? Or is this completely
> > > > impossible by the core? I was already fiddling around with the other
> > > > irq cases OTGSC_*IE, but never got anything useful.
> > >
> > > Once the vbus lower than B_SESSION_VALID, it will trigger (set
> > > OTGSC_BSVIS too) BSV interrupt.
> > 
> > By theory! ;)
> > 
> > > Check your vbus after unplugging please.
> > 
> > Today I measured the voltage level on vbus and it still had ~2.6V while
> > being not connected to anything.
> > 
> > > > I am working on the imx25 otg capable SoC.
> > 
> > I validated this with two different imx25 boards and realized, that we
> > have this external vbus divider errata for that SoC.
> > 
> > Errata: ENGcm09152
> > 
> > Its likely that the issue is related to this problem as the vbus was not
> > connected to anything different, than the SoC in that case.
> > 
>  
> Check the voltage at both cpu side (otgsc get value from it) and connector.
> check if you have a big cap at vbus.

> check if set otgsc.vd makes things different

This bit changes a lot! :) With that bit set, it works as
expected. The odd thing is that, without having an gadget
loaded (not having RUN/STOP bit set in USBCMD) it was working
already as expected. After starting the controller with setting
RUN/STOP bit in USBCMD no plug/unplug irqs occurred anymore.

Thanks for the help,
Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 6/6] ARM: dts: dra7-evm: Add regulator information to USB2 PHYs

2014-07-04 Thread Roger Quadros
The ldousb_reg regulator provides power to the USB1 and USB2
High Speed PHYs.

Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/dra7-evm.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 8308954..50f8022 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -496,3 +496,11 @@
};
};
 };
+
+&usb2_phy1 {
+   phy-supply = <&ldousb_reg>;
+};
+
+&usb2_phy2 {
+   phy-supply = <&ldousb_reg>;
+};
-- 
1.8.3.2

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


[PATCH v2 5/6] phy: omap-usb2: Balance pm_runtime_enable() on probe failure and remove

2014-07-04 Thread Roger Quadros
If probe fails then we need to call pm_runtime_disable() to balance
out the previous pm_runtime_enable() call. Else it will cause
unbalanced pm_runtime_enable() call in the succeding probe call.

This anomaly was observed when the call to devm_phy_create() failed
with -EPROBE_DEFER.

Balance out the pm_runtime_enable() call in .remove() as well.

Signed-off-by: Roger Quadros 
---
 drivers/phy/phy-omap-usb2.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 7007c11..3a1d00e 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -262,7 +262,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
otg->phy= &phy->phy;
 
platform_set_drvdata(pdev, phy);
-   pm_runtime_enable(phy->dev);
 
generic_phy = devm_phy_create(phy->dev, &ops, NULL);
if (IS_ERR(generic_phy))
@@ -270,10 +269,13 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
phy_set_drvdata(generic_phy, phy);
 
+   pm_runtime_enable(phy->dev);
phy_provider = devm_of_phy_provider_register(phy->dev,
of_phy_simple_xlate);
-   if (IS_ERR(phy_provider))
+   if (IS_ERR(phy_provider)) {
+   pm_runtime_disable(phy->dev);
return PTR_ERR(phy_provider);
+   }
 
phy->wkupclk = devm_clk_get(phy->dev, "wkupclk");
if (IS_ERR(phy->wkupclk)) {
@@ -317,6 +319,7 @@ static int omap_usb2_remove(struct platform_device *pdev)
if (!IS_ERR(phy->optclk))
clk_unprepare(phy->optclk);
usb_remove_phy(&phy->phy);
+   pm_runtime_disable(phy->dev);
 
return 0;
 }
-- 
1.8.3.2

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


[PATCH v2 4/6] phy: core: Add phy-supply to DT binding documentation

2014-07-04 Thread Roger Quadros
phy-supply is a phandle to the regulator that provides power to the
PHY. This regulator is managed during the PHY power on/off sequence
by the phy core driver.

Signed-off-by: Roger Quadros 
---
 Documentation/devicetree/bindings/phy/phy-bindings.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt 
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
index 8ae844f..2aa1840 100644
--- a/Documentation/devicetree/bindings/phy/phy-bindings.txt
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -10,6 +10,10 @@ Required Properties:
provider can use the values in cells to find the appropriate
PHY.
 
+Optional Properties:
+phy-supply:Phandle to a regulator that provides power to the PHY. This
+   regulator will be managed during the PHY power on/off sequence.
+
 For example:
 
 phys: phy {
-- 
1.8.3.2

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


[PATCH v2 3/6] phy: core: Support regulator supply for PHY power

2014-07-04 Thread Roger Quadros
Some PHYs can be powered by an external power regulator.
e.g. USB_HS PHY on DRA7 SoC. Make the PHY core support a
power regulator.

Signed-off-by: Roger Quadros 
---
 drivers/phy/phy-core.c  | 26 ++
 include/linux/phy/phy.h |  2 ++
 2 files changed, 28 insertions(+)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 49c4465..75c9739 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static struct class *phy_class;
 static DEFINE_MUTEX(phy_provider_mutex);
@@ -226,6 +227,12 @@ int phy_power_on(struct phy *phy)
if (!phy)
return 0;
 
+   if (phy->pwr) {
+   ret = regulator_enable(phy->pwr);
+   if (ret)
+   return ret;
+   }
+
ret = phy_pm_runtime_get_sync(phy);
if (ret < 0 && ret != -ENOTSUPP)
return ret;
@@ -247,6 +254,8 @@ int phy_power_on(struct phy *phy)
 out:
mutex_unlock(&phy->mutex);
phy_pm_runtime_put_sync(phy);
+   if (phy->pwr)
+   regulator_disable(phy->pwr);
 
return ret;
 }
@@ -272,6 +281,9 @@ int phy_power_off(struct phy *phy)
mutex_unlock(&phy->mutex);
phy_pm_runtime_put(phy);
 
+   if (phy->pwr)
+   regulator_disable(phy->pwr);
+
return 0;
 }
 EXPORT_SYMBOL_GPL(phy_power_off);
@@ -588,6 +600,16 @@ struct phy *phy_create(struct device *dev, const struct 
phy_ops *ops,
goto free_phy;
}
 
+   /* phy-supply */
+   phy->pwr = regulator_get_optional(dev, "phy");
+   if (IS_ERR(phy->pwr)) {
+   if (PTR_ERR(phy->pwr) == -EPROBE_DEFER) {
+   ret = -EPROBE_DEFER;
+   goto free_ida;
+   }
+   phy->pwr = NULL;
+   }
+
device_initialize(&phy->dev);
mutex_init(&phy->mutex);
 
@@ -617,6 +639,9 @@ put_dev:
put_device(&phy->dev);  /* calls phy_release() which frees resources */
return ERR_PTR(ret);
 
+free_ida:
+   ida_simple_remove(&phy_ida, phy->id);
+
 free_phy:
kfree(phy);
return ERR_PTR(ret);
@@ -800,6 +825,7 @@ static void phy_release(struct device *dev)
 
phy = to_phy(dev);
dev_vdbg(dev, "releasing '%s'\n", dev_name(dev));
+   regulator_put(phy->pwr);
ida_simple_remove(&phy_ida, phy->id);
kfree(phy);
 }
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 2760744..9a86945 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct phy;
 
@@ -65,6 +66,7 @@ struct phy {
int init_count;
int power_count;
struct phy_attrsattrs;
+   struct regulator*pwr;
 };
 
 /**
-- 
1.8.3.2

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


[PATCH v2 2/6] phy: core: Fix error path in phy_create()

2014-07-04 Thread Roger Quadros
Prevent resources from being freed twice in case device_add() call
fails within phy_create(). Also use ida_simple_remove() instead of
ida_remove() as we had used ida_simple_get() to allocate the ida.

Signed-off-by: Roger Quadros 
---
 drivers/phy/phy-core.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index c64a2f3..49c4465 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -614,8 +614,9 @@ struct phy *phy_create(struct device *dev, const struct 
phy_ops *ops,
return phy;
 
 put_dev:
-   put_device(&phy->dev);
-   ida_remove(&phy_ida, phy->id);
+   put_device(&phy->dev);  /* calls phy_release() which frees resources */
+   return ERR_PTR(ret);
+
 free_phy:
kfree(phy);
return ERR_PTR(ret);
@@ -799,7 +800,7 @@ static void phy_release(struct device *dev)
 
phy = to_phy(dev);
dev_vdbg(dev, "releasing '%s'\n", dev_name(dev));
-   ida_remove(&phy_ida, phy->id);
+   ida_simple_remove(&phy_ida, phy->id);
kfree(phy);
 }
 
-- 
1.8.3.2

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


[PATCH v2 1/6] ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on

2014-07-04 Thread Roger Quadros
After clarification from the hardware team it was found that
this 1.8V PHY supply can't be switched OFF when SoC is Active.

Since the PHY IPs don't contain isolation logic built in the design to
allow the power rail to be switched off, there is a very high risk
of IP reliability and additional leakage paths which can result in
additional power consumption.

The only scenario where this rail can be switched off is part of Power on
reset sequencing, but it needs to be kept always-on during operation.

This patch is required for proper functionality of USB, SATA
and PCIe on DRA7-evm.

CC: Rajendra Nayak 
CC: Tero Kristo 
Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/dra7-evm.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 4adc280..8308954 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -240,6 +240,7 @@
regulator-name = "ldo3";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+   regulator-always-on;
regulator-boot-on;
};
 
-- 
1.8.3.2

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


[PATCH v2 0/6] omap: phy: dra7-evm PHY fixes for 3.16

2014-07-04 Thread Roger Quadros
Hi,

On DRA7-evm, the VDDA_1V8_PHY supply must be always-on for proper functioning
of the PHYs on the SoC.

The 3.3V USB supply (ldousb_reg) can be turned OFF when the High Speed USB PHYs
are not in use. We add regulator support in the PHY framework core to manage
the PHY's regulator during PHY power on/off.

Finally we add the 3.3V regulator information to the USB2 PHYs.

This series should get the USB and SATA working again on 3.16 on DRA7-evm.

cheers,
-roger

Changelog:

v2:
- removed if (!NULL) check around regulator_put()
- added more technical information in commit message about 1V8_PHY power line
- added pm_runtime_disable in omap_usb2_remove()

---
Roger Quadros (6):
  ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on
  phy: core: Fix error path in phy_create()
  phy: core: Support regulator supply for PHY power
  phy: core: Add phy-supply to DT binding documentation
  phy: omap-usb2: Balance pm_runtime_enable() on probe failure and
remove
  ARM: dts: dra7-evm: Add regulator information to USB2 PHYs

 .../devicetree/bindings/phy/phy-bindings.txt   |  4 +++
 arch/arm/boot/dts/dra7-evm.dts |  9 ++
 drivers/phy/phy-core.c | 33 --
 drivers/phy/phy-omap-usb2.c|  7 +++--
 include/linux/phy/phy.h|  2 ++
 5 files changed, 50 insertions(+), 5 deletions(-)

-- 
1.8.3.2

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


[PATCH 7/7] fsl/otg: Resolve OTG crash issue with another host

2014-07-04 Thread Ramneek Mehresh
Resolves kernel crash issue when a USB flash drive is inserted
into USB1 port with USB2 port configured as otg. Removing
"else" block so that the controller coming up in "non-otg" mode
doesn't return -ENODEV. Returning "ENODEV" results in platform
framework unbinding platform-drv from controller resulting in
kernel crash later in hub driver

Signed-off-by: Ramneek Mehresh 
---
 drivers/usb/host/ehci-fsl.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 121f0c8..18339f8 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -206,9 +206,6 @@ static int usb_hcd_fsl_probe(const struct hc_driver *driver,
}
 
ehci_fsl->have_hcd = 1;
-   } else {
-   dev_err(&pdev->dev, "wrong operating mode\n");
-   return -ENODEV;
}
 #endif
return retval;
-- 
1.8.3.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] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture

2014-07-04 Thread Peter Griffin
Signed-off-by: Peter Griffin 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 702ca10..269ad3b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1325,6 +1325,7 @@ F:drivers/pinctrl/pinctrl-st.c
 F: drivers/media/rc/st_rc.c
 F: drivers/i2c/busses/i2c-st.c
 F: drivers/tty/serial/st-asc.c
+F: drivers/usb/dwc3/dwc3-st.c
 
 ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT
 M: Lennert Buytenhek 
-- 
1.9.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] ARM: dts: sti: Add st-dwc3 devicetree bindings documentation

2014-07-04 Thread Peter Griffin
This patch documents the device tree documentation required for
the ST usb3 controller glue layer found in STiH407 devices.

Signed-off-by: Giuseppe Cavallaro 
Signed-off-by: Peter Griffin 
---
 Documentation/devicetree/bindings/usb/dwc3-st.txt | 58 +++
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt

diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt 
b/Documentation/devicetree/bindings/usb/dwc3-st.txt
new file mode 100644
index 000..f14e5da
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
@@ -0,0 +1,58 @@
+ST DWC3 glue logic
+
+This file documents the parameters for the dwc3-st driver.
+This driver provides the glue logic to use the dwc3 on STiH407 based platforms.
+
+Required properties:
+ - compatible  : must be "st,stih407-dwc3"
+ - reg : glue logic base address and USB syscfg ctrl register offest
+ - reg-names   : Should be "reg-glue" and "syscfg-reg".
+ - st,syscon: should be phandle to system configuration node which
+ encompases the glue registers.
+ - resets   : phandle pointing to the system powerdown controller
+See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
+See: Documentation/devicetree/bindings/reset/reset.txt
+
+ - #address-cells, #size-cells : should be '1' if the device has sub-nodes
+ with 'reg' property.
+
+ - pinctl-names : A pinctrl state named "default" must be defined.
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt.
+
+ - pinctrl-0   : Pin control group
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt.
+
+ - ranges: allows valid 1:1 translation between child's address space and
+   parent's address space.
+
+Optional properties:
+ - st,dwc3-drd-device: to program the HC as "device" (static setup)
+
+Sub-nodes:
+The dwc3 core should be added as subnode to ST DWC3 glue as shown in the
+example below. The DT binding details of dwc3 can be found in:
+Documentation/devicetree/bindings/usb/dwc3.txt
+
+Example:
+
+st_dwc3: dwc3@8f94000 {
+   status  = "disabled";
+   compatible  = "st,stih407-dwc3";
+   reg = <0x08f94000 0x1000>, <0x110 0x4>;
+   reg-names   = "reg-glue", "syscfg-reg";
+   st,syscfg   = <&syscfg_core>;
+   resets  = <&powerdown STIH407_USB3_POWERDOWN>;
+   #address-cells  = <1>;
+   #size-cells = <1>;
+   pinctrl-names   = "default";
+   pinctrl-0   = <&pinctrl_usb3>;
+   ranges;
+
+   dwc3: dwc3@990 {
+   compatible  = "synopsys,dwc3";
+   reg = <0x0990 0x10>;
+   interrupts  =  ;
+
+   usb-phy = <&usb2_phy>, <&usb3_phy>;
+   };
+};
-- 
1.9.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 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC

2014-07-04 Thread Peter Griffin
This patch adds the ST glue logic to manage the DWC3 HC
on STiH407 SoC family. It manages the powerdown signal,
and configures the internal glue logic and syscfg registers.

Signed-off-by: Giuseppe Cavallaro 
Signed-off-by: Peter Griffin 
---
 drivers/usb/dwc3/Kconfig   |   9 ++
 drivers/usb/dwc3/Makefile  |   1 +
 drivers/usb/dwc3/dwc3-st.c | 325 +
 3 files changed, 335 insertions(+)
 create mode 100644 drivers/usb/dwc3/dwc3-st.c

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 8eb996e..f7b0518 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -77,6 +77,15 @@ config USB_DWC3_KEYSTONE
default USB_DWC3
help
  Support of USB2/3 functionality in TI Keystone2 platforms.
+
+config USB_DWC3_ST
+   tristate "STMicroelectronics Platforms"
+   depends on ARCH_STI && OF
+   default USB_DWC3_HOST
+   help
+ STMicroelectronics SoCs chip with one DesignWare Core USB3 IP
+ inside (i.e. STiH407).
+
  Say 'Y' or 'M' here if you have one such device
 
 comment "Debugging features"
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 10ac3e7..11c9f54 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_USB_DWC3_OMAP)   += dwc3-omap.o
 obj-$(CONFIG_USB_DWC3_EXYNOS)  += dwc3-exynos.o
 obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
 obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
+obj-$(CONFIG_USB_DWC3_ST)  += dwc3-st.o
diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
new file mode 100644
index 000..80b1b8f
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-st.c
@@ -0,0 +1,325 @@
+/**
+ * dwc3-st.c Support for dwc3 platform devices on ST Microelectronics platforms
+ *
+ * This is a small platform driver for the dwc3 to provide the glue logic
+ * to configure the controller. Tested on STi platforms.
+ *
+ * Copyright (C) 2014 Stmicroelectronics
+ *
+ * Author: Giuseppe Cavallaro 
+ * Contributors: Aymen Bouattay 
+ *   Peter Griffin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Inspired by dwc3-omap.c and dwc3-exynos.c.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "io.h"
+
+/* Reg glue registers */
+#define USB2_CLKRST_CTRL 0x00
+#define aux_clk_en(n) ((n)<<0)
+#define sw_pipew_reset_n(n) ((n)<<4)
+#define ext_cfg_reset_n(n) ((n)<<8)
+#define xhci_revision(n) ((n)<<12)
+
+#define USB2_VBUS_MNGMNT_SEL1 0x2C
+/*
+ * 2'b00 : Override value from Reg 0x30 is selected
+ * 2'b01 : utmiotg_vbusvalid from usb3_top top is selected
+ * 2'b10 : pipew_powerpresent from PIPEW instance is selected
+ * 2'b11 : value is 1'b0
+ */
+#define SEL_OVERRIDE_VBUSVALID(n) ((n)<<0)
+#define SEL_OVERRIDE_POWERPRESENT(n) ((n)<<4)
+#define SEL_OVERRIDE_BVALID(n) ((n)<<8)
+
+#define USB2_VBUS_MNGMNT_VAL1 0x30
+#define OVERRIDE_VBUSVALID_VAL (1 << 0)
+#define OVERRIDE_POWERPRESENT_VAL (1 << 4)
+#define OVERRIDE_BVALID_VAL (1 << 8)
+
+/* Static DRD configuration */
+#define USB_HOST_DEFAULT_MASK  0xffe
+#define USB_SET_PORT_DEVICE0x1
+
+struct st_dwc3 {
+   struct platform_device *dwc3;   /* platform device pointer */
+   struct device *dev; /* device pointer */
+   void __iomem *glue_base;/* ioaddr for programming the glue */
+   struct regmap *regmap;  /* regmap for getting syscfg */
+   int syscfg_reg_off; /* usb syscfg control offset */
+   bool drd_device_conf;   /* DRD static host/device conf */
+   struct reset_control *rstc_pwrdn;/* Rst control for powerdown*/
+};
+
+static inline u32 st_dwc3_readl(void __iomem *base, u32 offset)
+{
+   return readl_relaxed(base + offset);
+}
+
+static inline void st_dwc3_writel(void __iomem *base, u32 offset, u32 value)
+{
+   writel_relaxed(value, base + offset);
+}
+
+/**
+ * st_dwc3_drd_init: program the port
+ * @dwc3_data: driver private structure
+ * Description: this function is to program the port as either host or device
+ * according to the static configuration passed from devicetree.
+ * OTG and dual role are not yet supported!
+ */
+static int st_dwc3_drd_init(struct st_dwc3 *dwc3_data)
+{
+   u32 val;
+
+   regmap_read(dwc3_data->regmap, dwc3_data->syscfg_reg_off, &val);
+
+   if (dwc3_data->drd_device_conf)
+   val |= USB_SET_PORT_DEVICE;
+   else
+   val &= USB_HOST_DEFAULT_MASK;
+
+   return regmap_write(dwc3_data->regmap, dwc3_data->syscfg_reg_off, val);
+}
+
+/**
+ * st_dwc3_init: init the controller via glue logic
+ * @dwc3_data: driver private structur

[PATCH 0/3] Add ST dwc3 glue layer driver.

2014-07-04 Thread Peter Griffin
This series adds support for the ST glue logic to manage the DWC3 HC
on STiH407 SoC family chipsets.

Peter Griffin (3):
  usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
  ARM: dts: sti: Add st-dwc3 devicetree bindings documentation
  MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture

 Documentation/devicetree/bindings/usb/dwc3-st.txt |  58 
 MAINTAINERS   |   1 +
 drivers/usb/dwc3/Kconfig  |   9 +
 drivers/usb/dwc3/Makefile |   1 +
 drivers/usb/dwc3/dwc3-st.c| 325 ++
 5 files changed, 394 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt
 create mode 100644 drivers/usb/dwc3/dwc3-st.c

-- 
1.9.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: how to firing device event when SD card inserting usb card reader

2014-07-04 Thread loody
hi Alan:

2014-06-26 23:57 GMT+08:00 Alan Stern :
> On Thu, 26 Jun 2014, loody wrote:
>
>> hi all:
>> I try below flow:
>> 1. plug in usb card reader
>> 2. wait 2 seconds
>> 3. plug in SD card
>>
>> on ubuntu PC system, the udev can get SD plug in event
>> but on my embedded system, there is no udev plug event when SD plug in.
>>
>> Is this issue related to media change command?
>> if so, should I enable kernel config or do anything in user mode program?
>>
>> thanks for your help in advance,
>
> What does usbmon show?
after we enable CONFIG_SCSI_MULTI_LUN, we can udevent when SD plug in
card reader.

appreciate your kind 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] drivers: phy: exynos-usb2: add support for Exynos 3250

2014-07-04 Thread Marek Szyprowski
This patch adds support for Exynos3250 SoC to Exynos2USB PHY driver.
Although Exynos3250 has only one device phy interface, the register
layout and all operations that are required to get it enabled are almost
same as on Exynos4x12. The only different is one more register
(REFCLKSEL) which need to be set.

Signed-off-by: Marek Szyprowski 
---
 drivers/phy/Kconfig   | 12 ++--
 drivers/phy/phy-exynos4x12-usb2.c | 18 ++
 drivers/phy/phy-samsung-usb2.c|  6 ++
 drivers/phy/phy-samsung-usb2.h|  2 ++
 4 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 16a2f067c242..58737b9eaa6e 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -141,14 +141,14 @@ config PHY_EXYNOS4210_USB2
  phys are available - device, host, HSIC0 and HSIC1.
 
 config PHY_EXYNOS4X12_USB2
-   bool "Support for Exynos 4x12"
+   bool "Support for Exynos 3250/4x12"
depends on PHY_SAMSUNG_USB2
-   depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412)
+   depends on (SOC_EXYNOS3250 || SOC_EXYNOS4212 || SOC_EXYNOS4412)
help
- Enable USB PHY support for Exynos 4x12. This option requires that
- Samsung USB 2.0 PHY driver is enabled and means that support for this
- particular SoC is compiled in the driver. In case of Exynos 4x12 four
- phys are available - device, host, HSIC0 and HSIC1.
+ Enable USB PHY support for Exynos 3250/4x12. This option requires
+ that Samsung USB 2.0 PHY driver is enabled and means that support for
+ this particular SoC is compiled in the driver. In case of Exynos 4x12
+ four phys are available - device, host, HSIC0 and HSIC1.
 
 config PHY_EXYNOS5250_USB2
bool "Support for Exynos 5250"
diff --git a/drivers/phy/phy-exynos4x12-usb2.c 
b/drivers/phy/phy-exynos4x12-usb2.c
index 59d8dd3ff390..b29bbfacd4b5 100644
--- a/drivers/phy/phy-exynos4x12-usb2.c
+++ b/drivers/phy/phy-exynos4x12-usb2.c
@@ -67,6 +67,12 @@
 #define EXYNOS_4x12_UPHYCLK_PHYFSEL_24MHZ  (0x5 << 0)
 #define EXYNOS_4x12_UPHYCLK_PHYFSEL_50MHZ  (0x7 << 0)
 
+#define EXYNOS_4212_UPHYCLK_PHY0_ID_PULLUP (0x1 << 3)
+#define EXYNOS_4212_UPHYCLK_PHY0_COMMON_ON (0x1 << 4)
+#define EXYNOS_4212_UPHYCLK_PHY1_COMMON_ON (0x1 << 7)
+
+#define EXYNOS_3250_UPHYCLK_REFCLKSEL  (0x2 << 8)
+
 #define EXYNOS_4x12_UPHYCLK_PHY0_ID_PULLUP BIT(3)
 #define EXYNOS_4x12_UPHYCLK_PHY0_COMMON_ON BIT(4)
 #define EXYNOS_4x12_UPHYCLK_PHY1_COMMON_ON BIT(7)
@@ -197,6 +203,10 @@ static void exynos4x12_setup_clk(struct 
samsung_usb2_phy_instance *inst)
 
clk = readl(drv->reg_phy + EXYNOS_4x12_UPHYCLK);
clk &= ~EXYNOS_4x12_UPHYCLK_PHYFSEL_MASK;
+
+   if (drv->cfg->has_refclk_sel)
+   clk = EXYNOS_3250_UPHYCLK_REFCLKSEL;
+
clk |= drv->ref_reg_val << EXYNOS_4x12_UPHYCLK_PHYFSEL_OFFSET;
clk |= EXYNOS_4x12_UPHYCLK_PHY1_COMMON_ON;
writel(clk, drv->reg_phy + EXYNOS_4x12_UPHYCLK);
@@ -358,6 +368,14 @@ static const struct samsung_usb2_common_phy 
exynos4x12_phys[] = {
{},
 };
 
+const struct samsung_usb2_phy_config exynos3250_usb2_phy_config = {
+   .has_mode_switch= 1,
+   .has_refclk_sel = 1,
+   .num_phys   = 1,
+   .phys   = exynos4x12_phys,
+   .rate_to_clk= exynos4x12_rate_to_clk,
+};
+
 const struct samsung_usb2_phy_config exynos4x12_usb2_phy_config = {
.has_mode_switch= 1,
.num_phys   = EXYNOS4x12_NUM_PHYS,
diff --git a/drivers/phy/phy-samsung-usb2.c b/drivers/phy/phy-samsung-usb2.c
index 8a8c6bc8709a..36db8eb8c5f4 100644
--- a/drivers/phy/phy-samsung-usb2.c
+++ b/drivers/phy/phy-samsung-usb2.c
@@ -87,6 +87,12 @@ static struct phy *samsung_usb2_phy_xlate(struct device *dev,
 }
 
 static const struct of_device_id samsung_usb2_phy_of_match[] = {
+#ifdef CONFIG_PHY_EXYNOS4X12_USB2
+   {
+   .compatible = "samsung,exynos3250-usb2-phy",
+   .data = &exynos3250_usb2_phy_config,
+   },
+#endif
 #ifdef CONFIG_PHY_EXYNOS4210_USB2
{
.compatible = "samsung,exynos4210-usb2-phy",
diff --git a/drivers/phy/phy-samsung-usb2.h b/drivers/phy/phy-samsung-usb2.h
index 918847843a95..b03da0ef39ac 100644
--- a/drivers/phy/phy-samsung-usb2.h
+++ b/drivers/phy/phy-samsung-usb2.h
@@ -60,8 +60,10 @@ struct samsung_usb2_phy_config {
int (*rate_to_clk)(unsigned long, u32 *);
unsigned int num_phys;
bool has_mode_switch;
+   bool has_refclk_sel;
 };
 
+extern const struct samsung_usb2_phy_config exynos3250_usb2_phy_config;
 extern const struct samsung_usb2_phy_config exynos4210_usb2_phy_config;
 extern const struct samsung_usb2_phy_config exynos4x12_usb2_phy_config;
 extern const struct samsung_usb2_phy_config exynos5250_usb2_phy_config;
-- 
1.9.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
th

Re: [PATCH 2/3] ARM: dts: sti: Add st-dwc3 devicetree bindings documentation

2014-07-04 Thread Daniele Forsi
2014-07-04 13:13 GMT+02:00 Peter Griffin:

> +Required properties:
> + - compatible  : must be "st,stih407-dwc3"
> + - reg : glue logic base address and USB syscfg ctrl register offest
> + - reg-names   : Should be "reg-glue" and "syscfg-reg".
> + - st,syscon: should be phandle to system configuration node which
> + encompases the glue registers.
> + - resets   : phandle pointing to the system powerdown controller

minor knits:
s/offest/offset/
s/encompases/encompasses/
"Should" is upper case while all other lines in this block start with
a lower case letter;
two lines end with a full stop, three lines without;
colons the last lines do not align to the first three

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


Re: [PATCH 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC

2014-07-04 Thread Daniele Forsi
2014-07-04 13:13 GMT+02:00 Peter Griffin:

> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> index 8eb996e..f7b0518 100644
> --- a/drivers/usb/dwc3/Kconfig
> +++ b/drivers/usb/dwc3/Kconfig
> @@ -77,6 +77,15 @@ config USB_DWC3_KEYSTONE
> default USB_DWC3
> help
>   Support of USB2/3 functionality in TI Keystone2 platforms.
> +
> +config USB_DWC3_ST
> +   tristate "STMicroelectronics Platforms"
> +   depends on ARCH_STI && OF
> +   default USB_DWC3_HOST
> +   help
> + STMicroelectronics SoCs chip with one DesignWare Core USB3 IP
> + inside (i.e. STiH407).
> +
>   Say 'Y' or 'M' here if you have one such device
>
>  comment "Debugging features"

you are actually removing the line "Say 'Y' or 'M' here if you have
one such device" from the previous item

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


[PATCH] usb: chipidea: udc: avoid gadget driver insertion in host mode

2014-07-04 Thread Abbas Raza
From: Abbas Raza 

When gadget driver is inserted and OTG is in host mode, interrupts
occur which are not handled by chipidea driver causing following
problem. To avoid this problem, don't allow insertion of gadget
driver in host mode.

root@mx6q:~# echo -n host > /sys/kernel/debug/ci_hdrc.0/role
root@mx6q:~# modprobe g_ether
using random self ethernet address
using random host ethernet address
usb0: HOST MAC aa:4b:f8:b4:d7:81
usb0: MAC 5e:65:a8:9e:6e:45
using random self ethernet address
using random host ethernet address
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready
root@mx6q35:~# irq 75: nobody cared (try booting with the "irqpoll" option)
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-rc2-1-gd675913 #53
Backtrace:
[<80012418>] (dump_backtrace) from [<800126fc>] (show_stack+0x18/0x1c)
 r6:8092bae0 r5:8092bae0 r4: r3:
[<800126e4>] (show_stack) from [<806770bc>] (dump_stack+0x8c/0xa4)
[<80677030>] (dump_stack) from [<80074520>] (__report_bad_irq+0x28/0xc8)
 r6:004b r5: r4:be00ab00 r3:
[<800744f8>] (__report_bad_irq) from [<80074ae8>] (note_interrupt+0x264/0x2c4)
 r6:004b r5: r4:be00ab00 r3:
[<80074884>] (note_interrupt) from [<80072400>] 
(handle_irq_event_percpu+0xb4/0x13c)
 r10:80969dc6 r9:be00ab00 r8:004b r7: r6: r5:
 r4: r3:
[<8007234c>] (handle_irq_event_percpu) from [<800724cc>] 
(handle_irq_event+0x44/0x64)
 r10: r9:806816b0 r8:80907f20 r7:004b r6:bd882c40 r5:be00ab5c
 r4:be00ab00
[<80072488>] (handle_irq_event) from [<800758b8>] 
(handle_fasteoi_irq+0xc8/0x1bc)
 r6:8092bd64 r5:be00ab5c r4:be00ab00 r3:
[<800757f0>] (handle_fasteoi_irq) from [<80071b14>] 
(generic_handle_irq+0x30/0x44)
 r6:80906020 r5:80902e2c r4:004b r3:800757f0
[<80071ae4>] (generic_handle_irq) from [<8000f3d8>] (handle_IRQ+0x54/0xbc)
 r4:8090ed2c r3:0180
[<8000f384>] (handle_IRQ) from [<800086cc>] (gic_handle_irq+0x30/0x68)
 r8: r7:f4000100 r6:80907e28 r5:8090eea0 r4:f400010c r3:00a0
[<8000869c>] (gic_handle_irq) from [<80013264>] (__irq_svc+0x44/0x5c)
Exception stack(0x80907e28 to 0x80907e70)
7e20:   0001   80911f70 0282 80906000
7e40: 8002eec4 001d  806816b0  80907ebc  80907e70
7e60: 800663c4 8002e9bc 6113 
 r7:80907e5c r6: r5:6113 r4:8002e9bc
[<8002e8f4>] (__do_softirq) from [<8002eec4>] (irq_exit+0xb8/0x10c)
 r10: r9:806816b0 r8: r7:001d r6:80906000 r5:80902e2c
 r4:80906000
[<8002ee0c>] (irq_exit) from [<8000f3e0>] (handle_IRQ+0x5c/0xbc)
 r5:80902e2c r4:8090ed2c
[<8000f384>] (handle_IRQ) from [<800086cc>] (gic_handle_irq+0x30/0x68)
 r8:80969dc3 r7:f4000100 r6:80907f20 r5:8090eea0 r4:f400010c r3:00a0
[<8000869c>] (gic_handle_irq) from [<80013264>] (__irq_svc+0x44/0x5c)
Exception stack(0x80907f20 to 0x80907f68)
7f20: 0001 0001  80911f70 80906000 8090e98c 8090e938 80969dc3
7f40: 80969dc3 806816b0  80907f74  80907f68 8006640c 8000f754
7f60: 2013 
 r7:80907f54 r6: r5:2013 r4:8000f754
[<8000f72c>] (arch_cpu_idle) from [<80061c7c>] (cpu_startup_entry+0x104/0x16c)
[<80061b78>] (cpu_startup_entry) from [<80672258>] (rest_init+0xb0/0xd8)
 r7:808f4c00 r3:
[<806721a8>] (rest_init) from [<808b2bec>] (start_kernel+0x33c/0x3a8)
 r5:8096a000 r4:8090ea30
[<808b28b0>] (start_kernel) from [<10008074>] (0x10008074)
handlers:
[<804456a8>] ci_irq
Disabling IRQ #75
usb 2-1: new high-speed USB device number 2 using ci_hdrc
usb 2-1: device descriptor read/64, error -110
usb 2-1: device descriptor read/64, error -110
usb 2-1: new high-speed USB device number 3 using ci_hdrc
usb 2-1: device descriptor read/64, error -110
usb 2-1: device descriptor read/64, error -110
usb 2-1: new high-speed USB device number 4 using ci_hdrc
usb 2-1: device not accepting address 4, error -110
usb 2-1: new high-speed USB device number 5 using ci_hdrc
usb 2-1: device not accepting address 5, error -110
usb usb2-port1: unable to enumerate USB device
usb 2-1: new full-speed USB device number 6 using ci_hdrc
usb 2-1: device descriptor read/64, error -110
usb 2-1: device descriptor read/64, error -110
usb 2-1: new full-speed USB device number 7 using ci_hdrc
usb 2-1: device descriptor read/64, error -110
usb 2-1: device descriptor read/64, error -110
usb 2-1: new full-speed USB device number 8 using ci_hdrc
usb 2-1: device not accepting address 8, error -110
usb usb2-port1: cannot reset (err = -32)
usb usb2-port1: cannot reset (err = -32)
usb usb2-port1: cannot reset (err = -32)
usb usb2-port1: cannot reset (err = -32)
usb usb2-port1: cannot reset (err = -32)
usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
usb usb2-port1: unable to enumerate USB device

Signed-off-by: Abbas Raza 
---
 drivers/usb/chipidea/udc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/chipidea/udc.c b/drive

Re: Problem with Mobile Broadband on ubuntu

2014-07-04 Thread Oliver Neukum
On Thu, 2014-07-03 at 18:48 +0530, arun wrote:
> Bus 001 Device 031: ID 2001:7d01 D-Link Corp.
> 
> The verbose output text file is attached.
> 
> 2 things i would like to mention:
> - As soon as it is inserted , it is 2001:a706. But after sometime (few
> seconds) it changes to the above. I guess this is due to the pkg
> installed, and the initial usb_modeswitch.
> 
> - Also if i see dmesg output, the usb-dongle is initially shown as sr1
> (2001:a706), and then sg2 (2001:7d01).

Then all is as it should be.

> Now, if I do 3g_connect.sh sg2 (which is in /usr/bin after
> d-link's .deb package is installed), there are some errors, but i
> sometimes get it working. It is totally random. I am attaching this
> file also.

I am afraid we cannot debug ubuntu's shell scripts.
Is there anything in dmesg in the error cases?

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: Problem with Mobile Broadband on ubuntu

2014-07-04 Thread Bjørn Mork
Oliver Neukum  writes:
> On Thu, 2014-07-03 at 18:48 +0530, arun wrote:
>> Bus 001 Device 031: ID 2001:7d01 D-Link Corp.
>> 
>> The verbose output text file is attached.
>> 
>> 2 things i would like to mention:
>> - As soon as it is inserted , it is 2001:a706. But after sometime (few
>> seconds) it changes to the above. I guess this is due to the pkg
>> installed, and the initial usb_modeswitch.
>> 
>> - Also if i see dmesg output, the usb-dongle is initially shown as sr1
>> (2001:a706), and then sg2 (2001:7d01).
>
> Then all is as it should be.
>
>> Now, if I do 3g_connect.sh sg2 (which is in /usr/bin after
>> d-link's .deb package is installed), there are some errors, but i
>> sometimes get it working. It is totally random. I am attaching this
>> file also.
>
> I am afraid we cannot debug ubuntu's shell scripts.

The 3g_connect.sh script is actually included on the CD image on that
modem.  It's a simple ppp dialler script.  Kudos to Mediatek/D-Link for
at least attempting to support Linux.

But it is of course much better to just use whatever support you already
have in your distro.  The serial ports of 2001:7d01 are already
supported by the option driver, and the MBIM function is supported by
the cdc_mbim class driver.  Use a recent ModemManager and kernel, and do
not mess with the .deb package from the modem.



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


ath9k -> bogus usb xfer on at91

2014-07-04 Thread Anders Darander
Hi,

While porting an internal BSP (a design based on a at91sam9g20 SoC)
from 3.10 to 3.14, I got flooded with messages like:

~# usb 1-1: new full-speed USB device number 3 using at91_ohci
usb 1-1: ath9k_htc: Firmware htc_9271.fw requested
usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
---[ cut here ]---
WARNING: CPU: 0 PID: 93 at
/mnt/cs-builds/anders/oe-build/build-ccu/tmp-eglibc/work/ccu-oe-linux-gnueabi/linux-yocto-ccu/3.14+gitAUTOINC+7b03bd3dfd-r0/linux/drivers/usb/core/urb.c:450
usb_submit_urb+0x2ac/0x460()
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
Modules linked in: ath9k_htc ath9k_common ath9k_hw ath mac80211
cfg80211 ccudrv(O) at91_disable_wdt(O) at91_bootcount(O) at91_adc(O)
CPU: 0 PID: 93 Comm: kworker/0:3 Tainted: G W O 3.14.10-ccu #2
Workqueue: events request_firmware_work_func
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (warn_slowpath_common+0x60/0x80)
[] (warn_slowpath_common) from []
(warn_slowpath_fmt+0x2c/0x3c)
[] (warn_slowpath_fmt) from [] (usb_submit_urb+0x2ac/0x460)
[] (usb_submit_urb) from []
(hif_usb_send+0x268/0x2c8 [ath9k_htc])
[] (hif_usb_send [ath9k_htc]) from []
(htc_issue_send.constprop.4+0x64/0x68 [ath9k_htc])
[] (htc_issue_send.constprop.4 [ath9k_htc]) from
[] (htc_connect_service+0x170/0x1c8 [ath9k_htc])
[] (htc_connect_service [ath9k_htc]) from []
(ath9k_wmi_connect+0x50/0x6c [ath9k_htc])
[] (ath9k_wmi_connect [ath9k_htc]) from []
(ath9k_init_htc_services.isra.10+0x20/0x280 [ath9k_htc])
[] (ath9k_init_htc_services.isra.10 [ath9k_htc]) from
[] (ath9k_htc_probe_device+0xe4/0x928 [ath9k_htc])
[] (ath9k_htc_probe_device [ath9k_htc]) from []
(ath9k_htc_hw_init+0x10/0x30 [ath9k_htc])
[] (ath9k_htc_hw_init [ath9k_htc]) from []
(ath9k_hif_usb_firmware_cb+0x4cc/0x5c8 [ath9k_htc])
[] (ath9k_hif_usb_firmware_cb [ath9k_htc]) from []
(request_firmware_work_func+0x2c/0x4c)
[] (request_firmware_work_func) from []
(process_one_work+0x20c/0x33c)
[] (process_one_work) from [] (worker_thread+0x234/0x384)
[] (worker_thread) from [] (kthread+0xc0/0xd4)
[] (kthread) from [] (ret_from_fork+0x14/0x24)
--[ end trace b92d2c3cd165cd68 ]--
---[ cut here ]---

After temporarily reverting commit
3482528e9aced9234d4e2a4a9538c882a9aa5aa2, which enables debug checks
on all USB urb's (previously is was only enabled for a
CONFIG_USB_DEBUG enabled kernel), the WiFi chip starts to work
correctly. The chip in question is a ar9721.

 The same USB stick works without these messages on my laptop; while
another USB stick, based on an rtl8187 chip, works without these
messages on the target system (at91sam9g20)

Any pointers to what it could be? Or suggestions on how to attack the issue?

Thanks in advance!
Cheers,
Anders

-- 
Anders Darander
EPO guidelines 1978: "If the contribution to the known art resides
solely in a computer program then the subject matter is not
patentable in whatever manner it may be presented in the claims."
--
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/5] xhci: A default implementation for Ux timeout calculation and tier policy check

2014-07-04 Thread Mathias Nyman
From: Pratyush Anand 

As best case, a host controller should support U0 to U1 switching for
the devices connected below any tier of hub level supported by usb
specification. Therefore xhci_check_tier_policy should always return
success as default implementation.

A host should be able to issue LGO_Ux after the timeout calculated as
per definition of system exit latency defined in C.1.5.2. Therefore
xhci_calculate_ux_timeout returns ux_params.sel as the default
implementation.

Use default calculation in absence of any vendor specific limitations.

Signed-off-by: Pratyush Anand 
Tested-by: Aymen Bouattay 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci.c | 66 +++--
 1 file changed, 48 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2b8d9a2..3d943ed 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4299,8 +4299,7 @@ static u16 xhci_get_timeout_no_hub_lpm(struct usb_device 
*udev,
return USB3_LPM_DISABLED;
 }
 
-/* Returns the hub-encoded U1 timeout value.
- * The U1 timeout should be the maximum of the following values:
+/* The U1 timeout should be the maximum of the following values:
  *  - For control endpoints, U1 system exit latency (SEL) * 3
  *  - For bulk endpoints, U1 SEL * 5
  *  - For interrupt endpoints:
@@ -4308,7 +4307,8 @@ static u16 xhci_get_timeout_no_hub_lpm(struct usb_device 
*udev,
  *- Periodic EPs, max(105% of bInterval, U1 SEL * 2)
  *  - For isochronous endpoints, max(105% of bInterval, U1 SEL * 2)
  */
-static u16 xhci_calculate_intel_u1_timeout(struct usb_device *udev,
+static unsigned long long xhci_calculate_intel_u1_timeout(
+   struct usb_device *udev,
struct usb_endpoint_descriptor *desc)
 {
unsigned long long timeout_ns;
@@ -4340,11 +4340,28 @@ static u16 xhci_calculate_intel_u1_timeout(struct 
usb_device *udev,
return 0;
}
 
-   /* The U1 timeout is encoded in 1us intervals. */
-   timeout_ns = DIV_ROUND_UP_ULL(timeout_ns, 1000);
-   /* Don't return a timeout of zero, because that's USB3_LPM_DISABLED. */
+   return timeout_ns;
+}
+
+/* Returns the hub-encoded U1 timeout value. */
+static u16 xhci_calculate_u1_timeout(struct xhci_hcd *xhci,
+   struct usb_device *udev,
+   struct usb_endpoint_descriptor *desc)
+{
+   unsigned long long timeout_ns;
+
+   if (xhci->quirks & XHCI_INTEL_HOST)
+   timeout_ns = xhci_calculate_intel_u1_timeout(udev, desc);
+   else
+   timeout_ns = udev->u1_params.sel;
+
+   /* The U1 timeout is encoded in 1us intervals.
+* Don't return a timeout of zero, because that's USB3_LPM_DISABLED.
+*/
if (timeout_ns == USB3_LPM_DISABLED)
-   timeout_ns++;
+   timeout_ns = 1;
+   else
+   timeout_ns = DIV_ROUND_UP_ULL(timeout_ns, 1000);
 
/* If the necessary timeout value is bigger than what we can set in the
 * USB 3.0 hub, we have to disable hub-initiated U1.
@@ -4356,14 +4373,14 @@ static u16 xhci_calculate_intel_u1_timeout(struct 
usb_device *udev,
return xhci_get_timeout_no_hub_lpm(udev, USB3_LPM_U1);
 }
 
-/* Returns the hub-encoded U2 timeout value.
- * The U2 timeout should be the maximum of:
+/* The U2 timeout should be the maximum of:
  *  - 10 ms (to avoid the bandwidth impact on the scheduler)
  *  - largest bInterval of any active periodic endpoint (to avoid going
  *into lower power link states between intervals).
  *  - the U2 Exit Latency of the device
  */
-static u16 xhci_calculate_intel_u2_timeout(struct usb_device *udev,
+static unsigned long long xhci_calculate_intel_u2_timeout(
+   struct usb_device *udev,
struct usb_endpoint_descriptor *desc)
 {
unsigned long long timeout_ns;
@@ -4379,6 +4396,21 @@ static u16 xhci_calculate_intel_u2_timeout(struct 
usb_device *udev,
if (u2_del_ns > timeout_ns)
timeout_ns = u2_del_ns;
 
+   return timeout_ns;
+}
+
+/* Returns the hub-encoded U2 timeout value. */
+static u16 xhci_calculate_u2_timeout(struct xhci_hcd *xhci,
+   struct usb_device *udev,
+   struct usb_endpoint_descriptor *desc)
+{
+   unsigned long long timeout_ns;
+
+   if (xhci->quirks & XHCI_INTEL_HOST)
+   timeout_ns = xhci_calculate_intel_u2_timeout(udev, desc);
+   else
+   timeout_ns = udev->u2_params.sel;
+
/* The U2 timeout is encoded in 256us intervals */
timeout_ns = DIV_ROUND_UP_ULL(timeout_ns, 256 * 1000);
/* If the necessary timeout value is bigger than what we can set in the
@@ -4397,13 +4429,10 @@ static u16 
xhci_call_host_update_timeout_for_endpoint(struct xhci_hcd *xhci,
enum usb3_link_state state,
u16 *timeout)
 {
-   if (state == USB3_LPM_U1) {
-   if (xhci->quirks

[PATCH 3/5] xhci: Platform: Set xhci lpm support quirk based on platform data

2014-07-04 Thread Mathias Nyman
From: Pratyush Anand 

If an xhci platform supports USB3 LPM capability then enable
XHCI_LPM_SUPPORT quirk flag.

Signed-off-by: Pratyush Anand 
Signed-off-by: Mathias Nyman 
---
 Documentation/devicetree/bindings/usb/usb-xhci.txt |  3 ++-
 drivers/usb/host/xhci-plat.c   |  6 +
 include/linux/usb/xhci_pdriver.h   | 27 ++
 3 files changed, 35 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/usb/xhci_pdriver.h

diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index 5a79377..86f67f0 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -9,8 +9,9 @@ Required properties:
 register set for the device.
   - interrupts: one XHCI interrupt should be described here.
 
-Optional property:
+Optional properties:
   - clocks: reference to a clock
+  - usb3-lpm-capable: determines if platform is USB3 LPM capable
 
 Example:
usb@f0931000 {
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index a4ccd0e..b17459d 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xhci.h"
 #include "xhci-mvebu.h"
@@ -97,6 +98,8 @@ static const struct hc_driver xhci_plat_xhci_driver = {
 
 static int xhci_plat_probe(struct platform_device *pdev)
 {
+   struct device_node  *node = pdev->dev.of_node;
+   struct usb_xhci_pdata   *pdata = dev_get_platdata(&pdev->dev);
const struct hc_driver  *driver;
struct xhci_hcd *xhci;
struct resource *res;
@@ -185,6 +188,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto dealloc_usb2_hcd;
}
 
+   if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
+   (pdata && pdata->usb3_lpm_capable))
+   xhci->quirks |= XHCI_LPM_SUPPORT;
/*
 * Set the xHCI pointer before xhci_plat_setup() (aka hcd_driver.reset)
 * is called by usb_add_hcd().
diff --git a/include/linux/usb/xhci_pdriver.h b/include/linux/usb/xhci_pdriver.h
new file mode 100644
index 000..376654b
--- /dev/null
+++ b/include/linux/usb/xhci_pdriver.h
@@ -0,0 +1,27 @@
+/*
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ */
+
+#ifndef __USB_CORE_XHCI_PDRIVER_H
+#define __USB_CORE_XHCI_PDRIVER_H
+
+/**
+ * struct usb_xhci_pdata - platform_data for generic xhci platform driver
+ *
+ * @usb3_lpm_capable:  determines if this xhci platform supports USB3
+ * LPM capability
+ *
+ */
+struct usb_xhci_pdata {
+   unsignedusb3_lpm_capable:1;
+};
+
+#endif /* __USB_CORE_XHCI_PDRIVER_H */
-- 
1.8.3.2

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


[PATCH 2/5] xhci: Platform: Add (en/dis)able_usb3_lpm_timeout

2014-07-04 Thread Mathias Nyman
From: Pratyush Anand 

To use auto U0-U1/U2 transition by xhci platform device add
(en/dis)able_usb3_lpm_timeout function to the xhci_plat_xhci_driver struct.

Signed-off-by: Pratyush Anand 
Tested-by: Aymen Bouattay 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-plat.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 29d8adb..a4ccd0e 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -90,6 +90,9 @@ static const struct hc_driver xhci_plat_xhci_driver = {
.hub_status_data =  xhci_hub_status_data,
.bus_suspend =  xhci_bus_suspend,
.bus_resume =   xhci_bus_resume,
+
+   .enable_usb3_lpm_timeout =  xhci_enable_usb3_lpm_timeout,
+   .disable_usb3_lpm_timeout = xhci_disable_usb3_lpm_timeout,
 };
 
 static int xhci_plat_probe(struct platform_device *pdev)
-- 
1.8.3.2

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


[PATCH 0/5] xhci features for usb-next

2014-07-04 Thread Mathias Nyman
Hi Greg, Felipe

This patchseries by Pratyush Anand provide LPM support
for the dwc3 xhci hosts.

Patch 4/5 touches dwc3, Felipe already gave feedback on an earlier version but
I can't find an Ack anywhere?

Patch 5/5 touches usb core hub code, not much, but still outside xhci

-Mathias

Pratyush Anand (5):
  xhci: A default implementation for Ux timeout calculation and tier
policy check
  xhci: Platform: Add (en/dis)able_usb3_lpm_timeout
  xhci: Platform: Set xhci lpm support quirk based on platform data
  dwc3: host: Enable USB3 LPM capability
  usb: allow lpm (en/dis)able only if device is atleast in default state

 Documentation/devicetree/bindings/usb/usb-xhci.txt |  3 +-
 drivers/usb/core/hub.c |  6 +-
 drivers/usb/dwc3/Kconfig   |  7 +++
 drivers/usb/dwc3/host.c| 14 +
 drivers/usb/host/xhci-plat.c   |  9 +++
 drivers/usb/host/xhci.c| 66 --
 include/linux/usb/xhci_pdriver.h   | 27 +
 7 files changed, 111 insertions(+), 21 deletions(-)
 create mode 100644 include/linux/usb/xhci_pdriver.h

-- 
1.8.3.2

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


[PATCH 5/5] usb: allow lpm (en/dis)able only if device is atleast in default state

2014-07-04 Thread Mathias Nyman
From: Pratyush Anand 

When a USB device is disconnected, usb_unbind_interface is called, which
tries to enable and disable LPM. usb_enable_lpm also try to send a
control command SET SEL to the device.
Since device is already disconnected, therefore it does not make sense
to execute usb_(en/dis)able_lpm.
This patch returns from usb_(en/dis)able_lpm, if device was not in
default state atleast.

Signed-off-by: Pratyush Anand 
Tested-by: Aymen Bouattay 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/core/hub.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 879b66e..9c469dc 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3853,7 +3853,8 @@ int usb_disable_lpm(struct usb_device *udev)
 
if (!udev || !udev->parent ||
udev->speed != USB_SPEED_SUPER ||
-   !udev->lpm_capable)
+   !udev->lpm_capable ||
+   udev->state < USB_STATE_DEFAULT)
return 0;
 
hcd = bus_to_hcd(udev->bus);
@@ -3909,7 +3910,8 @@ void usb_enable_lpm(struct usb_device *udev)
 
if (!udev || !udev->parent ||
udev->speed != USB_SPEED_SUPER ||
-   !udev->lpm_capable)
+   !udev->lpm_capable ||
+   udev->state < USB_STATE_DEFAULT)
return;
 
udev->lpm_disable_count--;
-- 
1.8.3.2

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


[PATCH 4/5] dwc3: host: Enable USB3 LPM capability

2014-07-04 Thread Mathias Nyman
From: Pratyush Anand 

All dwc3 based xhci host controller supports USB3.0 LPM functionality.
Therefore enable it in platform data for all dwc3 based xhci device if
DWC3_HOST_USB3_LPM_ENABLE is selected in Kconfig.

Signed-off-by: Pratyush Anand 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/dwc3/Kconfig |  7 +++
 drivers/usb/dwc3/host.c  | 14 ++
 2 files changed, 21 insertions(+)

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 8eb996e..75a8af4 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -92,4 +92,11 @@ config USB_DWC3_VERBOSE
help
  Say Y here to enable verbose debugging messages on DWC3 Driver.
 
+config DWC3_HOST_USB3_LPM_ENABLE
+   bool "Enable USB3 LPM Capability"
+   depends on USB_DWC3_HOST=y || USB_DWC3_DUAL_ROLE=y
+   default n
+   help
+ Select this when you want to enable USB3 LPM with dwc3 xhci host.
+
 endif
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index 32db328..dcb8ca0 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -16,12 +16,14 @@
  */
 
 #include 
+#include 
 
 #include "core.h"
 
 int dwc3_host_init(struct dwc3 *dwc)
 {
struct platform_device  *xhci;
+   struct usb_xhci_pdata   pdata;
int ret;
 
xhci = platform_device_alloc("xhci-hcd", PLATFORM_DEVID_AUTO);
@@ -46,6 +48,18 @@ int dwc3_host_init(struct dwc3 *dwc)
goto err1;
}
 
+   memset(&pdata, 0, sizeof(pdata));
+
+#ifdef CONFIG_DWC3_HOST_USB3_LPM_ENABLE
+   pdata.usb3_lpm_capable = 1;
+#endif
+
+   ret = platform_device_add_data(xhci, &pdata, sizeof(pdata));
+   if (ret) {
+   dev_err(dwc->dev, "couldn't add platform data to xHCI 
device\n");
+   goto err1;
+   }
+
ret = platform_device_add(xhci);
if (ret) {
dev_err(dwc->dev, "failed to register xHCI device\n");
-- 
1.8.3.2

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


Re: Problem with Mobile Broadband on ubuntu

2014-07-04 Thread Lars Melin

On 2014-07-04 20:26, Bjørn Mork wrote:

Oliver Neukum  writes:

On Thu, 2014-07-03 at 18:48 +0530, arun wrote:

Bus 001 Device 031: ID 2001:7d01 D-Link Corp.

The verbose output text file is attached.

2 things i would like to mention:
- As soon as it is inserted , it is 2001:a706. But after sometime (few
seconds) it changes to the above. I guess this is due to the pkg
installed, and the initial usb_modeswitch.

- Also if i see dmesg output, the usb-dongle is initially shown as sr1
(2001:a706), and then sg2 (2001:7d01).

Then all is as it should be.


 Now, if I do 3g_connect.sh sg2 (which is in /usr/bin after
d-link's .deb package is installed), there are some errors, but i
sometimes get it working. It is totally random. I am attaching this
file also.

I am afraid we cannot debug ubuntu's shell scripts.

The 3g_connect.sh script is actually included on the CD image on that
modem.  It's a simple ppp dialler script.  Kudos to Mediatek/D-Link for
at least attempting to support Linux.

But it is of course much better to just use whatever support you already
have in your distro.  The serial ports of 2001:7d01 are already
supported by the option driver, and the MBIM function is supported by
the cdc_mbim class driver.  Use a recent ModemManager and kernel, and do
not mess with the .deb package from the modem.



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

I've already told him (off the list) to upgrade to Ubuntu 14.04.
Ubuntu 12.04 which is an LTS distro is hopeless behind in drivers and 
their usb_modeswitch

version is two and a half years old.
The Ubuntu maintainers seems to have their own definition of LTS.
--
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: ath9k -> bogus usb xfer on at91

2014-07-04 Thread Oleksij Rempel
Hi Andreas,

... uff.. again at91_ohci with 12 Mbit usb!!! No interest. I don't even
wont to talk about it. Except only if you have usb protocol analyser.

Beside, this warning is about slow path, which i would expect on this
configuration.

Am 04.07.2014 15:32, schrieb Anders Darander:
> Hi,
> 
> While porting an internal BSP (a design based on a at91sam9g20 SoC)
> from 3.10 to 3.14, I got flooded with messages like:
> 
> ~# usb 1-1: new full-speed USB device number 3 using at91_ohci
> usb 1-1: ath9k_htc: Firmware htc_9271.fw requested
> usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
> ---[ cut here ]---
> WARNING: CPU: 0 PID: 93 at
> /mnt/cs-builds/anders/oe-build/build-ccu/tmp-eglibc/work/ccu-oe-linux-gnueabi/linux-yocto-ccu/3.14+gitAUTOINC+7b03bd3dfd-r0/linux/drivers/usb/core/urb.c:450
> usb_submit_urb+0x2ac/0x460()
> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> Modules linked in: ath9k_htc ath9k_common ath9k_hw ath mac80211
> cfg80211 ccudrv(O) at91_disable_wdt(O) at91_bootcount(O) at91_adc(O)
> CPU: 0 PID: 93 Comm: kworker/0:3 Tainted: G W O 3.14.10-ccu #2
> Workqueue: events request_firmware_work_func
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (warn_slowpath_common+0x60/0x80)
> [] (warn_slowpath_common) from []
> (warn_slowpath_fmt+0x2c/0x3c)
> [] (warn_slowpath_fmt) from [] 
> (usb_submit_urb+0x2ac/0x460)
> [] (usb_submit_urb) from []
> (hif_usb_send+0x268/0x2c8 [ath9k_htc])
> [] (hif_usb_send [ath9k_htc]) from []
> (htc_issue_send.constprop.4+0x64/0x68 [ath9k_htc])
> [] (htc_issue_send.constprop.4 [ath9k_htc]) from
> [] (htc_connect_service+0x170/0x1c8 [ath9k_htc])
> [] (htc_connect_service [ath9k_htc]) from []
> (ath9k_wmi_connect+0x50/0x6c [ath9k_htc])
> [] (ath9k_wmi_connect [ath9k_htc]) from []
> (ath9k_init_htc_services.isra.10+0x20/0x280 [ath9k_htc])
> [] (ath9k_init_htc_services.isra.10 [ath9k_htc]) from
> [] (ath9k_htc_probe_device+0xe4/0x928 [ath9k_htc])
> [] (ath9k_htc_probe_device [ath9k_htc]) from []
> (ath9k_htc_hw_init+0x10/0x30 [ath9k_htc])
> [] (ath9k_htc_hw_init [ath9k_htc]) from []
> (ath9k_hif_usb_firmware_cb+0x4cc/0x5c8 [ath9k_htc])
> [] (ath9k_hif_usb_firmware_cb [ath9k_htc]) from []
> (request_firmware_work_func+0x2c/0x4c)
> [] (request_firmware_work_func) from []
> (process_one_work+0x20c/0x33c)
> [] (process_one_work) from [] (worker_thread+0x234/0x384)
> [] (worker_thread) from [] (kthread+0xc0/0xd4)
> [] (kthread) from [] (ret_from_fork+0x14/0x24)
> --[ end trace b92d2c3cd165cd68 ]--
> ---[ cut here ]---
> 
> After temporarily reverting commit
> 3482528e9aced9234d4e2a4a9538c882a9aa5aa2, which enables debug checks
> on all USB urb's (previously is was only enabled for a
> CONFIG_USB_DEBUG enabled kernel), the WiFi chip starts to work
> correctly. The chip in question is a ar9721.
> 
>  The same USB stick works without these messages on my laptop; while
> another USB stick, based on an rtl8187 chip, works without these
> messages on the target system (at91sam9g20)
> 
> Any pointers to what it could be? Or suggestions on how to attack the issue?
> 
> Thanks in advance!
> Cheers,
> Anders
> 


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature


RE: Problem with Mobile Broadband on ubuntu

2014-07-04 Thread David Laight
> I've already told him (off the list) to upgrade to Ubuntu 14.04.
> Ubuntu 12.04 which is an LTS distro is hopeless behind in drivers and
> their usb_modeswitch
> version is two and a half years old.
> The Ubuntu maintainers seems to have their own definition of LTS.

Not as back as RHEL5 (2.6.18 based, extended support through to 2020 :-)



Re: XHCI, "brain-dead scanner", and microframe rounding

2014-07-04 Thread Mathias Nyman
On 07/01/2014 09:07 AM, Mike Mammarella wrote:
>> Hi
>>
>> Can you add xhci debugging by enabling CONFIG_DYNAMIC_DEBUG, and run
>> `echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control`
>> as root,
>> and send me the output of dmesg.
>>
>> Without debugging info it's hard to guess what's going on.
>>
>> The microframe rounding look a bit suspicious:
>> [12864.453456] usb 3-4: ep 0x81 - rounding interval to 128 microframes, ep 
>> desc says 255 microframes
>>
>> xhci specs says it needs the interval rounded to nearest 2^(X) value, which 
>> would be 256, not 128. I'll take a look at that.
>>
>> An other possibility is that it's related to how xhci handles halted 
>> endpoints. I got some untested code to fix this, It needs a lot of cleanup 
>> but can be tested.
>>
>> If you are able to test my ep_reset_halt_test branch (with xhci debugging) 
>> I'd be interested to know if it helps.
>>
>> Code is at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git 
>> ep_reset_halt_test
>>
>> -Mathias
> 
> Thanks! I've built a kernel from fb58633e with CONFIG_DYNAMIC_DEBUG enabled.
> (I also had to mount debugfs, it turns out.) The scanner does not work in
> this configuration. I've posted the logs here:
> 
> http://spark.crystalorb.net/mikem/dmesg.log
> http://spark.crystalorb.net/mikem/scanadf.log
> 
> dmesg seems to have much more information than what showed up on the
> console (which showed only MATTU messages); it may be relevant when
> sifting through that output that the root file system is also on USB.
> 

Thanks,

Took a quick look, but can't find any obvious reason why it fails.
I'll be out of office next week, but I'll try to take a better look again when 
I return   

usbmon traces of this could give some hint on what is happening

-Mathias

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


Some question about usb scsi storage driver

2014-07-04 Thread loody
hi all:
when I trace kernel driver source about usb scsi storage driver, I
have below 2 questions:
1. in sd.c -> static int sd_probe(struct device *dev)
we use below macro to get scsi_device.
   struct scsi_device *sdp = to_scsi_device(dev);

take usb for example, is usb storage driver allocate memory for
scsi_device then calling sd_probe?
I am looking for usb_stor_probe1 and usb_stor_probe2 but not find
where it is.

2. at the end of sd.c -> sd_probe, why we call async_schedule_domain like below
  async_schedule_domain(sd_probe_async, sdkp, &scsi_sd_probe_domain);
to finish scsi device initialization?
Couldn't we put what sd_probe_async directly in sd_probe?
is there any benefit to do so?

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


Re: Some question about usb scsi storage driver

2014-07-04 Thread Maurizio Lombardi


On 07/04/2014 04:44 PM, loody wrote:
> 
> 2. at the end of sd.c -> sd_probe, why we call async_schedule_domain like 
> below
>   async_schedule_domain(sd_probe_async, sdkp, &scsi_sd_probe_domain);
> to finish scsi device initialization?
> Couldn't we put what sd_probe_async directly in sd_probe?
> is there any benefit to do so?

A possible explanation may be that sd_probe_async() calls sd_spinup_disk(), 
this function spins up the drive and
may block for some seconds, so it is better to do that asynchronously.

Regards,
Maurizio Lombardi
--
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: ath9k -> bogus usb xfer on at91

2014-07-04 Thread Alan Stern
On Fri, 4 Jul 2014, Anders Darander wrote:

> Hi,
> 
> While porting an internal BSP (a design based on a at91sam9g20 SoC)
> from 3.10 to 3.14, I got flooded with messages like:
> 
> ~# usb 1-1: new full-speed USB device number 3 using at91_ohci
> usb 1-1: ath9k_htc: Firmware htc_9271.fw requested
> usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
> ---[ cut here ]---
> WARNING: CPU: 0 PID: 93 at
> /mnt/cs-builds/anders/oe-build/build-ccu/tmp-eglibc/work/ccu-oe-linux-gnueabi/linux-yocto-ccu/3.14+gitAUTOINC+7b03bd3dfd-r0/linux/drivers/usb/core/urb.c:450
> usb_submit_urb+0x2ac/0x460()
> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> Modules linked in: ath9k_htc ath9k_common ath9k_hw ath mac80211
> cfg80211 ccudrv(O) at91_disable_wdt(O) at91_bootcount(O) at91_adc(O)
> CPU: 0 PID: 93 Comm: kworker/0:3 Tainted: G W O 3.14.10-ccu #2
> Workqueue: events request_firmware_work_func
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (warn_slowpath_common+0x60/0x80)
> [] (warn_slowpath_common) from []
> (warn_slowpath_fmt+0x2c/0x3c)
> [] (warn_slowpath_fmt) from [] 
> (usb_submit_urb+0x2ac/0x460)
> [] (usb_submit_urb) from []
> (hif_usb_send+0x268/0x2c8 [ath9k_htc])
> [] (hif_usb_send [ath9k_htc]) from []
> (htc_issue_send.constprop.4+0x64/0x68 [ath9k_htc])
> [] (htc_issue_send.constprop.4 [ath9k_htc]) from
> [] (htc_connect_service+0x170/0x1c8 [ath9k_htc])
> [] (htc_connect_service [ath9k_htc]) from []
> (ath9k_wmi_connect+0x50/0x6c [ath9k_htc])
> [] (ath9k_wmi_connect [ath9k_htc]) from []
> (ath9k_init_htc_services.isra.10+0x20/0x280 [ath9k_htc])
> [] (ath9k_init_htc_services.isra.10 [ath9k_htc]) from
> [] (ath9k_htc_probe_device+0xe4/0x928 [ath9k_htc])
> [] (ath9k_htc_probe_device [ath9k_htc]) from []
> (ath9k_htc_hw_init+0x10/0x30 [ath9k_htc])
> [] (ath9k_htc_hw_init [ath9k_htc]) from []
> (ath9k_hif_usb_firmware_cb+0x4cc/0x5c8 [ath9k_htc])
> [] (ath9k_hif_usb_firmware_cb [ath9k_htc]) from []
> (request_firmware_work_func+0x2c/0x4c)
> [] (request_firmware_work_func) from []
> (process_one_work+0x20c/0x33c)
> [] (process_one_work) from [] (worker_thread+0x234/0x384)
> [] (worker_thread) from [] (kthread+0xc0/0xd4)
> [] (kthread) from [] (ret_from_fork+0x14/0x24)
> --[ end trace b92d2c3cd165cd68 ]--
> ---[ cut here ]---

I can't tell exactly where the fault is, but this message means that an
URB was submitted for a bulk endpoint with a pipe of type
PIPE_INTERRUPT.

> After temporarily reverting commit
> 3482528e9aced9234d4e2a4a9538c882a9aa5aa2, which enables debug checks
> on all USB urb's (previously is was only enabled for a
> CONFIG_USB_DEBUG enabled kernel), the WiFi chip starts to work
> correctly. The chip in question is a ar9721.
> 
>  The same USB stick works without these messages on my laptop; while
> another USB stick, based on an rtl8187 chip, works without these
> messages on the target system (at91sam9g20)
> 
> Any pointers to what it could be? Or suggestions on how to attack the issue?

Fix the URB submission to use the correct pipe type.

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: Some question about usb scsi storage driver

2014-07-04 Thread Alan Stern
On Fri, 4 Jul 2014, loody wrote:

> hi all:
> when I trace kernel driver source about usb scsi storage driver, I
> have below 2 questions:
> 1. in sd.c -> static int sd_probe(struct device *dev)
> we use below macro to get scsi_device.
>struct scsi_device *sdp = to_scsi_device(dev);
> 
> take usb for example, is usb storage driver allocate memory for
> scsi_device then calling sd_probe?

No.

> I am looking for usb_stor_probe1 and usb_stor_probe2 but not find
> where it is.

Because it's not there.  The memory is allocated by 
drivers/scsi/scsi_scan.c:scsi_alloc_sdev().

> 2. at the end of sd.c -> sd_probe, why we call async_schedule_domain like 
> below
>   async_schedule_domain(sd_probe_async, sdkp, &scsi_sd_probe_domain);
> to finish scsi device initialization?
> Couldn't we put what sd_probe_async directly in sd_probe?
> is there any benefit to do so?

Like Maurizio said, the benefit is that the probe routine will return
quickly so that other devices can be probed while the drive spins up.

Alan Stern

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


Re: [PATCH v3 1/2] usb: doc: udc-xilinx: Add devicetree bindings

2014-07-04 Thread Mark Rutland
On Tue, Jun 24, 2014 at 07:44:10AM +0100, sundeep subbaraya wrote:
> Ping
> 
> Thanks,
> Sundeep.B.S.
> 
> On Tue, Jun 10, 2014 at 5:34 PM,   wrote:
> > From: Subbaraya Sundeep Bhatta 
> >
> > Add devicetree bindings for Xilinx axi udc driver.
> >
> > Signed-off-by: Subbaraya Sundeep Bhatta 
> > ---
> > Changes for v3:
> > - None
> > Changes for v2:
> > - replaced xlnx,include-dma with xlnx,has-builtin-dma
> >
> >  .../devicetree/bindings/usb/udc-xilinx.txt |   20 
> > 
> >  1 files changed, 20 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/usb/udc-xilinx.txt
> >
> > diff --git a/Documentation/devicetree/bindings/usb/udc-xilinx.txt 
> > b/Documentation/devicetree/bindings/usb/udc-xilinx.txt
> > new file mode 100644
> > index 000..7c24fac
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/udc-xilinx.txt
> > @@ -0,0 +1,20 @@
> > +Xilinx AXI USB2 device controller
> > +
> > +Required properties:
> > +- compatible   : Should be "xlnx,axi-usb2-device-4.00.a"

That's an interesting name. What's the product name? Is the a manual?

> > +- reg  : Physical base address and size of the Axi USB2
> > + device registers map.
> > +- interrupts   : Property with a value describing the interrupt
> > + number.

Describe what this logically is. Everyone knows that this is a property
with a value, and everyone knows that an interrupts property describes
interrupts.

The ket point is _which_ interrupts this describes.

> > +- interrupt-parent : Must be core interrupt controller

This isn't strictly necessary anyway.

> > +- xlnx,include-dma : if DMA is included

You appear to have forgotten to fix this name, judging by the changelog
and example.

> > +
> > +Example:
> > +   axi-usb2-device@42e0 {
> > +compatible = "xlnx,axi-usb2-device-4.00.a";
> > +interrupt-parent = <0x1>;

Huh? Who writes a raw phandle value?

> > +interrupts = <0x0 0x39 0x1>;
> > +reg = <0x42e0 0x1>;
> > +xlnx,has-builtin-dma;

As mentioned above, this conflicts with the binding documentation.
Please ensure the example is aligned with the documentation.

Thanks,
Mark.
--
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: ath9k -> bogus usb xfer on at91

2014-07-04 Thread Oleksij Rempel
Am 04.07.2014 18:30, schrieb Alan Stern:
> On Fri, 4 Jul 2014, Anders Darander wrote:
> 
>> Hi,
>>
>> While porting an internal BSP (a design based on a at91sam9g20 SoC)
>> from 3.10 to 3.14, I got flooded with messages like:
>>
>> ~# usb 1-1: new full-speed USB device number 3 using at91_ohci
>> usb 1-1: ath9k_htc: Firmware htc_9271.fw requested
>> usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
>> ---[ cut here ]---
>> WARNING: CPU: 0 PID: 93 at
>> /mnt/cs-builds/anders/oe-build/build-ccu/tmp-eglibc/work/ccu-oe-linux-gnueabi/linux-yocto-ccu/3.14+gitAUTOINC+7b03bd3dfd-r0/linux/drivers/usb/core/urb.c:450
>> usb_submit_urb+0x2ac/0x460()
>> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>> Modules linked in: ath9k_htc ath9k_common ath9k_hw ath mac80211
>> cfg80211 ccudrv(O) at91_disable_wdt(O) at91_bootcount(O) at91_adc(O)
>> CPU: 0 PID: 93 Comm: kworker/0:3 Tainted: G W O 3.14.10-ccu #2
>> Workqueue: events request_firmware_work_func
>> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
>> [] (show_stack) from [] (warn_slowpath_common+0x60/0x80)
>> [] (warn_slowpath_common) from []
>> (warn_slowpath_fmt+0x2c/0x3c)
>> [] (warn_slowpath_fmt) from [] 
>> (usb_submit_urb+0x2ac/0x460)
>> [] (usb_submit_urb) from []
>> (hif_usb_send+0x268/0x2c8 [ath9k_htc])
>> [] (hif_usb_send [ath9k_htc]) from []
>> (htc_issue_send.constprop.4+0x64/0x68 [ath9k_htc])
>> [] (htc_issue_send.constprop.4 [ath9k_htc]) from
>> [] (htc_connect_service+0x170/0x1c8 [ath9k_htc])
>> [] (htc_connect_service [ath9k_htc]) from []
>> (ath9k_wmi_connect+0x50/0x6c [ath9k_htc])
>> [] (ath9k_wmi_connect [ath9k_htc]) from []
>> (ath9k_init_htc_services.isra.10+0x20/0x280 [ath9k_htc])
>> [] (ath9k_init_htc_services.isra.10 [ath9k_htc]) from
>> [] (ath9k_htc_probe_device+0xe4/0x928 [ath9k_htc])
>> [] (ath9k_htc_probe_device [ath9k_htc]) from []
>> (ath9k_htc_hw_init+0x10/0x30 [ath9k_htc])
>> [] (ath9k_htc_hw_init [ath9k_htc]) from []
>> (ath9k_hif_usb_firmware_cb+0x4cc/0x5c8 [ath9k_htc])
>> [] (ath9k_hif_usb_firmware_cb [ath9k_htc]) from []
>> (request_firmware_work_func+0x2c/0x4c)
>> [] (request_firmware_work_func) from []
>> (process_one_work+0x20c/0x33c)
>> [] (process_one_work) from [] (worker_thread+0x234/0x384)
>> [] (worker_thread) from [] (kthread+0xc0/0xd4)
>> [] (kthread) from [] (ret_from_fork+0x14/0x24)
>> --[ end trace b92d2c3cd165cd68 ]--
>> ---[ cut here ]---
> 
> I can't tell exactly where the fault is, but this message means that an
> URB was submitted for a bulk endpoint with a pipe of type
> PIPE_INTERRUPT.

Then kernel driver and firmware should be updated. There was some
Bulk/Interrupt issues which was fixed last year.

I hope this HW will not be used as AP.

>> After temporarily reverting commit
>> 3482528e9aced9234d4e2a4a9538c882a9aa5aa2, which enables debug checks
>> on all USB urb's (previously is was only enabled for a
>> CONFIG_USB_DEBUG enabled kernel), the WiFi chip starts to work
>> correctly. The chip in question is a ar9721.
>>
>>  The same USB stick works without these messages on my laptop; while
>> another USB stick, based on an rtl8187 chip, works without these
>> messages on the target system (at91sam9g20)
>>
>> Any pointers to what it could be? Or suggestions on how to attack the issue?
> 
> Fix the URB submission to use the correct pipe type.
> 
> Alan Stern
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature


[PATCH] mach-omap1: Fix call to omap_cfg_reg

2014-07-04 Thread Nicholas Krause
This patch fixes the call to ompa_cfg_reg(USB2_SPEED) in the case
that the cpu is a omap16xx and the nwires are not equal to 3.

Signed-off-by: Nicholas Krause 
---
 arch/arm/mach-omap1/usb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
index 4118db5..17e3139 100644
--- a/arch/arm/mach-omap1/usb.c
+++ b/arch/arm/mach-omap1/usb.c
@@ -504,8 +504,7 @@ static u32 __init omap1_usb2_init(unsigned nwires, unsigned 
alt_pingroup)
omap_cfg_reg(W9_USB2_TXEN);
omap_cfg_reg(W5_USB2_SE0);
if (nwires != 3)
-   omap_cfg_reg(Y5_USB2_RCV);
-   // FIXME omap_cfg_reg(USB2_SPEED);
+   omap_cfg_reg(USB2_SPEED)
} else {
pr_debug("usb%d cpu unrecognized\n", 1);
return 0;
-- 
1.9.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] drivers: phy: exynos-usb2: add support for Exynos 3250

2014-07-04 Thread Tomasz Figa
Hi Marek,

Please see my comments inline.

On 04.07.2014 14:13, Marek Szyprowski wrote:
> This patch adds support for Exynos3250 SoC to Exynos2USB PHY driver.
> Although Exynos3250 has only one device phy interface, the register
> layout and all operations that are required to get it enabled are almost
> same as on Exynos4x12. The only different is one more register
> (REFCLKSEL) which need to be set.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/phy/Kconfig   | 12 ++--
>  drivers/phy/phy-exynos4x12-usb2.c | 18 ++
>  drivers/phy/phy-samsung-usb2.c|  6 ++
>  drivers/phy/phy-samsung-usb2.h|  2 ++

This patch adds new compatible string, but there is no respective change
to the documentation. Please add it.

>  4 files changed, 32 insertions(+), 6 deletions(-)
> 

[snip]

> diff --git a/drivers/phy/phy-exynos4x12-usb2.c 
> b/drivers/phy/phy-exynos4x12-usb2.c
> index 59d8dd3ff390..b29bbfacd4b5 100644
> --- a/drivers/phy/phy-exynos4x12-usb2.c
> +++ b/drivers/phy/phy-exynos4x12-usb2.c
> @@ -67,6 +67,12 @@
>  #define EXYNOS_4x12_UPHYCLK_PHYFSEL_24MHZ(0x5 << 0)
>  #define EXYNOS_4x12_UPHYCLK_PHYFSEL_50MHZ(0x7 << 0)
>  
> +#define EXYNOS_4212_UPHYCLK_PHY0_ID_PULLUP   (0x1 << 3)
> +#define EXYNOS_4212_UPHYCLK_PHY0_COMMON_ON   (0x1 << 4)
> +#define EXYNOS_4212_UPHYCLK_PHY1_COMMON_ON   (0x1 << 7)

The 3 macros above don't seem to be used anywhere in this patch.

Best regards,
Tomasz
--
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] usb: hcd: add generic PHY support

2014-07-04 Thread Sergei Shtylyov

Hello.

On 06/25/2014 02:32 PM, Vivek Gautam wrote:


 From Sergei Shtylyov 



Add the generic PHY support, analogous to the USB PHY support. Intended it to be
used with the PCI EHCI/OHCI drivers and the xHCI platform driver.



Signed-off-by: Sergei Shtylyov 
Signed-off-by: Yoshihiro Shimoda 
---
This patch is against the 'usb-next' branch of Greg KH's 'usb.git' repo.
(commit id = 70d2f61fc7559df3d5be32a9d01efdb9ee1b11d8)



Changes in version 3:
  - rebased the current usb-next.
  - I tested this patch on my R-Car H2 USB 3.0 driver (not merged yet)



  drivers/usb/core/hcd.c  |   42 --
  include/linux/usb/hcd.h |3 ++-
  2 files changed, 42 insertions(+), 3 deletions(-)



diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index bec31e2..2841149 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c

[...]

@@ -2649,6 +2650,29 @@ int usb_add_hcd(struct usb_hcd *hcd,
 }
 }

+   if (IS_ENABLED(CONFIG_GENERIC_PHY)) {
+   struct phy *phy = phy_get(hcd->self.controller, "usb");



The xHCI host controller is going to have two controllers (main and
shared) USB2 controller and
USB3 controller. So they will have two different PHYs.


   Not necessarily -- in my case there's going be one PHY, even for xHCI.


For example, the DWC3, which has a xHCI controller, has to have 2
different phys -- usb2-phy and usb3-phy.


   Yes, I understood that.


So, how the two 'hcd's' will be able to differentiate and get two separate PHYs.


   Apparently, by name? I don't see any other way...


Unfortunately, the xHCI with DWC3 doesn't have a device node too, so
it needs to have
a way out to look up the PHYs (in a way suggested by Heikki :
 usb: dwc3: host: convey the PHYs to xhci
 (https://lkml.org/lkml/2014/6/5/585) and related patch series.
But this also has an issue, since we need to have two separate
constant strings to distinguish between the two PHYs,
while creating the lookup table.


   I'm sorry, where's the issue?


So how do you suggest me to get link the two PHYs in DWC3 with the
XHCI host controller, the issue which i am
facing currently while working with the patch:
usb: host: xhci-plat: Add support to get PHYsand the related patch
series, since we need to handle PHY from the hcd.


   Well, I've already spoke out in another thread: you'll have to carry on 
with your approach, ignoring the patch starting this thread. I'm sorry for 
side-tracking you...


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


[PATCH] Register NOP tranciever driver in JZ4740 musb glue layer

2014-07-04 Thread Apelete Seketeli
Hello,

The name of the NOP transceiver driver was changed during v3.16
release cycle from usb_phy_gen_xceiv to usb_phy_generic.

The patch that comes as a follow up of this message registers the NOP
transceiver driver before calling usb_get_phy() to avoid issues
related to accessing its data structure while it was not registered.

For notice, I updated corresponding platform data to rename NOP
transceiver used for JZ4740 in a patch sent today to linux-mips.

Changes were rebased on top of the linux-usb master branch, built and
tested successfully.

The following changes since commit 80235c4:

  Merge tag 'v3.16-rc2'

are available in the git repository at:

  git://git.seketeli.net/~apelete/linux-usb.git register-jz4740-phy

Apelete Seketeli (1):
  usb: musb: register nop transceiver driver for jz4740

 drivers/usb/musb/jz4740.c |3 +++
 1 file changed, 3 insertions(+)

-- 
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] usb: musb: register nop transceiver driver for jz4740

2014-07-04 Thread Apelete Seketeli
Following the name change of the nop transceiver driver in commit
4525bee, make sure to register the transceiver driver before calling
usb_get_phy() to avoid issues related to accessing its data structure
while it was not registered.

Signed-off-by: Apelete Seketeli 
---
 drivers/usb/musb/jz4740.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/musb/jz4740.c b/drivers/usb/musb/jz4740.c
index 5f30537..d118729 100644
--- a/drivers/usb/musb/jz4740.c
+++ b/drivers/usb/musb/jz4740.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "musb_core.h"
 
@@ -80,6 +81,7 @@ static struct musb_hdrc_platform_data 
jz4740_musb_platform_data = {
 
 static int jz4740_musb_init(struct musb *musb)
 {
+   usb_phy_generic_register();
musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (!musb->xceiv) {
pr_err("HS UDC: no transceiver configured\n");
@@ -182,6 +184,7 @@ static int jz4740_remove(struct platform_device *pdev)
struct jz4740_glue  *glue = platform_get_drvdata(pdev);
 
platform_device_unregister(glue->musb);
+   usb_phy_generic_unregister(pdev);
clk_disable_unprepare(glue->clk);
 
return 0;
-- 
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 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC

2014-07-04 Thread Peter Griffin
Hi Daniele,

Thankyou for reviewing.

> > +config USB_DWC3_ST
> > +   tristate "STMicroelectronics Platforms"
> > +   depends on ARCH_STI && OF
> > +   default USB_DWC3_HOST
> > +   help
> > + STMicroelectronics SoCs chip with one DesignWare Core USB3 IP
> > + inside (i.e. STiH407).
> > +
> >   Say 'Y' or 'M' here if you have one such device
> >
> >  comment "Debugging features"
> 
> you are actually removing the line "Say 'Y' or 'M' here if you have
> one such device" from the previous item

Whoops, good spot. I've fixed in V2, and added the same sentence for this
new entry as well.

I've also replaced "STMicroelectronics SoCs chip with one DesignWare Core"
with "STMicroelectronics SoCs with one DesignWare Core".

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


Re: [PATCH 2/3] ARM: dts: sti: Add st-dwc3 devicetree bindings documentation

2014-07-04 Thread Peter Griffin
Hi Daniele,

Thanks for reviewing.

On Fri, 04 Jul 2014, Daniele Forsi wrote:
> 2014-07-04 13:13 GMT+02:00 Peter Griffin:
> 
> > +Required properties:
> > + - compatible  : must be "st,stih407-dwc3"
> > + - reg : glue logic base address and USB syscfg ctrl register 
> > offest
> > + - reg-names   : Should be "reg-glue" and "syscfg-reg".
> > + - st,syscon: should be phandle to system configuration node which
> > + encompases the glue registers.
> > + - resets   : phandle pointing to the system powerdown controller
> 
> minor knits:
> s/offest/offset/
> s/encompases/encompasses/
> "Should" is upper case while all other lines in this block start with
> a lower case letter;
> two lines end with a full stop, three lines without;
> colons the last lines do not align to the first three

All fixed in V2.

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


[PATCH v2 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture

2014-07-04 Thread Peter Griffin
Signed-off-by: Peter Griffin 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 702ca10..269ad3b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1325,6 +1325,7 @@ F:drivers/pinctrl/pinctrl-st.c
 F: drivers/media/rc/st_rc.c
 F: drivers/i2c/busses/i2c-st.c
 F: drivers/tty/serial/st-asc.c
+F: drivers/usb/dwc3/dwc3-st.c
 
 ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT
 M: Lennert Buytenhek 
-- 
1.9.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 v2 2/3] ARM: dts: sti: Add st-dwc3 devicetree bindings documentation

2014-07-04 Thread Peter Griffin
This patch documents the device tree documentation required for
the ST usb3 controller glue layer found in STiH407 devices.

Signed-off-by: Giuseppe Cavallaro 
Signed-off-by: Peter Griffin 
---
 Documentation/devicetree/bindings/usb/dwc3-st.txt | 58 +++
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt

diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt 
b/Documentation/devicetree/bindings/usb/dwc3-st.txt
new file mode 100644
index 000..befd964
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
@@ -0,0 +1,58 @@
+ST DWC3 glue logic
+
+This file documents the parameters for the dwc3-st driver.
+This driver provides the glue logic to use the dwc3 on STiH407 based platforms.
+
+Required properties:
+ - compatible  : must be "st,stih407-dwc3"
+ - reg : glue logic base address and USB syscfg ctrl register offset
+ - reg-names   : should be "reg-glue" and "syscfg-reg"
+ - st,syscon   : should be phandle to system configuration node which
+ encompasses the glue registers
+ - resets  : phandle pointing to the system powerdown controller
+See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
+See: Documentation/devicetree/bindings/reset/reset.txt
+
+ - #address-cells, #size-cells : should be '1' if the device has sub-nodes
+ with 'reg' property
+
+ - pinctl-names: A pinctrl state named "default" must be defined
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - pinctrl-0   : Pin control group
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - ranges  : allows valid 1:1 translation between child's address space and
+ parent's address space
+
+Optional properties:
+ - st,dwc3-drd-device: to program the HC as "device" (static setup)
+
+Sub-nodes:
+The dwc3 core should be added as subnode to ST DWC3 glue as shown in the
+example below. The DT binding details of dwc3 can be found in:
+Documentation/devicetree/bindings/usb/dwc3.txt
+
+Example:
+
+st_dwc3: dwc3@8f94000 {
+   status  = "disabled";
+   compatible  = "st,stih407-dwc3";
+   reg = <0x08f94000 0x1000>, <0x110 0x4>;
+   reg-names   = "reg-glue", "syscfg-reg";
+   st,syscfg   = <&syscfg_core>;
+   resets  = <&powerdown STIH407_USB3_POWERDOWN>;
+   #address-cells  = <1>;
+   #size-cells = <1>;
+   pinctrl-names   = "default";
+   pinctrl-0   = <&pinctrl_usb3>;
+   ranges;
+
+   dwc3: dwc3@990 {
+   compatible  = "synopsys,dwc3";
+   reg = <0x0990 0x10>;
+   interrupts  =  ;
+
+   usb-phy = <&usb2_phy>, <&usb3_phy>;
+   };
+};
-- 
1.9.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 v2 0/3] Add ST dwc3 glue layer driver.

2014-07-04 Thread Peter Griffin
This series adds support for the ST glue logic to manage the DWC3 HC
on STiH407 SoC family chipsets.

Peter Griffin (3):
  usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
  ARM: dts: sti: Add st-dwc3 devicetree bindings documentation
  MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture

 Documentation/devicetree/bindings/usb/dwc3-st.txt |  58 
 MAINTAINERS   |   1 +
 drivers/usb/dwc3/Kconfig  |   9 +
 drivers/usb/dwc3/Makefile |   1 +
 drivers/usb/dwc3/dwc3-st.c| 325 ++
 5 files changed, 394 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt
 create mode 100644 drivers/usb/dwc3/dwc3-st.c

-- 
1.9.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 v2 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC

2014-07-04 Thread Peter Griffin
This patch adds the ST glue logic to manage the DWC3 HC
on STiH407 SoC family. It manages the powerdown signal,
and configures the internal glue logic and syscfg registers.

Signed-off-by: Giuseppe Cavallaro 
Signed-off-by: Peter Griffin 
---
 drivers/usb/dwc3/Kconfig   |   9 ++
 drivers/usb/dwc3/Makefile  |   1 +
 drivers/usb/dwc3/dwc3-st.c | 325 +
 3 files changed, 335 insertions(+)
 create mode 100644 drivers/usb/dwc3/dwc3-st.c

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 8eb996e..6c85c43 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -79,6 +79,15 @@ config USB_DWC3_KEYSTONE
  Support of USB2/3 functionality in TI Keystone2 platforms.
  Say 'Y' or 'M' here if you have one such device
 
+config USB_DWC3_ST
+   tristate "STMicroelectronics Platforms"
+   depends on ARCH_STI && OF
+   default USB_DWC3_HOST
+   help
+ STMicroelectronics SoCs with one DesignWare Core USB3 IP
+ inside (i.e. STiH407).
+ Say 'Y' or 'M' if you have one such device.
+
 comment "Debugging features"
 
 config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 10ac3e7..11c9f54 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_USB_DWC3_OMAP)   += dwc3-omap.o
 obj-$(CONFIG_USB_DWC3_EXYNOS)  += dwc3-exynos.o
 obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
 obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
+obj-$(CONFIG_USB_DWC3_ST)  += dwc3-st.o
diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
new file mode 100644
index 000..2cae9d3
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-st.c
@@ -0,0 +1,325 @@
+/**
+ * dwc3-st.c Support for dwc3 platform devices on ST Microelectronics platforms
+ *
+ * This is a small platform driver for the dwc3 to provide the glue logic
+ * to configure the controller. Tested on STi platforms.
+ *
+ * Copyright (C) 2014 Stmicroelectronics
+ *
+ * Author: Giuseppe Cavallaro 
+ * Contributors: Aymen Bouattay 
+ *   Peter Griffin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Inspired by dwc3-omap.c and dwc3-exynos.c.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "io.h"
+
+/* Reg glue registers */
+#define USB2_CLKRST_CTRL 0x00
+#define aux_clk_en(n) ((n)<<0)
+#define sw_pipew_reset_n(n) ((n)<<4)
+#define ext_cfg_reset_n(n) ((n)<<8)
+#define xhci_revision(n) ((n)<<12)
+
+#define USB2_VBUS_MNGMNT_SEL1 0x2C
+/*
+ * 2'b00 : Override value from Reg 0x30 is selected
+ * 2'b01 : utmiotg_vbusvalid from usb3_top top is selected
+ * 2'b10 : pipew_powerpresent from PIPEW instance is selected
+ * 2'b11 : value is 1'b0
+ */
+#define SEL_OVERRIDE_VBUSVALID(n) ((n)<<0)
+#define SEL_OVERRIDE_POWERPRESENT(n) ((n)<<4)
+#define SEL_OVERRIDE_BVALID(n) ((n)<<8)
+
+#define USB2_VBUS_MNGMNT_VAL1 0x30
+#define OVERRIDE_VBUSVALID_VAL (1 << 0)
+#define OVERRIDE_POWERPRESENT_VAL (1 << 4)
+#define OVERRIDE_BVALID_VAL (1 << 8)
+
+/* Static DRD configuration */
+#define USB_HOST_DEFAULT_MASK  0xffe
+#define USB_SET_PORT_DEVICE0x1
+
+struct st_dwc3 {
+   struct platform_device *dwc3;   /* platform device pointer */
+   struct device *dev; /* device pointer */
+   void __iomem *glue_base;/* ioaddr for programming the glue */
+   struct regmap *regmap;  /* regmap for getting syscfg */
+   int syscfg_reg_off; /* usb syscfg control offset */
+   bool drd_device_conf;   /* DRD static host/device conf */
+   struct reset_control *rstc_pwrdn;/* Rst control for powerdown*/
+};
+
+static inline u32 st_dwc3_readl(void __iomem *base, u32 offset)
+{
+   return readl_relaxed(base + offset);
+}
+
+static inline void st_dwc3_writel(void __iomem *base, u32 offset, u32 value)
+{
+   writel_relaxed(value, base + offset);
+}
+
+/**
+ * st_dwc3_drd_init: program the port
+ * @dwc3_data: driver private structure
+ * Description: this function is to program the port as either host or device
+ * according to the static configuration passed from devicetree.
+ * OTG and dual role are not yet supported!
+ */
+static int st_dwc3_drd_init(struct st_dwc3 *dwc3_data)
+{
+   u32 val;
+
+   regmap_read(dwc3_data->regmap, dwc3_data->syscfg_reg_off, &val);
+
+   if (dwc3_data->drd_device_conf)
+   val |= USB_SET_PORT_DEVICE;
+   else
+   val &= USB_HOST_DEFAULT_MASK;
+
+   return regmap_write(dwc3_data->regmap, dwc3_data->syscfg_reg_off, val);
+}
+
+/**
+ * st_dwc3_init: init the controller via glue logic
+ * @