Re: [PATCH 2/2] gadget: Support for the usb charger framework

[Baolin Wang]

On 8 August 2015 at 01:53, Greg KH  wrote:
> On Fri, Aug 07, 2015 at 05:22:47PM +0800, Baolin Wang wrote:
>> On 7 August 2015 at 17:07, Peter Chen  wrote:
>> >
>> >> >>  /**
>> >> >>   * struct usb_udc - describes one usb device controller @@ -127,12
>> >> >> +128,45 @@ void usb_gadget_giveback_request(struct usb_ep *ep,  }
>> >> >> EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
>> >> >>
>> >> >> +int usb_gadget_register_notify(struct usb_gadget *gadget,
>> >> >> +struct notifier_block *nb) {
>> >> >> + unsigned long flags;
>> >> >> + int ret;
>> >> >> +
>> >> >> + spin_lock_irqsave(&gadget->lock, flags);
>> >> >
>> >> > I find you use so many spin_lock_irqsave, any reasons for that?
>> >> > Why mutex_lock can't be used?
>> >> >
>> >>
>> >> The spin_lock_irqsave() can make it as a atomic notifier, that can make 
>> >> sure the
>> >> gadget state event can be quickly reported to the user who register a 
>> >> notifier
>> >> on the gadget device. Is it OK?
>> >>
>> >
>> > I don't think it is a good reason, spin_lock_irqsave is usually used for 
>> > protecting
>> > data which is accessed at atomic environment.
>> >
>>
>> Yes, we want the notify process is a atomic environment which do not
>> want to be interrupted by irq or other things to make the notice can
>> be quickly reported to the user.
>
> No, this is a "slow" event, you don't need to notify anyone under atomic
> context, that's crazy.
>
>> Also i think the notify process is less cost, thus i use the spinlock. 
>> Thanks.
>
> No, use a mutex please, that's the safe thing.  This is not
> time-critical code at all.
>

OK, Thanks for your comments and will fix the lock thing.

> thanks,
>
> greg k-h



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

Re: [PATCH 0/2] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

On 8 August 2015 at 01:52, Greg KH  wrote:
> On Fri, Aug 07, 2015 at 04:19:40PM +0800, Baolin Wang wrote:
>> On 7 August 2015 at 13:34, Peter Chen  wrote:
>> > On Thu, Aug 06, 2015 at 03:03:47PM +0800, Baolin Wang wrote:
>> >> Currently the Linux kernel does not provide any standard integration of 
>> >> this
>> >> feature that integrates the USB subsystem with the system power regulation
>> >> provided by PMICs meaning that either vendors must add this in their 
>> >> kernels
>> >> or USB gadget devices based on Linux (such as mobile phones) may not 
>> >> behave
>> >> as they should.
>> >>
>> >> Providing a standard framework for doing this in the kernel.
>> >
>> > Baolin, thanks for introducing a framework for doing it, we do support
>> > USB Charger for chipidea driver at internal tree, but it is specific
>> > for imx, and still have some problems to upstream due to need to
>> > change some common code.
>> >
>> > One suggestion, would you add your user next time? In that case, we can
>> > know better for this framework.
>> >
>>
>> Peter, Thanks for your reviewing and comments. Now I just introduce
>> the framework to review for more feedbacks and do not have a useful
>> user to use it. I just can show you some example code to show how to
>> use it. Thanks.
>
> Without a real, in-tree user, I can not accept this code.  We don't add
> "frameworks" for non-existant things, otherwise it will be instantly
> ripped out the next kernel release.
>
> Please come up with at least 2 users, ideally 3, otherwise there's no
> real way to know if the framework is sufficient.
>

OK, I'll try to come up with 2 or 3 users. Thanks.

> thanks,
>
> greg k-h



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

Re: [PATCH v4 2/2] usb: Add support for ACPI identification to xhci-platform

[Javier Martinez Canillas]

Hello Greg,

On Sat, Aug 8, 2015 at 3:29 AM, Greg KH  wrote:
> On Fri, Aug 07, 2015 at 06:03:36PM -0700, Duc Dang wrote:
>> Provide the methods to let ACPI identify the need to use
>> xhci-platform. Change the Kconfig files so the
>> xhci-plat.o file is selectable during kernel config.
>>
>> This has been tested on an ARM64 machine with platform XHCI, an
>> x86_64 machine with XHCI, and an x86_64 machine without XHCI.
>> There were no regressions or error messages on the machines
>> without platform XHCI.
>>
>> [dhdang: regenerate the patch over 4.2-rc5]
>> Signed-off-by: Mark Langsdorf 
>> Signed-off-by: Duc Dang 
>>
>> ---
>> Changes from v3:
>>   Regenerate the patch over 4.2-rc5
>>   No code change
>>
>> Changes from v2
>>   Replaced tristate with a boolean as the driver doesn't
>>   compile as a module
>>   Correct --help-- to ---help---
>>
>> Changes from v1
>>   Renamed from "add support for APM X-Gene to xhci-platform"
>>   Removed changes to arm64/Kconfig
>>   Made CONFIG_USB_XHCI_PLATFORM a user selectable config option
>>
>>  drivers/usb/host/Kconfig |  7 ++-
>>  drivers/usb/host/xhci-plat.c | 11 +++
>>  2 files changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>> index 8afc3c1..96231ee 100644
>> --- a/drivers/usb/host/Kconfig
>> +++ b/drivers/usb/host/Kconfig
>> @@ -32,7 +32,12 @@ config USB_XHCI_PCI
>> default y
>>
>>  config USB_XHCI_PLATFORM
>> - tristate
>> + tristate "xHCI platform driver support"
>> + ---help---
>> +   Say 'Y' to enable the support for the xHCI host controller
>> +   as a platform device. Many ARM SoCs provide USB this way.
>> +
>> +   If unsure, say 'Y'.
>>
>>  config USB_XHCI_MVEBU
>>   tristate "xHCI support for Marvell Armada 375/38x"
>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>> index 5d03f8b..14b40d2 100644
>> --- a/drivers/usb/host/xhci-plat.c
>> +++ b/drivers/usb/host/xhci-plat.c
>> @@ -19,6 +19,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include "xhci.h"
>>  #include "xhci-mvebu.h"
>> @@ -262,6 +263,15 @@ static const struct of_device_id usb_xhci_of_match[] = {
>>  MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
>>  #endif
>>
>> +#ifdef CONFIG_ACPI
>
> You shoudn't need this #ifdef, right?
>

Why it is not needed?

The driver does .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match) and
ACPI_PTR() is NULL if CONFIG_ACPI is not enabled. Which can happen
AFAIU since the driver also supports OF. So without the #ifdef guards,
.acpi_match_table = NULL and the struct acpi_device_id
usb_xhci_acpi_match[] will be built but not used.

Or am I missing something?

> thanks,
>
> greg k-h
>

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

[PATCH v5 2/2] usb: Add support for ACPI identification to xhci-platform

[Duc Dang]

Provide the methods to let ACPI identify the need to use
xhci-platform. Change the Kconfig files so the
xhci-plat.o file is selectable during kernel config.

This has been tested on an ARM64 machine with platform XHCI, an
x86_64 machine with XHCI, and an x86_64 machine without XHCI.
There were no regressions or error messages on the machines
without platform XHCI.

Signed-off-by: Mark Langsdorf 
Signed-off-by: Duc Dang 

---
Changes from v4:
Remove #ifdef CONFIG_ACPI

Changes from v3:
Regenerate the patch over 4.2-rc5
No code change

Changes from v2
Replaced tristate with a boolean as the driver doesn't
compile as a module
Correct --help-- to ---help---

Changes from v1
Renamed from "add support for APM X-Gene to xhci-platform"
Removed changes to arm64/Kconfig
Made CONFIG_USB_XHCI_PLATFORM a user selectable config option

 drivers/usb/host/Kconfig | 7 ++-
 drivers/usb/host/xhci-plat.c | 9 +
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8afc3c1..96231ee 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -32,7 +32,12 @@ config USB_XHCI_PCI
default y
 
 config USB_XHCI_PLATFORM
-   tristate
+   tristate "xHCI platform driver support"
+   ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ as a platform device. Many ARM SoCs provide USB this way.
+
+ If unsure, say 'Y'.
 
 config USB_XHCI_MVEBU
tristate "xHCI support for Marvell Armada 375/38x"
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 5d03f8b..bd282cd 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xhci.h"
 #include "xhci-mvebu.h"
@@ -262,6 +263,13 @@ static const struct of_device_id usb_xhci_of_match[] = {
 MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
 #endif
 
+static const struct acpi_device_id usb_xhci_acpi_match[] = {
+   /* APM X-Gene USB Controller */
+   { "PNP0D10", },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, usb_xhci_acpi_match);
+
 static struct platform_driver usb_xhci_driver = {
.probe  = xhci_plat_probe,
.remove = xhci_plat_remove,
@@ -269,6 +277,7 @@ static struct platform_driver usb_xhci_driver = {
.name = "xhci-hcd",
.pm = DEV_PM_OPS,
.of_match_table = of_match_ptr(usb_xhci_of_match),
+   .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
},
 };
 MODULE_ALIAS("platform:xhci-hcd");
-- 
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 v5 1/2] usb: make xhci platform driver use 64 bit or 32 bit DMA

[Duc Dang]

The xhci platform driver needs to work on systems that
either only support 64-bit DMA or only support 32-bit DMA.
Attempt to set a coherent dma mask for 64-bit DMA, and
attempt again with 32-bit DMA if that fails.

[dhdang: Regenerate the patch over 4.2-rc5]
Signed-off-by: Mark Langsdorf 
Tested-by: Mark Salter 
Signed-off-by: Duc Dang 

---
Changes from v4:
None

Changes from v3:
Re-generate the patch over 4.2-rc5
No code change.

Changes from v2:
None

Changes from v1:
Consolidated to use dma_set_mask_and_coherent
Got rid of the check against sizeof(dma_addr_t)

 drivers/usb/host/xhci-plat.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 890ad9d..5d03f8b 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -93,14 +93,14 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (irq < 0)
return -ENODEV;
 
-   /* Initialize dma_mask and coherent_dma_mask to 32-bits */
-   ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
-   if (ret)
-   return ret;
-   if (!pdev->dev.dma_mask)
-   pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
-   else
-   dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+   /* Try setting the coherent_dma_mask to 64 bits, then try 32 bits */
+   ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
+   if (ret) {
+   ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+   if (ret)
+   return ret;
+   }
+
 
hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
if (!hcd)
-- 
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 v4 2/2] usb: Add support for ACPI identification to xhci-platform

[Duc Dang]

On Fri, Aug 7, 2015 at 6:29 PM, Greg KH  wrote:
> On Fri, Aug 07, 2015 at 06:03:36PM -0700, Duc Dang wrote:
>> Provide the methods to let ACPI identify the need to use
>> xhci-platform. Change the Kconfig files so the
>> xhci-plat.o file is selectable during kernel config.
>>
>> This has been tested on an ARM64 machine with platform XHCI, an
>> x86_64 machine with XHCI, and an x86_64 machine without XHCI.
>> There were no regressions or error messages on the machines
>> without platform XHCI.
>>
>> [dhdang: regenerate the patch over 4.2-rc5]
>> Signed-off-by: Mark Langsdorf 
>> Signed-off-by: Duc Dang 
>>
>> ---
>> Changes from v3:
>>   Regenerate the patch over 4.2-rc5
>>   No code change
>>
>> Changes from v2
>>   Replaced tristate with a boolean as the driver doesn't
>>   compile as a module
>>   Correct --help-- to ---help---
>>
>> Changes from v1
>>   Renamed from "add support for APM X-Gene to xhci-platform"
>>   Removed changes to arm64/Kconfig
>>   Made CONFIG_USB_XHCI_PLATFORM a user selectable config option
>>
>>  drivers/usb/host/Kconfig |  7 ++-
>>  drivers/usb/host/xhci-plat.c | 11 +++
>>  2 files changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>> index 8afc3c1..96231ee 100644
>> --- a/drivers/usb/host/Kconfig
>> +++ b/drivers/usb/host/Kconfig
>> @@ -32,7 +32,12 @@ config USB_XHCI_PCI
>> default y
>>
>>  config USB_XHCI_PLATFORM
>> - tristate
>> + tristate "xHCI platform driver support"
>> + ---help---
>> +   Say 'Y' to enable the support for the xHCI host controller
>> +   as a platform device. Many ARM SoCs provide USB this way.
>> +
>> +   If unsure, say 'Y'.
>>
>>  config USB_XHCI_MVEBU
>>   tristate "xHCI support for Marvell Armada 375/38x"
>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>> index 5d03f8b..14b40d2 100644
>> --- a/drivers/usb/host/xhci-plat.c
>> +++ b/drivers/usb/host/xhci-plat.c
>> @@ -19,6 +19,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include "xhci.h"
>>  #include "xhci-mvebu.h"
>> @@ -262,6 +263,15 @@ static const struct of_device_id usb_xhci_of_match[] = {
>>  MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
>>  #endif
>>
>> +#ifdef CONFIG_ACPI
>
> You shoudn't need this #ifdef, right?

You are correct, Greg.

I will post a new version that remove this #ifdef CONFIG_ACPI shortly

>
> thanks,
>
> greg k-h



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

Re: [PATCH v4 2/2] usb: Add support for ACPI identification to xhci-platform

[Greg KH]

On Fri, Aug 07, 2015 at 06:03:36PM -0700, Duc Dang wrote:
> Provide the methods to let ACPI identify the need to use
> xhci-platform. Change the Kconfig files so the
> xhci-plat.o file is selectable during kernel config.
> 
> This has been tested on an ARM64 machine with platform XHCI, an
> x86_64 machine with XHCI, and an x86_64 machine without XHCI.
> There were no regressions or error messages on the machines
> without platform XHCI.
> 
> [dhdang: regenerate the patch over 4.2-rc5]
> Signed-off-by: Mark Langsdorf 
> Signed-off-by: Duc Dang 
> 
> ---
> Changes from v3:
>   Regenerate the patch over 4.2-rc5
>   No code change
> 
> Changes from v2
>   Replaced tristate with a boolean as the driver doesn't
>   compile as a module
>   Correct --help-- to ---help---
> 
> Changes from v1
>   Renamed from "add support for APM X-Gene to xhci-platform"
>   Removed changes to arm64/Kconfig
>   Made CONFIG_USB_XHCI_PLATFORM a user selectable config option
> 
>  drivers/usb/host/Kconfig |  7 ++-
>  drivers/usb/host/xhci-plat.c | 11 +++
>  2 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 8afc3c1..96231ee 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -32,7 +32,12 @@ config USB_XHCI_PCI
> default y
>  
>  config USB_XHCI_PLATFORM
> - tristate
> + tristate "xHCI platform driver support"
> + ---help---
> +   Say 'Y' to enable the support for the xHCI host controller
> +   as a platform device. Many ARM SoCs provide USB this way.
> +
> +   If unsure, say 'Y'.
>  
>  config USB_XHCI_MVEBU
>   tristate "xHCI support for Marvell Armada 375/38x"
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 5d03f8b..14b40d2 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "xhci.h"
>  #include "xhci-mvebu.h"
> @@ -262,6 +263,15 @@ static const struct of_device_id usb_xhci_of_match[] = {
>  MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
>  #endif
>  
> +#ifdef CONFIG_ACPI

You shoudn't need this #ifdef, right?

thanks,

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

[PATCH v4 2/2] usb: Add support for ACPI identification to xhci-platform

[Duc Dang]

Provide the methods to let ACPI identify the need to use
xhci-platform. Change the Kconfig files so the
xhci-plat.o file is selectable during kernel config.

This has been tested on an ARM64 machine with platform XHCI, an
x86_64 machine with XHCI, and an x86_64 machine without XHCI.
There were no regressions or error messages on the machines
without platform XHCI.

[dhdang: regenerate the patch over 4.2-rc5]
Signed-off-by: Mark Langsdorf 
Signed-off-by: Duc Dang 

---
Changes from v3:
Regenerate the patch over 4.2-rc5
No code change

Changes from v2
Replaced tristate with a boolean as the driver doesn't
compile as a module
Correct --help-- to ---help---

Changes from v1
Renamed from "add support for APM X-Gene to xhci-platform"
Removed changes to arm64/Kconfig
Made CONFIG_USB_XHCI_PLATFORM a user selectable config option

 drivers/usb/host/Kconfig |  7 ++-
 drivers/usb/host/xhci-plat.c | 11 +++
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8afc3c1..96231ee 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -32,7 +32,12 @@ config USB_XHCI_PCI
default y
 
 config USB_XHCI_PLATFORM
-   tristate
+   tristate "xHCI platform driver support"
+   ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ as a platform device. Many ARM SoCs provide USB this way.
+
+ If unsure, say 'Y'.
 
 config USB_XHCI_MVEBU
tristate "xHCI support for Marvell Armada 375/38x"
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 5d03f8b..14b40d2 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xhci.h"
 #include "xhci-mvebu.h"
@@ -262,6 +263,15 @@ static const struct of_device_id usb_xhci_of_match[] = {
 MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
 #endif
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id usb_xhci_acpi_match[] = {
+   /* APM X-Gene USB Controller */
+   { "PNP0D10", },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, usb_xhci_acpi_match);
+#endif
+
 static struct platform_driver usb_xhci_driver = {
.probe  = xhci_plat_probe,
.remove = xhci_plat_remove,
@@ -269,6 +279,7 @@ static struct platform_driver usb_xhci_driver = {
.name = "xhci-hcd",
.pm = DEV_PM_OPS,
.of_match_table = of_match_ptr(usb_xhci_of_match),
+   .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
},
 };
 MODULE_ALIAS("platform:xhci-hcd");
-- 
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 v4 1/2] usb: make xhci platform driver use 64 bit or 32 bit DMA

[Duc Dang]

The xhci platform driver needs to work on systems that
either only support 64-bit DMA or only support 32-bit DMA. 
Attempt to set a coherent dma mask for 64-bit DMA, and 
attempt again with 32-bit DMA if that fails.

[dhdang: regenerate the patch over 4.2-rc5]
Signed-off-by: Mark Langsdorf 
Tested-by: Mark Salter 
Signed-off-by: Duc Dang 

---
Changes from v3:
Re-generate the patch over 4.2-rc5
No code change.

Changes from v2:
None

Changes from v1:
Consolidated to use dma_set_mask_and_coherent
Got rid of the check against sizeof(dma_addr_t)

 drivers/usb/host/xhci-plat.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 890ad9d..5d03f8b 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -93,14 +93,14 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (irq < 0)
return -ENODEV;
 
-   /* Initialize dma_mask and coherent_dma_mask to 32-bits */
-   ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
-   if (ret)
-   return ret;
-   if (!pdev->dev.dma_mask)
-   pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
-   else
-   dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+   /* Try setting the coherent_dma_mask to 64 bits, then try 32 bits */
+   ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
+   if (ret) {
+   ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+   if (ret)
+   return ret;
+   }
+
 
hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
if (!hcd)
-- 
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 v3 1/2] make xhci platform driver use 64 bit or 32 bit DMA

[Duc Dang]

Hi Greg,

On Wed, Jul 29, 2015 at 10:18 PM, Loc Ho  wrote:
> Hi,
>
>>> >> The xhci platform driver needs to work on systems that either only
>>> >> support 64-bit DMA or only support 32-bit DMA. Attempt to set a
>>> >> coherent dma mask for 64-bit DMA, and attempt again with 32-bit
>>> >> DMA if that fails.
>>> >>
>>> >> Signed-off-by: Mark Langsdorf 
>>> >> Tested-by: Mark Salter 
>>> >> ---
>>> >> Changes from v2:
>>> >> None
>>> >> Changes from v1:
>>> >> Consolidated to use dma_set_mask_and_coherent
>>> >> Got rid of the check against sizeof(dma_addr_t)
>>> >>
>>> >>  drivers/usb/host/xhci-plat.c | 16 
>>> >>  1 file changed, 8 insertions(+), 8 deletions(-)
>>>
>>> Any reason why this isn't pulled in already? It is already 6 months
>>> and seems to be ack'ed already.
>>
>> Does it work for you on 4.2-rc4?  Is it still needed?
>>
>> Care to repost the whole patch updated?

I tested this v3 patch set with 4.2-rc5 and it works fine on my X-Gene
arm64 platform.

The only problem is 'git am' will complain (due to line offset
changed, I guess). Using 'patch -p 1' to apply the 2 patches is fine.

I will repost the whole set over 4.2-rc5.

>
> Let me apply and see if it still work as is.
>
> -Loc

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

[GIT PULL] USB driver fixes for 4.2-rc6

[Greg KH]

The following changes since commit cbfe8fa6cd672011c755c3cd85c9ffd4e2d10a6f:

  Linux 4.2-rc4 (2015-07-26 12:26:21 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.2-rc6

for you to fetch changes up to 0a1b6f63198f6e51d12c8d8c4ed4e7d759b3b73d:

  Merge tag 'phy-for-4.2-rc6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-linus 
(2015-08-05 10:12:23 -0700)


USB fixes for 4.2-rc6

Here are some USB and PHY fixes for 4.2-rc6 that resolve some reported
issues.

All of these have been in the linux-next tree for a while, full details
on the patches are in the shortlog below.

Signed-off-by: Greg Kroah-Hartman 


Al Cooper (1):
  usb: gadget: bdc: fix a driver crash on disconnect

Alan Stern (1):
  usb: udc: core: add device_del() call to error pathway

Andrzej Pietrasiewicz (2):
  usb: gadget: f_hid: actually limit the number of instances
  usb: gadget: f_printer: actually limit the number of instances

Dirk Behme (1):
  USB: sierra: add 1199:68AB device ID

Gavin Shan (1):
  drivers/usb: Delete XHCI command timer if necessary

Greg Kroah-Hartman (5):
  Merge tag 'usb-ci-v4.2-rc5' of git://git.kernel.org/.../peter.chen/usb 
into usb-linus
  Merge tag 'fixes-for-v4.2-rc5' of git://git.kernel.org/.../balbi/usb into 
usb-linus
  Merge tag 'usb-serial-4.2-rc5' of 
git://git.kernel.org/.../johan/usb-serial into usb-linus
  Merge tag 'fixes-for-v4.2-rc6' of git://git.kernel.org/.../balbi/usb into 
usb-linus
  Merge tag 'phy-for-4.2-rc6' of git://git.kernel.org/.../kishon/linux-phy 
into usb-linus

Hans de Goede (1):
  phy-sun4i-usb: Add missing EXPORT_SYMBOL_GPL for 
sun4i_usb_phy_set_squelch_detect

Mathias Nyman (1):
  xhci: fix off by one error in TRB DMA address boundary check

Peter Chen (2):
  usb: chipidea: ehci_init_driver is intended to call one time
  usb: gadget: f_uac2: fix calculation of uac2->p_interval

Pieter Hollants (1):
  USB: qcserial: Add support for Dell Wireless 5809e 4G Modem

Reinhard Speyerer (1):
  USB: qcserial/option: make AT URCs work for Sierra Wireless MC7305/MC7355

Roger Quadros (2):
  phy: ti-pipe3: i783 workaround for SATA lockup after dpll unlock/relock
  ARM: dts: dra7: Add syscon-pllreset syscon to SATA PHY

 Documentation/devicetree/bindings/phy/ti-phy.txt | 16 +++
 arch/arm/boot/dts/dra7.dtsi  |  1 +
 drivers/phy/phy-sun4i-usb.c  |  1 +
 drivers/phy/phy-ti-pipe3.c   | 61 +---
 drivers/usb/chipidea/core.c  | 13 -
 drivers/usb/chipidea/host.c  |  7 ++-
 drivers/usb/chipidea/host.h  |  6 +++
 drivers/usb/gadget/function/f_hid.c  |  4 ++
 drivers/usb/gadget/function/f_printer.c  | 10 +++-
 drivers/usb/gadget/function/f_uac2.c |  4 +-
 drivers/usb/gadget/udc/bdc/bdc_ep.c  |  2 +-
 drivers/usb/gadget/udc/udc-core.c|  1 +
 drivers/usb/host/xhci-mem.c  |  3 +-
 drivers/usb/host/xhci-ring.c |  2 +-
 drivers/usb/serial/option.c  |  2 +
 drivers/usb/serial/qcserial.c|  2 +-
 drivers/usb/serial/sierra.c  |  1 +
 17 files changed, 120 insertions(+), 16 deletions(-)
--
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: [ANNOUNCE] tree closed for v4.3 merge window

[Tim Bird]

On Thu, Aug 6, 2015 at 9:40 AM, Felipe Balbi  wrote:
> Hi folks,
>
> if your patches aren't in my tree yet, it's too late, sorry.
>
> We have a total of 145 non-merge commits, here's dirstat:
>
> $ git diff --dirstat next ^cbfe8fa6cd67 | sort -rn
>   21.0% drivers/usb/gadget/udc/
>   19.9% drivers/usb/musb/
>   12.9% drivers/usb/phy/
>   11.7% drivers/usb/gadget/legacy/
>7.8% drivers/usb/gadget/
>6.1% drivers/usb/gadget/function/
>5.7% drivers/usb/dwc3/
>5.0% include/linux/usb/
>4.0% drivers/usb/
>3.1% Documentation/devicetree/bindings/usb/
>
> My tree will soak a bit on linux-next to catch any further build
> regressions (I couldn't find anything missing after the recent 4 patches
> I sent) and next week a pull request will be sent to Greg.
>
> Please, avoid sending patches until v4.3-rc1 is tagged as that goes a
> long way towards keeping my sanity ;-)

I'm not sure I understand.  What about discussion of USB patches for
the next release?
Can we send RFC patches amongst ourselves to the linux-usb list?

 -- Tim Bird
Senior Software Engineer, Sony Mobile
Architecture Group Chair, CE Workgroup, Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/8][v2]usb:fsl:otg: Add support to add/remove usb host driver

[Alan Stern]

On Wed, 15 Jul 2015, Ramneek Mehresh wrote:

> Add workqueue to add/remove host driver (outside
> interrupt context) upon each id change.
> 
> Signed-off-by: Li Yang 
> Signed-off-by: Ramneek Mehresh 
> ---
>  drivers/usb/host/ehci-fsl.c | 83 
> ++---
>  drivers/usb/host/ehci-fsl.h | 20 +++
>  2 files changed, 84 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
> index 5352e74..81e4bf5 100644
> --- a/drivers/usb/host/ehci-fsl.c
> +++ b/drivers/usb/host/ehci-fsl.c
> @@ -44,6 +44,34 @@
>  
>  static struct hc_driver __read_mostly fsl_ehci_hc_driver;
>  
> +#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)

You've got these #if lines all over the place.  They look ugly and make
the code hard to read.  Consider removing them.  Or even if you can't
remove them entirely, removing most of them would help.

Also, instead of testing both CONFIG_FSL_USB2_OTG and
CONFIG_FSL_USB2_OTG_MODULE, how about testing a single symbol?  For 
example:

#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
#define CHANGE_HCD 1
#else
#define CHANGE_HCD 0
#endif

Then all you need later on is "#if CHANGE_HCD".  Or if it's inside a 
code block, just "if (CHANGE_HCD)".

> +static struct ehci_fsl *hcd_to_ehci_fsl(struct usb_hcd *hcd)
> +{
> + return (struct ehci_fsl *)hcd_to_ehci(hcd)->priv;
> +}
> +
> +static void do_change_hcd(struct work_struct *work)
> +{
> + struct ehci_fsl *ehci_fsl = container_of(work, struct ehci_fsl,
> + change_hcd_work);
> + struct usb_hcd *hcd = ehci_fsl->hcd;
> + void __iomem *non_ehci = hcd->regs;
> + int retval;
> +
> + if (ehci_fsl->hcd_add && !ehci_fsl->have_hcd) {
> + writel(USBMODE_CM_HOST, non_ehci + FSL_SOC_USB_USBMODE);
> + /* host, gadget and otg share same int line */
> + retval = usb_add_hcd(hcd, hcd->irq, IRQF_SHARED);
> + if (retval == 0)
> + ehci_fsl->have_hcd = 1;
> + } else if (!ehci_fsl->hcd_add && ehci_fsl->have_hcd) {
> + usb_remove_hcd(hcd);
> + ehci_fsl->have_hcd = 0;

Don't you have to turn off the USBMODE_CM_HOST bit here?  It looks 
strange to turn it on above but not turn it off again.

> + }
> +}
> +#endif


>  static int ehci_fsl_drv_suspend(struct device *dev)
>  {
>   struct usb_hcd *hcd = dev_get_drvdata(dev);
> - struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
>   void __iomem *non_ehci = hcd->regs;
> +#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
> + struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
> + struct usb_bus host = hcd->self;
> +#endif
> +
>  
>   if (of_device_is_compatible(dev->parent->of_node,
>   "fsl,mpc5121-usb2-dr")) {
>   return ehci_fsl_mpc512x_drv_suspend(dev);
>   }
>  
> +#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
> + if (host.is_otg) {
> + /* remove hcd */
> + ehci_fsl->hcd_add = 0;
> + schedule_work(&ehci_fsl->change_hcd_work);
> + host.is_otg = 0;

Why do you set host.is_otg to 0 here?  Why not do it in the work 
routine?

> + return 0;
> + }
> +#endif
> +
>   ehci_prepare_ports_for_controller_suspend(hcd_to_ehci(hcd),
>   device_may_wakeup(dev));
>   if (!fsl_deep_sleep())
> @@ -540,15 +571,29 @@ static int ehci_fsl_drv_suspend(struct device *dev)
>  static int ehci_fsl_drv_resume(struct device *dev)
>  {
>   struct usb_hcd *hcd = dev_get_drvdata(dev);
> - struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
>   struct ehci_hcd *ehci = hcd_to_ehci(hcd);
>   void __iomem *non_ehci = hcd->regs;
> +#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
> + struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
> + struct usb_bus host = hcd->self;
> +#endif
>  
>   if (of_device_is_compatible(dev->parent->of_node,
>   "fsl,mpc5121-usb2-dr")) {
>   return ehci_fsl_mpc512x_drv_resume(dev);
>   }
>  
> +#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
> + if (host.is_otg) {
> + /* add hcd */
> + ehci_fsl->hcd_add = 1;
> + schedule_work(&ehci_fsl->change_hcd_work);
> + usb_hcd_resume_root_hub(hcd);
> + host.is_otg = 0;

Again, why change host.is_otg here?  And for that matter, where does 
host.is_otg ever get set to 1?

Also, what is the reason for calling usb_hcd_resume_root_hub()?  It 
won't do anything, because it will run before the scheduled work, so 
there won't be a root hub for it to resume.

> + return 0;
> + }
> +#endif
> +
>   ehci_prepare_ports_for_controller_resume(ehci);
>   if (!fsl_deep_sleep())
>   return 0;
> diff

[Patch v4] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification

[Tal Shorer]

>From the usb 3.1 spec available at http://www.usb.org/developers/docs/
table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and
GetPortErrorCount as:

Request bmRequestType   bRequestwValue  
wIndex  wLength Data
SetHubDepth 0010B   SET_HUB_DEPTH   Hub Depth   
ZeroZeroNone
GetPortErrorCount   10100011B   GET_PORT_ERR_COUNT  Zero
PortTwo Number of Link Errors on this port

Fix these two values to match the spec.

Signed-off-by: Tal Shorer 
---
 include/linux/usb/hcd.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index c9aa779..d2784c1 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -564,9 +564,9 @@ extern void usb_ep0_reinit(struct usb_device *);
 
 /*-*/
 
-/* class requests from USB 3.0 hub spec, table 10-5 */
-#define SetHubDepth(0x3000 | HUB_SET_DEPTH)
-#define GetPortErrorCount  (0x8000 | HUB_GET_PORT_ERR_COUNT)
+/* class requests from USB 3.1 hub spec, table 10-7 */
+#define SetHubDepth(0x2000 | HUB_SET_DEPTH)
+#define GetPortErrorCount  (0xa300 | HUB_GET_PORT_ERR_COUNT)
 
 /*
  * Generic bandwidth allocation constants/support
-- 
2.4.6

--
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.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification

[Greg KH]

On Fri, Aug 07, 2015 at 09:48:19PM +0300, Tal Shorer wrote:
> On Fri, Aug 7, 2015 at 9:40 PM, Greg KH  wrote:
> > On Fri, Aug 07, 2015 at 09:16:00PM +0300, Tal Shorer wrote:
> >> >From the usb 3.1 spec available at http://www.usb.org/developers/docs/
> >> table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and
> >> GetPortErrorCount as:
> >>
> >> Request bmRequestType bRequest wValue wIndex wLength Data
> >> SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
> >> GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of 
> >> Link Errors on this port
> >
> > Still does not look correct to me, how about you?
> >
> 
> Not sure what you mean. This is a simple copy-paste from the spec document.
> Do you want me to put quotation marks around the multi-word Data column?

I want the columns to line up so that they look sane and someone can
understand what they mean :)

--
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.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification

[Tal Shorer]

On Fri, Aug 7, 2015 at 9:40 PM, Greg KH  wrote:
> On Fri, Aug 07, 2015 at 09:16:00PM +0300, Tal Shorer wrote:
>> >From the usb 3.1 spec available at http://www.usb.org/developers/docs/
>> table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and
>> GetPortErrorCount as:
>>
>> Request bmRequestType bRequest wValue wIndex wLength Data
>> SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
>> GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link 
>> Errors on this port
>
> Still does not look correct to me, how about you?
>

Not sure what you mean. This is a simple copy-paste from the spec document.
Do you want me to put quotation marks around the multi-word Data column?
--
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.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification

[Greg KH]

On Fri, Aug 07, 2015 at 09:16:00PM +0300, Tal Shorer wrote:
> >From the usb 3.1 spec available at http://www.usb.org/developers/docs/
> table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and
> GetPortErrorCount as:
> 
> Request bmRequestType bRequest wValue wIndex wLength Data
> SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
> GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link 
> Errors on this port

Still does not look correct to me, how about you?

--
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] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification

[Tal Shorer]

Please ignore v2, I missed that you

On Fri, Aug 7, 2015 at 9:13 PM, Tal Shorer  wrote:
> From the usb 3.1 spec available at http://www.usb.org/developers/docs/
> table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and
> GetPortErrorCount as:
>
> Request bmRequestType bRequest wValue wIndex wLength Data
> SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
> GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link
> Errors on this port
>
> Fix these two values to match the spec.
>
> Signed-off-by: Tal Shorer 
> ---
>  include/linux/usb/hcd.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
> index c9aa779..d2784c1 100644
> --- a/include/linux/usb/hcd.h
> +++ b/include/linux/usb/hcd.h
> @@ -564,9 +564,9 @@ extern void usb_ep0_reinit(struct usb_device *);
>
>  /*-*/
>
> -/* class requests from USB 3.0 hub spec, table 10-5 */
> -#define SetHubDepth(0x3000 | HUB_SET_DEPTH)
> -#define GetPortErrorCount  (0x8000 | HUB_GET_PORT_ERR_COUNT)
> +/* class requests from USB 3.1 hub spec, table 10-7 */
> +#define SetHubDepth(0x2000 | HUB_SET_DEPTH)
> +#define GetPortErrorCount  (0xa300 | HUB_GET_PORT_ERR_COUNT)
>
>  /*
>   * Generic bandwidth allocation constants/support
> --
> 2.4.6
>
--
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 v3] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification

[Tal Shorer]

>From the usb 3.1 spec available at http://www.usb.org/developers/docs/
table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and
GetPortErrorCount as:

Request bmRequestType bRequest wValue wIndex wLength Data
SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link 
Errors on this port

Fix these two values to match the spec.

Signed-off-by: Tal Shorer 
---
 include/linux/usb/hcd.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index c9aa779..d2784c1 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -564,9 +564,9 @@ extern void usb_ep0_reinit(struct usb_device *);
 
 /*-*/
 
-/* class requests from USB 3.0 hub spec, table 10-5 */
-#define SetHubDepth(0x3000 | HUB_SET_DEPTH)
-#define GetPortErrorCount  (0x8000 | HUB_GET_PORT_ERR_COUNT)
+/* class requests from USB 3.1 hub spec, table 10-7 */
+#define SetHubDepth(0x2000 | HUB_SET_DEPTH)
+#define GetPortErrorCount  (0xa300 | HUB_GET_PORT_ERR_COUNT)
 
 /*
  * Generic bandwidth allocation constants/support
-- 
2.4.6

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

[Patch v2] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification

[Tal Shorer]

>From the usb 3.1 spec available at http://www.usb.org/developers/docs/
table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and
GetPortErrorCount as:

Request bmRequestType bRequest wValue wIndex wLength Data
SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link
Errors on this port

Fix these two values to match the spec.

Signed-off-by: Tal Shorer 
---
 include/linux/usb/hcd.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index c9aa779..d2784c1 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -564,9 +564,9 @@ extern void usb_ep0_reinit(struct usb_device *);
 
 /*-*/
 
-/* class requests from USB 3.0 hub spec, table 10-5 */
-#define SetHubDepth(0x3000 | HUB_SET_DEPTH)
-#define GetPortErrorCount  (0x8000 | HUB_GET_PORT_ERR_COUNT)
+/* class requests from USB 3.1 hub spec, table 10-7 */
+#define SetHubDepth(0x2000 | HUB_SET_DEPTH)
+#define GetPortErrorCount  (0xa300 | HUB_GET_PORT_ERR_COUNT)
 
 /*
  * Generic bandwidth allocation constants/support
-- 
2.4.6

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

Re: [PATCH] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification

[Greg KH]

On Fri, Aug 07, 2015 at 08:52:25PM +0300, Tal Shorer wrote:
> >From the usb 3.1 spec available at http://www.usb.org/developers/docs/
> table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and
> GetPortErrorCount as:
> 
> Request bmRequestType bRequest wValue wIndex wLength Data
> SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
> GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link
>   Errors on this port
> 
> Fix these two values to match the spec.
> 
> Signed-off-by: Tal Shorer 
> ---
>  include/linux/usb/hcd.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
> index c9aa779..6a24416 100644
> --- a/include/linux/usb/hcd.h
> +++ b/include/linux/usb/hcd.h
> @@ -564,9 +564,9 @@ extern void usb_ep0_reinit(struct usb_device *);
>  
>  /*-*/
>  
> -/* class requests from USB 3.0 hub spec, table 10-5 */
> -#define SetHubDepth  (0x3000 | HUB_SET_DEPTH)
> -#define GetPortErrorCount(0x8000 | HUB_GET_PORT_ERR_COUNT)
> +/* class requests from USB 3.1 hub spec, table 10-7 */
> +#define SetHubDepth (0x2000 | HUB_SET_DEPTH)
> +#define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT)

Why did you loose the indentation?

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

Re: [PATCH] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification

[Greg KH]

On Fri, Aug 07, 2015 at 08:52:25PM +0300, Tal Shorer wrote:
> >From the usb 3.1 spec available at http://www.usb.org/developers/docs/
> table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and
> GetPortErrorCount as:
> 
> Request bmRequestType bRequest wValue wIndex wLength Data
> SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
> GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link
>   Errors on this port

This doesn't make much sense at all, can you properly format it to look
correct?

thanks,

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

Re: [PATCH 0/2] Introduce usb charger framework to deal with the usb gadget power negotation

[Greg KH]

On Fri, Aug 07, 2015 at 04:19:40PM +0800, Baolin Wang wrote:
> On 7 August 2015 at 13:34, Peter Chen  wrote:
> > On Thu, Aug 06, 2015 at 03:03:47PM +0800, Baolin Wang wrote:
> >> Currently the Linux kernel does not provide any standard integration of 
> >> this
> >> feature that integrates the USB subsystem with the system power regulation
> >> provided by PMICs meaning that either vendors must add this in their 
> >> kernels
> >> or USB gadget devices based on Linux (such as mobile phones) may not behave
> >> as they should.
> >>
> >> Providing a standard framework for doing this in the kernel.
> >
> > Baolin, thanks for introducing a framework for doing it, we do support
> > USB Charger for chipidea driver at internal tree, but it is specific
> > for imx, and still have some problems to upstream due to need to
> > change some common code.
> >
> > One suggestion, would you add your user next time? In that case, we can
> > know better for this framework.
> >
> 
> Peter, Thanks for your reviewing and comments. Now I just introduce
> the framework to review for more feedbacks and do not have a useful
> user to use it. I just can show you some example code to show how to
> use it. Thanks.

Without a real, in-tree user, I can not accept this code.  We don't add
"frameworks" for non-existant things, otherwise it will be instantly
ripped out the next kernel release.

Please come up with at least 2 users, ideally 3, otherwise there's no
real way to know if the framework is sufficient.

thanks,

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

[PATCH] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification

[Tal Shorer]

>From the usb 3.1 spec available at http://www.usb.org/developers/docs/
table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and
GetPortErrorCount as:

Request bmRequestType bRequest wValue wIndex wLength Data
SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link
Errors on this port

Fix these two values to match the spec.

Signed-off-by: Tal Shorer 
---
 include/linux/usb/hcd.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index c9aa779..6a24416 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -564,9 +564,9 @@ extern void usb_ep0_reinit(struct usb_device *);
 
 /*-*/
 
-/* class requests from USB 3.0 hub spec, table 10-5 */
-#define SetHubDepth(0x3000 | HUB_SET_DEPTH)
-#define GetPortErrorCount  (0x8000 | HUB_GET_PORT_ERR_COUNT)
+/* class requests from USB 3.1 hub spec, table 10-7 */
+#define SetHubDepth (0x2000 | HUB_SET_DEPTH)
+#define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT)
 
 /*
  * Generic bandwidth allocation constants/support
-- 
2.4.6

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

Re: [PATCH 2/2] gadget: Support for the usb charger framework

[Greg KH]

On Fri, Aug 07, 2015 at 05:22:47PM +0800, Baolin Wang wrote:
> On 7 August 2015 at 17:07, Peter Chen  wrote:
> >
> >> >>  /**
> >> >>   * struct usb_udc - describes one usb device controller @@ -127,12
> >> >> +128,45 @@ void usb_gadget_giveback_request(struct usb_ep *ep,  }
> >> >> EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
> >> >>
> >> >> +int usb_gadget_register_notify(struct usb_gadget *gadget,
> >> >> +struct notifier_block *nb) {
> >> >> + unsigned long flags;
> >> >> + int ret;
> >> >> +
> >> >> + spin_lock_irqsave(&gadget->lock, flags);
> >> >
> >> > I find you use so many spin_lock_irqsave, any reasons for that?
> >> > Why mutex_lock can't be used?
> >> >
> >>
> >> The spin_lock_irqsave() can make it as a atomic notifier, that can make 
> >> sure the
> >> gadget state event can be quickly reported to the user who register a 
> >> notifier
> >> on the gadget device. Is it OK?
> >>
> >
> > I don't think it is a good reason, spin_lock_irqsave is usually used for 
> > protecting
> > data which is accessed at atomic environment.
> >
> 
> Yes, we want the notify process is a atomic environment which do not
> want to be interrupted by irq or other things to make the notice can
> be quickly reported to the user.

No, this is a "slow" event, you don't need to notify anyone under atomic
context, that's crazy.

> Also i think the notify process is less cost, thus i use the spinlock. Thanks.

No, use a mutex please, that's the safe thing.  This is not
time-critical code at all.

thanks,

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

Re: USB - Generic Serial device : Unable to read more than 4095 bytes

[Greg KH]

On Fri, Aug 07, 2015 at 07:26:15PM +0900, arun k wrote:
> Hi,
> 
> I am stuck with the above issue,
> I have some doubts regarding USB - Generic driver
> 1. Could you please explain me why USB - Generic driver is slow ?

Because it was designed that way, it is not for high-speed data
throughput at all.  It is a stop-gap measure for dumb usb devices that
want to emulate a serial connection.  If you need a "real" driver, to
handle high rates of data, you will need to write a new driver for it.

> 2. Now I am try to study USB - Generic driver implementation , I am
> confused with the function usb_serial_generic_read_bulk_callback() ,
> could you please tell me from where this function is calling ?

I recommend reading the USB chapter in the Linux Device Drivers book
(version 3, free online) to understand how USB drivers work.  After
that, the answer should be obvious (hint, look at where that function
pointer is assigned to something...)

> 3. If you have any detailed doc regarding the implementation of USB -
> Generic serial driver, Please send to me,

The source code is pretty well documented :)

thanks,

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

Re: Values for SetHubDepth and GetPortErrorCount

[Tal Shorer]

On Fri, Aug 7, 2015 at 8:31 PM, Greg KH  wrote:
> On Fri, Aug 07, 2015 at 07:56:37PM +0300, Tal Shorer wrote:
>> On Fri, Aug 7, 2015 at 7:37 PM, Greg KH  wrote:
>> > On Fri, Aug 07, 2015 at 12:49:39PM +0300, Tal Shorer wrote:
>> >> In include/linux/usb/hcd.h, we have
>> >>
>> >> /* class requests from USB 3.0 hub spec, table 10-5 */
>> >> #define SetHubDepth (0x3000 | HUB_SET_DEPTH)
>> >> #define GetPortErrorCount (0x8000 | HUB_GET_PORT_ERR_COUNT)
>> >>
>> >> However, from the usb 3.1 spec I downloaded at
>> >> http://www.usb.org/developers/docs/,
>> >> table 10-5 appears to be unrelated (Table 10-5. Enhanced SuperSpeed
>> >> Hub Descriptor).
>> >
>> > Um, look at the comment you copied "3.0 hub spec", vs. the spec you
>> > downloaded and referred to "3.1 spec".  Things might have changed :)
>> >
>> Yeah, my bad.
>> >> Table 10-7 (Table 10-7. Hub Class Requests) lists the two values as:
>> >> Request bmRequestType bRequest wValue wIndex wLength Data
>> >> SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
>> >> GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of
>> >> Link Errors on this port
>> >>
>> >> It appears the correct bmRequestType values should be:
>> >> #define SetHubDepth (0x2000 | HUB_SET_DEPTH)
>> >> #define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT)
>> >>
>> >> Which are the bmRequestType values of SetHubFeature and GetPortStatus
>> >> (and friends).
>> >>
>> >> These lines were introduced in
>> >> commit 0eadcc09203349b11ca477ec367079b23d32ab91
>> >> Author: Tatyana Brokhman 
>> >> Date:   Mon Nov 1 18:18:24 2010 +0200
>> >>
>> >> usb: USB3.0 ch11 definitions
>> >>
>> >> Adding hub SuperSpeed usb definitions as defined by ch10 of the USB3.0
>> >> spec.
>> >>
>> >> Signed-off-by: Tatyana Brokhman 
>> >> Signed-off-by: Greg Kroah-Hartman 
>> >>
>> >> The values are only used by dummy_hcd which does nothing with them and
>> >> by max3421-hcd which returns an error.
>> >> Can anyone clarify what I'm missing or if the values are actually wrong?
>> >
>> > Can you compare the 3.1 to the 3.0 spec and see if they changed things
>> > here?
>> >
>> > thanks,
>> >
>> > greg k-h
>>
>> USB 3.0 spec download from 
>> http://www.usb.org/developers/docs/documents_archive/
>> Table 10-6. Hub Class Requests
>> GetPortErrorCount 1000B GET_PORT_ERR_COUNT Zero Port Two Number of
>> Link Errors on this port
>> SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
>>
>> It appears it wasn't changed from 3.0 to 3.1.
>> Looking at the code in hub.c, it appears root hubs are never called
>> with SetHubDepth.
>>
>> 1049 if (hdev->parent && hub_is_superspeed(hdev)) {
>> 1050 ret = usb_control_msg(hdev,
>> usb_sndctrlpipe(hdev, 0),
>> 1051 HUB_SET_DEPTH, USB_RT_HUB,
>> 1052 hdev->level - 1, 0, NULL, 0,
>> 1053 USB_CTRL_SET_TIMEOUT);
>>
>> There are no more uses of HUB_SET_DEPTH except for this one and the one in 
>> hcd.h
>>
>> tal@tal-H87-D3H:~/Dev/linux|0 $ git grep HUB_SET_DEPTH
>> drivers/usb/core/hub.c: HUB_SET_DEPTH,
>> USB_RT_HUB,
>> include/linux/usb/hcd.h:#define SetHubDepth (0x3000 | 
>> HUB_SET_DEPTH)
>> include/uapi/linux/usb/ch11.h:#define HUB_SET_DEPTH 12
>
> People use SetHubDepth today.
>
>> And HUB_GET_PORT_ERR_COUNT is never used by the hub driver:
>>
>> tal@tal-H87-D3H:~/Dev/linux|1 $ git grep HUB_GET_PORT_ERR_COUNT
>> include/linux/usb/hcd.h:#define GetPortErrorCount   (0x8000 |
>> HUB_GET_PORT_ERR_COUNT)
>> include/uapi/linux/usb/ch11.h:#define HUB_GET_PORT_ERR_COUNT13
>>
>> So even if the constant was right, root hubs using it would never
>> reach the code handling it.
>
> But again, GetPortErrorCount is being used.
Yes, but with the current implementation of hub.c, these uses will never
run. I don't really think it's a good idea to delete these uses, since
this feature might be implemented in the future.
>
>> Would you prefer to eliminate these completely or make them right in
>> case anyone uses them in the future?
>
> We should fix these if they were incorrect.
>
> Care to make up a patch?
Sure, I'll send it shortly.
>
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Values for SetHubDepth and GetPortErrorCount

[Greg KH]

On Fri, Aug 07, 2015 at 07:56:37PM +0300, Tal Shorer wrote:
> On Fri, Aug 7, 2015 at 7:37 PM, Greg KH  wrote:
> > On Fri, Aug 07, 2015 at 12:49:39PM +0300, Tal Shorer wrote:
> >> In include/linux/usb/hcd.h, we have
> >>
> >> /* class requests from USB 3.0 hub spec, table 10-5 */
> >> #define SetHubDepth (0x3000 | HUB_SET_DEPTH)
> >> #define GetPortErrorCount (0x8000 | HUB_GET_PORT_ERR_COUNT)
> >>
> >> However, from the usb 3.1 spec I downloaded at
> >> http://www.usb.org/developers/docs/,
> >> table 10-5 appears to be unrelated (Table 10-5. Enhanced SuperSpeed
> >> Hub Descriptor).
> >
> > Um, look at the comment you copied "3.0 hub spec", vs. the spec you
> > downloaded and referred to "3.1 spec".  Things might have changed :)
> >
> Yeah, my bad.
> >> Table 10-7 (Table 10-7. Hub Class Requests) lists the two values as:
> >> Request bmRequestType bRequest wValue wIndex wLength Data
> >> SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
> >> GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of
> >> Link Errors on this port
> >>
> >> It appears the correct bmRequestType values should be:
> >> #define SetHubDepth (0x2000 | HUB_SET_DEPTH)
> >> #define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT)
> >>
> >> Which are the bmRequestType values of SetHubFeature and GetPortStatus
> >> (and friends).
> >>
> >> These lines were introduced in
> >> commit 0eadcc09203349b11ca477ec367079b23d32ab91
> >> Author: Tatyana Brokhman 
> >> Date:   Mon Nov 1 18:18:24 2010 +0200
> >>
> >> usb: USB3.0 ch11 definitions
> >>
> >> Adding hub SuperSpeed usb definitions as defined by ch10 of the USB3.0
> >> spec.
> >>
> >> Signed-off-by: Tatyana Brokhman 
> >> Signed-off-by: Greg Kroah-Hartman 
> >>
> >> The values are only used by dummy_hcd which does nothing with them and
> >> by max3421-hcd which returns an error.
> >> Can anyone clarify what I'm missing or if the values are actually wrong?
> >
> > Can you compare the 3.1 to the 3.0 spec and see if they changed things
> > here?
> >
> > thanks,
> >
> > greg k-h
> 
> USB 3.0 spec download from 
> http://www.usb.org/developers/docs/documents_archive/
> Table 10-6. Hub Class Requests
> GetPortErrorCount 1000B GET_PORT_ERR_COUNT Zero Port Two Number of
> Link Errors on this port
> SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
> 
> It appears it wasn't changed from 3.0 to 3.1.
> Looking at the code in hub.c, it appears root hubs are never called
> with SetHubDepth.
> 
> 1049 if (hdev->parent && hub_is_superspeed(hdev)) {
> 1050 ret = usb_control_msg(hdev,
> usb_sndctrlpipe(hdev, 0),
> 1051 HUB_SET_DEPTH, USB_RT_HUB,
> 1052 hdev->level - 1, 0, NULL, 0,
> 1053 USB_CTRL_SET_TIMEOUT);
> 
> There are no more uses of HUB_SET_DEPTH except for this one and the one in 
> hcd.h
> 
> tal@tal-H87-D3H:~/Dev/linux|0 $ git grep HUB_SET_DEPTH
> drivers/usb/core/hub.c: HUB_SET_DEPTH,
> USB_RT_HUB,
> include/linux/usb/hcd.h:#define SetHubDepth (0x3000 | 
> HUB_SET_DEPTH)
> include/uapi/linux/usb/ch11.h:#define HUB_SET_DEPTH 12

People use SetHubDepth today.

> And HUB_GET_PORT_ERR_COUNT is never used by the hub driver:
> 
> tal@tal-H87-D3H:~/Dev/linux|1 $ git grep HUB_GET_PORT_ERR_COUNT
> include/linux/usb/hcd.h:#define GetPortErrorCount   (0x8000 |
> HUB_GET_PORT_ERR_COUNT)
> include/uapi/linux/usb/ch11.h:#define HUB_GET_PORT_ERR_COUNT13
> 
> So even if the constant was right, root hubs using it would never
> reach the code handling it.

But again, GetPortErrorCount is being used.

> Would you prefer to eliminate these completely or make them right in
> case anyone uses them in the future?

We should fix these if they were incorrect.

Care to make up a patch?

thanks,

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

Re: Values for SetHubDepth and GetPortErrorCount

[Tal Shorer]

On Fri, Aug 7, 2015 at 7:37 PM, Greg KH  wrote:
> On Fri, Aug 07, 2015 at 12:49:39PM +0300, Tal Shorer wrote:
>> In include/linux/usb/hcd.h, we have
>>
>> /* class requests from USB 3.0 hub spec, table 10-5 */
>> #define SetHubDepth (0x3000 | HUB_SET_DEPTH)
>> #define GetPortErrorCount (0x8000 | HUB_GET_PORT_ERR_COUNT)
>>
>> However, from the usb 3.1 spec I downloaded at
>> http://www.usb.org/developers/docs/,
>> table 10-5 appears to be unrelated (Table 10-5. Enhanced SuperSpeed
>> Hub Descriptor).
>
> Um, look at the comment you copied "3.0 hub spec", vs. the spec you
> downloaded and referred to "3.1 spec".  Things might have changed :)
>
Yeah, my bad.
>> Table 10-7 (Table 10-7. Hub Class Requests) lists the two values as:
>> Request bmRequestType bRequest wValue wIndex wLength Data
>> SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
>> GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of
>> Link Errors on this port
>>
>> It appears the correct bmRequestType values should be:
>> #define SetHubDepth (0x2000 | HUB_SET_DEPTH)
>> #define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT)
>>
>> Which are the bmRequestType values of SetHubFeature and GetPortStatus
>> (and friends).
>>
>> These lines were introduced in
>> commit 0eadcc09203349b11ca477ec367079b23d32ab91
>> Author: Tatyana Brokhman 
>> Date:   Mon Nov 1 18:18:24 2010 +0200
>>
>> usb: USB3.0 ch11 definitions
>>
>> Adding hub SuperSpeed usb definitions as defined by ch10 of the USB3.0
>> spec.
>>
>> Signed-off-by: Tatyana Brokhman 
>> Signed-off-by: Greg Kroah-Hartman 
>>
>> The values are only used by dummy_hcd which does nothing with them and
>> by max3421-hcd which returns an error.
>> Can anyone clarify what I'm missing or if the values are actually wrong?
>
> Can you compare the 3.1 to the 3.0 spec and see if they changed things
> here?
>
> thanks,
>
> greg k-h

USB 3.0 spec download from http://www.usb.org/developers/docs/documents_archive/
Table 10-6. Hub Class Requests
GetPortErrorCount 1000B GET_PORT_ERR_COUNT Zero Port Two Number of
Link Errors on this port
SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None

It appears it wasn't changed from 3.0 to 3.1.
Looking at the code in hub.c, it appears root hubs are never called
with SetHubDepth.

1049 if (hdev->parent && hub_is_superspeed(hdev)) {
1050 ret = usb_control_msg(hdev,
usb_sndctrlpipe(hdev, 0),
1051 HUB_SET_DEPTH, USB_RT_HUB,
1052 hdev->level - 1, 0, NULL, 0,
1053 USB_CTRL_SET_TIMEOUT);

There are no more uses of HUB_SET_DEPTH except for this one and the one in hcd.h

tal@tal-H87-D3H:~/Dev/linux|0 $ git grep HUB_SET_DEPTH
drivers/usb/core/hub.c: HUB_SET_DEPTH,
USB_RT_HUB,
include/linux/usb/hcd.h:#define SetHubDepth (0x3000 | HUB_SET_DEPTH)
include/uapi/linux/usb/ch11.h:#define HUB_SET_DEPTH 12

And HUB_GET_PORT_ERR_COUNT is never used by the hub driver:

tal@tal-H87-D3H:~/Dev/linux|1 $ git grep HUB_GET_PORT_ERR_COUNT
include/linux/usb/hcd.h:#define GetPortErrorCount   (0x8000 |
HUB_GET_PORT_ERR_COUNT)
include/uapi/linux/usb/ch11.h:#define HUB_GET_PORT_ERR_COUNT13

So even if the constant was right, root hubs using it would never
reach the code handling it.


Would you prefer to eliminate these completely or make them right in
case anyone uses them in the future?
--
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: Values for SetHubDepth and GetPortErrorCount

[Greg KH]

On Fri, Aug 07, 2015 at 12:49:39PM +0300, Tal Shorer wrote:
> In include/linux/usb/hcd.h, we have
> 
> /* class requests from USB 3.0 hub spec, table 10-5 */
> #define SetHubDepth (0x3000 | HUB_SET_DEPTH)
> #define GetPortErrorCount (0x8000 | HUB_GET_PORT_ERR_COUNT)
> 
> However, from the usb 3.1 spec I downloaded at
> http://www.usb.org/developers/docs/,
> table 10-5 appears to be unrelated (Table 10-5. Enhanced SuperSpeed
> Hub Descriptor).

Um, look at the comment you copied "3.0 hub spec", vs. the spec you
downloaded and referred to "3.1 spec".  Things might have changed :)

> Table 10-7 (Table 10-7. Hub Class Requests) lists the two values as:
> Request bmRequestType bRequest wValue wIndex wLength Data
> SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
> GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of
> Link Errors on this port
> 
> It appears the correct bmRequestType values should be:
> #define SetHubDepth (0x2000 | HUB_SET_DEPTH)
> #define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT)
> 
> Which are the bmRequestType values of SetHubFeature and GetPortStatus
> (and friends).
> 
> These lines were introduced in
> commit 0eadcc09203349b11ca477ec367079b23d32ab91
> Author: Tatyana Brokhman 
> Date:   Mon Nov 1 18:18:24 2010 +0200
> 
> usb: USB3.0 ch11 definitions
> 
> Adding hub SuperSpeed usb definitions as defined by ch10 of the USB3.0
> spec.
> 
> Signed-off-by: Tatyana Brokhman 
> Signed-off-by: Greg Kroah-Hartman 
> 
> The values are only used by dummy_hcd which does nothing with them and
> by max3421-hcd which returns an error.
> Can anyone clarify what I'm missing or if the values are actually wrong?

Can you compare the 3.1 to the 3.0 spec and see if they changed things
here?

thanks,

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

Re: Increasing TRBS_PER_SEGMENT causes DMAR/PTE faults

[Mathias Nyman]

On 07.08.2015 15:40, linux-...@andraxin.se wrote:
> Hi there,

Hi

> 
> 
> Moving from 4.0.4 to 4.0.5, my USB 3.0 controller became practically useless
> (and this same issue persists [at least] upto and including 4.1.3).
> Here's an excerpt from my syslog demonstrating the problem:
> 
...
> 
> Looking in ChangeLog-4.0.5 for xhci-related changes gave me 3 hits:
> 
> (1)  xhci: gracefully handle xhci_irq dead device
>  commit 948fa13504f80b9765d2b753691ab94c83a10341 upstream.
> 
> (2)  xhci: Solve full event ring by increasing TRBS_PER_SEGMENT to 256
>  commit 18cc2f4cbbaf825a4fedcf2d60fd388d291e0a38 upstream.
> 
> (3)  xhci: fix isoc endpoint dequeue from advancing too far on transaction 
> error
>  commit d104d0152a97fade389f47635b73a9ccc7295d0b upstream.
> 
> The first one seemed fairly irrelevant.  The third one mentions DMA, but
> looking at the actual changes, I couldn't see an obvious connection to the
> 'PTE read access' issue.  So, I tested reverting the second patch in my
> current (4.1.3) kernel and my USB 3.0 controller started working again.
> 
> This is good enough for me, but I thought you might want to look more closely
> at the root cause, and ensure that the PTE is correctly setup even with the
> increased TRBS_PER_SEGMENT.
> 

We just found that the TRBS_PER_SEGMENT reveals an old off by one error in an 
upper boundary check.
Previously a ring segment didn't use a full memory page, and each ring segment 
was allocated a new page, so the +1 off by one never caused any harm.

Now that we use the full memory page the off by one actually allowed us going 
past the allocated page.

This is fixed in patch 
commit 7895086afde2a05fa24a0e410d8e6b75ca7c8fdd
xhci: fix off by one error in TRB DMA address boundary check

Fix is now in  Greg's usb-linus branch, and should end up in linus 4.2 kernel 
(rc6 earliest)

Does that fix help in your case?

-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

Re: [PATCH 2/2] usb: musb: gadget: fix build break by adding missing 'break'

[Felipe Balbi]

On Fri, Aug 07, 2015 at 02:13:34PM +0200, Robert Baldyga wrote:
> Add missing break after 'default' label to fix compilation error.
> 
> Signed-off-by: Robert Baldyga 

the funny thing is that this doesn't break with ARM build:

$ make ARCH=arm drivers/usb/musb/
  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  UPD include/config/kernel.release
  CHK include/generated/utsrelease.h
  UPD include/generated/utsrelease.h
make[1]: 'include/generated/mach-types.h' is up to date.
  CHK include/generated/timeconst.h
  CHK include/generated/bounds.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  LD  drivers/usb/musb/built-in.o
  CC [M]  drivers/usb/musb/musb_core.o
  CC [M]  drivers/usb/musb/musb_virthub.o
  CC [M]  drivers/usb/musb/musb_host.o
  CC [M]  drivers/usb/musb/musb_gadget_ep0.o
  CC [M]  drivers/usb/musb/musb_gadget.o
  CC [M]  drivers/usb/musb/musb_debugfs.o
  CC [M]  drivers/usb/musb/omap2430.o
  CC [M]  drivers/usb/musb/musb_dsps.o
  CC [M]  drivers/usb/musb/musb_am335x.o
  CC [M]  drivers/usb/musb/am35x.o
  CC [M]  drivers/usb/musb/sunxi.o
  CC [M]  drivers/usb/musb/tusb6010.o
  CC [M]  drivers/usb/musb/ux500.o
  LD [M]  drivers/usb/musb/musb_hdrc.o

oh well :-p

-- 
balbi


signature.asc
Description: Digital signature

Re: USB - Generic Serial device : Unable to read more than 4095 bytes

[Peter Hurley]

On 08/06/2015 02:42 AM, arun k wrote:
> / # lsusb -v
> Bus 002 Device 006: ID 045b:0218
> Bus 001 Device 001: ID 1d6b:0002
> Bus 002 Device 001: ID 1d6b:0001
> Bus 003 Device 001: ID 1d6b:0002
> Bus 004 Device 001: ID 1d6b:0003
> 
> In this my device is
> Bus 002 Device 006: ID 045b:0218

I have no idea what this device is, sorry. And the device descriptor
dump below is not very helpful because it doesn't have the configurations.
What is this for?

> I enabled data dumping in usb_serial_generic_read_bulk_callback()
> function and found data received in this function is losing.
> In this function data is received as 64 bytes packets and two
> continuous 64 bytes having no data loss but the next packets are lost
> ie
> 1st packet ok(64 byte)
> 2nd packet ok(64 byte)
> .
> . packet lossing
> .
> 7th packet ok(64 byte)
> 8th packet ok(64 byte)
> .
> .
> In this way data loss is happening. Number of packets losing is
> different not constant always.

It's unclear what you are saying here; are you saying
(a) the sending device is dropping data so the urbs do not contain the
data you expect, or
(b) all of the data is being received but the not all of it is being
buffered.

Either way, the fundamental problem you have is that your reader is
not fast enough. What is your application?

Have you tried a simple test jig that only reads data without processing
it to see if the application is the problem?

What h/w platform is this?

You mentioned earlier you're running 3.4.35. That's really old; current 3.4
is .108. Where did you get this kernel?

Regards,
Peter Hurley

PS - Please stop top-posting. See how I had to reiterate your linux version...


>>> I think the generic USB driver ignores baud rate. Like Greg suggested, 
>>> >>you need to
>>> use the proper driver for your hardware.
> 
> I did't find any other suitable driver inside Linux.
> I checked this device in windows in that usbser.sys is detecting(.inf
> file is attached with the mail).
> 
>  Could you suggest any available drivers for my device. Sorry I am
> very new to Linux drivers.
> I will post my USB device descriptor values below
> 
> [ 1291.908071] ## udev->descriptor.bLength  0x12
> [ 1291.908089] ## udev->descriptor.bDescriptorType  0x1
> [ 1291.908147] ## udev->descriptor.bcdUSB  0x200
> [ 1291.908165] ## udev->descriptor.bDeviceClass  0xef
> [ 1291.908181] ## udev->descriptor.bDeviceSubClass  0x2
> [ 1291.908196] ## udev->descriptor.bDeviceProtocol  0x1
> [ 1291.908211] ## udev->descriptor.bMaxPacketSize0  0x40
> [ 1291.908226] ## udev->descriptor.idVendor  0x45b
> [ 1291.908241] ## udev->descriptor.idProduct  0x218
> [ 1291.908255] ## udev->descriptor.bcdDevice  0x1
> [ 1291.908270] ## udev->descriptor.iManufacturer  0x0
> [ 1291.908284] ## udev->descriptor.iProduct  0x0
> [ 1291.908298] ## udev->descriptor.iSerialNumber  0x0
> [ 1291.908313] ## udev->descriptor.bNumConfigurations  0x1
> 
> Regards,
> Arun
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, Aug 5, 2015 at 9:31 PM, Peter Hurley  wrote:
>> On 08/04/2015 11:57 PM, arun k wrote:
 Ok, but does the sending device know how to process in-band software flow 
 control
 and is it set up to respond properly?
>>>
>>> I am not sure about this. I need to check this.
>>>
 Also, I doubt software flow control is going to work @ 4Mbaud line rate.
 If you're stuck using software flow control, start with a 115kbaud line 
 rate
 and see if that fixes your data loss problem
>>>
>>> I tried B115200 also but issue is still there.
>>
>> I think the generic USB driver ignores baud rate. Like Greg suggested, you 
>> need to
>> use the proper driver for your hardware.
>>
>> What is the output from 'lsusb -v' and please identify in that output which
>> device you are using.
>>
>>> I am using a USB device and that sending data at a rate of *409600 
>>> bytes/sec*. Is this data rate have any relation with issue.
>>
>> Yes. Also, can you test this on a newer kernel like 3.18?
>>
>> Regards,
>> Peter Hurley
>>
>>> On Wed, Aug 5, 2015 at 11:24 AM, Peter Hurley >> > wrote:
>>>
>>> On 08/04/2015 10:00 PM, arun k wrote:
>>> > I enabled software flow control like below
>>> >
>>> > tty.c_iflag |= (IXON | IXOFF | IXANY);
>>>
>>> Ok, but does the sending device know how to process in-band software 
>>> flow control
>>> and is it set up to respond properly?
>>>
>>> Also, I doubt software flow control is going to work @ 4Mbaud line rate.
>>> If you're stuck using software flow control, start with a 115kbaud line 
>>> rate
>>> and see if that fixes your data loss problem.
>>>
>>> Regards,
>>> Peter Hurley
>>>
>>>
>>> > On Wed, Aug 5, 2015 at 12:59 AM, Peter Hurley 
>>> mailto:pe...@hurleysoftware.com>> wrote:
>>> >> On 08/03/2015 10:47 PM, arun k wrote:
>>> >>> Thank you for the reply
>>> >>>
>>> > The tty layer is limiting you, just keep reading in a loop until 
>>> you
>>> > run out 

[PATCH] usb: musb: gadget: fix possible build error

[Felipe Balbi]

While building MUSB for Blackfin, a build error
can surface due to the empty default branch of
the switch statement.

In order to avoid the problem, just add a ; with
a comment.

Reported-by: Fengguang Wu 
Signed-off-by: Felipe Balbi 
---
 drivers/usb/musb/musb_gadget.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index cc503591b634..b30ed129ddf3 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1703,6 +1703,7 @@ static struct usb_ep *musb_match_ep(struct usb_gadget *g,
ep = gadget_find_ep_by_name(g, "ep2out");
break;
default:
+   /* nothing */ ;
}
 
if (ep && usb_gadget_ep_match_desc(g, ep, desc, ep_comp))
-- 
2.5.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

Increasing TRBS_PER_SEGMENT causes DMAR/PTE faults

[linux-usb]

Hi there,


Moving from 4.0.4 to 4.0.5, my USB 3.0 controller became practically useless
(and this same issue persists [at least] upto and including 4.1.3).
Here's an excerpt from my syslog demonstrating the problem:

-=-=-
Jun 24 23:15:22 eleven kernel: usb 2-4: new SuperSpeed USB device number 2
using xhci_hcd
Jun 24 23:15:22 eleven kernel: usb 2-4: New USB device found, idVendor=0781,
idProduct=5588
Jun 24 23:15:22 eleven kernel: usb 2-4: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
Jun 24 23:15:22 eleven kernel: usb 2-4: Product: ExtremePro
Jun 24 23:15:22 eleven kernel: usb 2-4: Manufacturer: SanDisk
Jun 24 23:15:22 eleven kernel: usb 2-4: SerialNumber: AA010602150045080168
Jun 24 23:15:22 eleven kernel: usb-storage 2-4:1.0: USB Mass Storage device
detected
Jun 24 23:15:22 eleven kernel: scsi host8: usb-storage 2-4:1.0
Jun 24 23:15:21 eleven mtp-probe[19425]: checking bus 2, device 2:
"/sys/devices/pci:00/:00:1c.4/:03:00.0/usb2/2-4"
Jun 24 23:15:21 eleven mtp-probe[19425]: bus: 2, device: 2 was not an MTP
device
Jun 24 23:15:23 eleven kernel: scsi 8:0:0:0: Direct-Access SanDisk
ExtremePro   0001 PQ: 0 ANSI: 6
Jun 24 23:15:23 eleven kernel: sd 8:0:0:0: [sdi] 250069680 512-byte logical
blocks: (128 GB/119 GiB)
Jun 24 23:15:23 eleven kernel: sd 8:0:0:0: [sdi] Write Protect is off
Jun 24 23:15:23 eleven kernel: sd 8:0:0:0: [sdi] Mode Sense: 53 00 00 08
Jun 24 23:15:23 eleven kernel: sd 8:0:0:0: [sdi] Write cache: disabled, read
cache: enabled, doesn't support DPO or FUA
Jun 24 23:15:23 eleven kernel:  sdi: sdi1 sdi2 sdi3 sdi4
Jun 24 23:15:23 eleven kernel: sd 8:0:0:0: [sdi] Attached SCSI removable disk
Jun 24 23:15:23 eleven kernel: dmar: DRHD: handling fault status reg 2
Jun 24 23:15:23 eleven kernel: dmar: DMAR:[DMA Read] Request device [03:00.0]
fault addr fffbd000 \x0aDMAR:[fault reason 06] PTE Read access is not set
Jun 24 23:15:23 eleven kernel: dmar: DRHD: handling fault status reg 2
Jun 24 23:15:23 eleven kernel: dmar: DMAR:[DMA Read] Request device [03:00.0]
fault addr fffbd000 \x0aDMAR:[fault reason 06] PTE Read access is not set
Jun 24 23:15:23 eleven kernel: xhci_hcd :03:00.0: WARNING: Host System
Error
Jun 24 23:16:13 eleven kernel: xhci_hcd :03:00.0: Stopped the command ring
failed, maybe the host is dead
Jun 24 23:16:15 eleven kernel: xhci_hcd :03:00.0: Abort command ring
failed
Jun 24 23:16:15 eleven kernel: xhci_hcd :03:00.0: HC died; cleaning up
Jun 24 23:16:15 eleven kernel: xhci_hcd :03:00.0: Timeout while waiting
for setup device command
Jun 24 23:16:15 eleven kernel: usb 1-1: USB disconnect, device number 2
Jun 24 23:16:15 eleven kernel: usb 2-4: USB disconnect, device number 0
-=-=-


This is a "VIA Technologies, Inc. VL80x xHCI USB 3.0 Controller" inserted
into an older Gigabyte board with Intel Q35 chipset, VT-d enabled...


Looking in ChangeLog-4.0.5 for xhci-related changes gave me 3 hits:

(1)  xhci: gracefully handle xhci_irq dead device
 commit 948fa13504f80b9765d2b753691ab94c83a10341 upstream.

(2)  xhci: Solve full event ring by increasing TRBS_PER_SEGMENT to 256
 commit 18cc2f4cbbaf825a4fedcf2d60fd388d291e0a38 upstream.

(3)  xhci: fix isoc endpoint dequeue from advancing too far on transaction error
 commit d104d0152a97fade389f47635b73a9ccc7295d0b upstream.

The first one seemed fairly irrelevant.  The third one mentions DMA, but
looking at the actual changes, I couldn't see an obvious connection to the
'PTE read access' issue.  So, I tested reverting the second patch in my
current (4.1.3) kernel and my USB 3.0 controller started working again.

This is good enough for me, but I thought you might want to look more closely
at the root cause, and ensure that the PTE is correctly setup even with the
increased TRBS_PER_SEGMENT.

Kind regards,


--@;

PS
I'd _love_ to help, but I have very little "screen time".  I'm lucky
if I can turn on this box once a week...  (That's also why it took me
almost 2 months to figure out what the problem was.)
DS
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 4/5] xhci: mediatek: support MTK xHCI host controller

[Chunfeng Yun]

MTK xhci host controller defines some extra SW scheduling
parameters for HW to minimize the scheduling effort for
synchronous and interrupt endpoints. The parameters are
put into reseved DWs of slot context and endpoint context

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/Kconfig|   9 +
 drivers/usb/host/Makefile   |   4 +
 drivers/usb/host/xhci-mtk-sch.c | 436 +
 drivers/usb/host/xhci-mtk.c | 837 
 drivers/usb/host/xhci-mtk.h | 133 +++
 drivers/usb/host/xhci-ring.c|  35 +-
 drivers/usb/host/xhci.c |  19 +-
 drivers/usb/host/xhci.h |   1 +
 8 files changed, 1467 insertions(+), 7 deletions(-)
 create mode 100644 drivers/usb/host/xhci-mtk-sch.c
 create mode 100644 drivers/usb/host/xhci-mtk.c
 create mode 100644 drivers/usb/host/xhci-mtk.h

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8afc3c1..358ab6d 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -34,6 +34,15 @@ config USB_XHCI_PCI
 config USB_XHCI_PLATFORM
tristate
 
+config USB_XHCI_MTK
+   tristate "xHCI support for Mediatek MT65xx"
+   select MFD_SYSCON
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ found in Mediatek MT65xx SoCs.
+ If unsure, say N.
+
 config USB_XHCI_MVEBU
tristate "xHCI support for Marvell Armada 375/38x"
select USB_XHCI_PLATFORM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 754efaa..00401f9 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -13,6 +13,9 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
 xhci-hcd-y := xhci.o xhci-mem.o
 xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
 xhci-hcd-y += xhci-trace.o
+ifneq ($(CONFIG_USB_XHCI_MTK), )
+   xhci-hcd-y += xhci-mtk-sch.o
+endif
 
 xhci-plat-hcd-y := xhci-plat.o
 ifneq ($(CONFIG_USB_XHCI_MVEBU), )
@@ -30,6 +33,7 @@ endif
 
 obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
 obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
+obj-$(CONFIG_USB_XHCI_MTK) += xhci-mtk.o
 
 obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
 obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c
new file mode 100644
index 000..d4b41a6
--- /dev/null
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -0,0 +1,436 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author:
+ *  Zhigang.Wei 
+ *  Chunfeng.Yun 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include "xhci.h"
+#include "xhci-mtk.h"
+
+#define SS_BW_BOUNDARY 51000
+/* table 5-5. High-speed Isoc Transaction Limits in usb_20 spec */
+#define HS_BW_BOUNDARY 6144
+/* usb2 spec section11.18.1: at most 188 FS bytes per microframe */
+#define FS_PAYLOAD_MAX 188
+
+/* mtk scheduler bitmasks */
+#define EP_BPKTS(p)((p) & 0x3f)
+#define EP_BCSCOUNT(p) (((p) & 0x7) << 8)
+#define EP_BBM(p)  ((p) << 11)
+#define EP_BOFFSET(p)  ((p) & 0x3fff)
+#define EP_BREPEAT(p)  (((p) & 0x7fff) << 16)
+
+static int is_fs_or_ls(enum usb_device_speed speed)
+{
+   return speed == USB_SPEED_FULL || speed == USB_SPEED_LOW;
+}
+
+static int get_bw_index(struct xhci_hcd *xhci, struct usb_device *udev,
+   struct usb_host_endpoint *ep)
+{
+   int bw_index;
+   int port_id;
+   struct xhci_virt_device *virt_dev;
+
+   virt_dev = xhci->devs[udev->slot_id];
+   port_id = virt_dev->real_port;
+
+   if (udev->speed == USB_SPEED_SUPER) {
+   if (usb_endpoint_dir_out(&ep->desc))
+   bw_index = (port_id - 1) * 2;
+   else
+   bw_index = (port_id - 1) * 2 + 1;
+   } else {
+   bw_index = port_id + xhci->num_usb3_ports - 1;
+   }
+
+   return bw_index;
+}
+
+static void setup_sch_info(struct usb_device *udev,
+   struct xhci_ep_ctx *ep_ctx, struct mu3h_sch_ep_info *sch_ep)
+{
+   u32 ep_type;
+   u32 ep_interval;
+   u32 max_packet_size;
+   u32 max_burst;
+   u32 mult;
+   u32 esit_pkts;
+
+   ep_type = CTX_TO_EP_TYPE(le32_to_cpu(ep_ctx->ep_info2));
+   ep_interval = CTX_TO_EP_INTERVAL(le32_to_cpu(ep_ctx->ep_info));
+   max_packet_size = MAX_PACKET_DECODED(le32_to_cpu(ep_ctx->ep_info2));
+   max_burst = CTX_TO_MAX_BURST(le32_to_cpu(ep_ctx->ep_info2));
+   mult = CTX_TO_EP_MULT(le32_to_cpu(ep_ctx->ep_info));
+
+   sch_ep->ep_type = ep_type;
+   sch

Mediatek xHCI support

[Chunfeng Yun]

>From 5c00619366ce4e7ff2bad050697dd6b3294f38ec Mon Sep 17 00:00:00 2001
From: Chunfeng Yun 
Date: Fri, 7 Aug 2015 20:16:42 +0800
Subject: [PATCH v5 0/5]  Mediatek xHCI support

The patch supports MediaTek's xHCI controller.

There are some differences from xHCI spec:
1. The interval is specified in 250 * 8ns increments for Interrupt Moderation
Interval(IMODI) of the Interrupter Moderation(IMOD) register, it is 8 times as
much as that defined in xHCI spec.

2. For the value of TD Size in Normal TRB, MTK's xHCI controller defines a
number of packets that remain to be transferred for a TD after processing all
Max packets in all previous TRBs,that means don't include the current TRB's,
but in xHCI spec it includes the current ones.

3. To minimize the scheduling effort for synchronous endpoints in xHC, the MTK
architecture defines some extra SW scheduling parameters for HW. According to
these parameters provided by SW, the xHC can easily decide whether a
synchronous endpoint should be scheduled in a specific uFrame. The extra SW
scheduling parameters are put into reserved DWs in Slot and Endpoint Context.
And a bandwidth scheduler algorithm is added to support such feature.

A usb3.0 phy driver is also added which used by mt65xx SoCs platform, it
supports two usb2.0 ports and one usb3.0 port.

Change in v5:
1. descripte more exactly for each specifiers in xHCI binding
2. make use of new multi-phy feature for phy driver


Chunfeng Yun (5):
  dt-bindings: Add usb3.0 phy binding for MT65xx SoCs
  dt-bindings: Add a binding for Mediatek xHCI host controller
  usb: phy: add usb3.0 phy driver for mt65xx SoCs
  xhci: mediatek: support MTK xHCI host controller
  arm64: dts: mediatek: add xHCI & usb phy for mt8173

 .../devicetree/bindings/phy/phy-mt65xx-usb.txt |  69 ++
 .../devicetree/bindings/usb/mt8173-xhci.txt|  52 ++
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts|  16 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  44 ++
 drivers/phy/Kconfig|   9 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-mt65xx-usb3.c  | 467 
 drivers/usb/host/Kconfig   |   9 +
 drivers/usb/host/Makefile  |   4 +
 drivers/usb/host/xhci-mtk-sch.c| 436 +++
 drivers/usb/host/xhci-mtk.c| 837 +
 drivers/usb/host/xhci-mtk.h| 133 
 drivers/usb/host/xhci-ring.c   |  35 +-
 drivers/usb/host/xhci.c|  19 +-
 drivers/usb/host/xhci.h|   1 +
 15 files changed, 2125 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
 create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
 create mode 100644 drivers/phy/phy-mt65xx-usb3.c
 create mode 100644 drivers/usb/host/xhci-mtk-sch.c
 create mode 100644 drivers/usb/host/xhci-mtk.c
 create mode 100644 drivers/usb/host/xhci-mtk.h

--
1.8.1.1.dirty


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

[PATCH v5 3/5] usb: phy: add usb3.0 phy driver for mt65xx SoCs

[Chunfeng Yun]

support usb3.0 phy of mt65xx SoCs

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/Kconfig   |   9 +
 drivers/phy/Makefile  |   1 +
 drivers/phy/phy-mt65xx-usb3.c | 467 ++
 3 files changed, 477 insertions(+)
 create mode 100644 drivers/phy/phy-mt65xx-usb3.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index c0e6ede..019cf8b 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -193,6 +193,15 @@ config PHY_HIX5HD2_SATA
help
  Support for SATA PHY on Hisilicon hix5hd2 Soc.
 
+config PHY_MT65XX_USB3
+   tristate "Mediatek USB3.0 PHY Driver"
+   depends on ARCH_MEDIATEK && OF
+   select GENERIC_PHY
+   help
+ Say 'Y' here to add support for Mediatek USB3.0 PHY driver
+ for mt65xx SoCs. it supports two usb2.0 ports and
+ one usb3.0 port.
+
 config PHY_SUN4I_USB
tristate "Allwinner sunxi SoC USB PHY driver"
depends on ARCH_SUNXI && HAS_IOMEM && OF
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index f344e1b..3ceff2a 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_TI_PIPE3)+= 
phy-ti-pipe3.o
 obj-$(CONFIG_TWL4030_USB)  += phy-twl4030-usb.o
 obj-$(CONFIG_PHY_EXYNOS5250_SATA)  += phy-exynos5250-sata.o
 obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o
+obj-$(CONFIG_PHY_MT65XX_USB3)  += phy-mt65xx-usb3.o
 obj-$(CONFIG_PHY_SUN4I_USB)+= phy-sun4i-usb.o
 obj-$(CONFIG_PHY_SUN9I_USB)+= phy-sun9i-usb.o
 obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-exynos-usb2.o
diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
new file mode 100644
index 000..6835bff
--- /dev/null
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -0,0 +1,467 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Chunfeng Yun 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * for sifslv2 register, but exclude port's;
+ * relative to USB3_SIF2_BASE base address
+ */
+#define SSUSB_SIFSLV_SPLLC 0x
+
+/* offsets of sub-segment in each port registers */
+#define SSUSB_SIFSLV_U2PHY_COM_BASE0x
+#define SSUSB_SIFSLV_U3PHYD_BASE   0x0100
+#define SSUSB_USB30_PHYA_SIV_B_BASE0x0300
+#define SSUSB_SIFSLV_U3PHYA_DA_BASE0x0400
+
+#define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x)
+#define PA0_RG_U2PLL_FORCE_ON  BIT(15)
+
+#define U3P_USBPHYACR2 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0008)
+#define PA2_RG_SIF_U2PLL_FORCE_EN  BIT(18)
+
+#define U3P_USBPHYACR5 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014)
+#define PA5_RG_U2_HSTX_SRCTRL  (0x7 << 12)
+#define PA5_RG_U2_HSTX_SRCTRL_VAL(x)   ((0x7 & (x)) << 12)
+#define PA5_RG_U2_HS_100U_U3_ENBIT(11)
+
+#define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018)
+#define PA6_RG_U2_ISO_EN   BIT(31)
+#define PA6_RG_U2_BC11_SW_EN   BIT(23)
+#define PA6_RG_U2_OTG_VBUSCMP_EN   BIT(20)
+
+#define U3P_U2PHYACR4  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020)
+#define P2C_RG_USB20_GPIO_CTL  BIT(9)
+#define P2C_USB20_GPIO_MODEBIT(8)
+#define P2C_U2_GPIO_CTR_MSK(P2C_RG_USB20_GPIO_CTL | P2C_USB20_GPIO_MODE)
+
+#define U3D_U2PHYDCR0  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0060)
+#define P2C_RG_SIF_U2PLL_FORCE_ON  BIT(24)
+
+#define U3P_U2PHYDTM0  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0068)
+#define P2C_FORCE_UART_EN  BIT(26)
+#define P2C_FORCE_DATAIN   BIT(23)
+#define P2C_FORCE_DM_PULLDOWN  BIT(21)
+#define P2C_FORCE_DP_PULLDOWN  BIT(20)
+#define P2C_FORCE_XCVRSEL  BIT(19)
+#define P2C_FORCE_SUSPENDM BIT(18)
+#define P2C_FORCE_TERMSEL  BIT(17)
+#define P2C_RG_DATAIN  (0xf << 10)
+#define P2C_RG_DATAIN_VAL(x)   ((0xf & (x)) << 10)
+#define P2C_RG_DMPULLDOWN  BIT(7)
+#define P2C_RG_DPPULLDOWN  BIT(6)
+#define P2C_RG_XCVRSEL (0x3 << 4)
+#define P2C_RG_XCVRSEL_VAL(x)  ((0x3 & (x)) << 4)
+#define P2C_RG_SUSPENDMBIT(3)
+#define P2C_RG_TERMSEL BIT(2)
+#define P2C_DTM0_PART_MASK \
+   (P2C_FORCE_DATAIN | P2C_FORCE_DM_PULLDOWN | \
+   P2C_FORCE_DP_PULLDOWN | P2C_FORCE_XCVRSEL | \
+   P2C_FORCE_TERMSEL | P2C_RG_DMPULLDOWN | \
+   P2C_RG_DPPULLDOWN | P2C_

[PATCH v5 2/5] dt-bindings: Add a binding for Mediatek xHCI host controller

[Chunfeng Yun]

add a DT binding documentation of xHCI host controller for the
MT8173 SoC from Mediatek.

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/usb/mt8173-xhci.txt| 52 ++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt

diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
new file mode 100644
index 000..8e6e463
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -0,0 +1,52 @@
+mt65XX xHCI
+
+The device node for Mediatek SOC usb3.0 host controller
+
+Required properties:
+ - compatible : should contain "mediatek,mt8173-xhci"
+ - reg : specifies physical base address and size of the registers,
+   the first one for MAC, the second for IPPC
+ - interrupts : interrupt used by the controller
+ - power-domains : a phandle to USB power domain node to control usb's
+   mtcmos
+ - vusb33-supply : regulator of usb avdd3.3v
+
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+   entry in clock-names
+ - clock-names : must contain
+   "sys_ck": for clock of xHCI MAC
+   "wakeup_deb_p0": for usb wakeup debounce clock of port0
+   "wakeup_deb_p0": for usb wakeup debounce clock of port1
+
+ - phys : a list of phandle + phy specifier pairs
+ - usb3-lpm-capable : supports USB3 LPM
+ - mediatek,syscon-wakeup : phandle to syscon used to access usb wakeup
+   control register
+ - mediatek,wakeup-src : 1: ip sleep wakeup mode; 2: line state wakeup
+   mode; others means don't enable wakeup source of usb
+
+Optional properties:
+ - vbus-supply : Reference to the VBUS regulator;
+
+Example:
+usb30: usb@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x4000>,
+ <0 0x1128 0 0x0800>;
+   interrupts = ;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+   clocks = <&topckgen CLK_TOP_USB30_SEL>,
+<&pericfg CLK_PERI_USB0>,
+<&pericfg CLK_PERI_USB1>;
+   clock-names = "sys_ck",
+ "wakeup_deb_p0",
+ "wakeup_deb_p1";
+   phys = <&phy_port0 PHY_TYPE_USB3>,
+  <&phy_port1 PHY_TYPE_USB2>;
+   vusb33-supply = <&mt6397_vusb_reg>;
+   vbus-supply = <&usb_p1_vbus>;
+   usb3-lpm-capable;
+   mediatek,syscon-wakeup = <&pericfg>;
+   mediatek,wakeup-src = <1>;
+   status = "okay";
+};
-- 
1.8.1.1.dirty

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

[PATCH v5 1/5] dt-bindings: Add usb3.0 phy binding for MT65xx SoCs

[Chunfeng Yun]

add a DT binding documentation of usb3.0 phy for MT65xx
SoCs from Mediatek.

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/phy/phy-mt65xx-usb.txt | 69 ++
 1 file changed, 69 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
new file mode 100644
index 000..5812d20
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
@@ -0,0 +1,69 @@
+mt65xx USB3.0 PHY binding
+--
+
+This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
+
+Required properties (controller (parent) node):
+ - compatible  : should be "mediatek,mt8173-u3phy"
+ - reg : offset and length of register for phy, exclude port's
+ register.
+ - clocks  : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+ - clock-names : must contain
+ "u3phya_ref": for reference clock of usb3.0 analog phy.
+
+Required nodes : a sub-node is required for each port the controller
+ provides. Address range information including the usual
+ 'reg' property is used inside these nodes to describe
+ the controller's topology. These nodes are translated
+ by the driver's .xlate() function.
+
+Required properties (port (child) node):
+- reg  : address and length of the register set for the port.
+- #phy-cells   : should be 1 (See second example)
+ cell after port phandle is phy type from:
+   - PHY_TYPE_USB2
+   - PHY_TYPE_USB3
+
+Example:
+
+u3phy: usb-phy@1129 {
+   compatible = "mediatek,mt8173-u3phy";
+   reg = <0 0x1129 0 0x800>;
+   clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+   clock-names = "u3phya_ref";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "okay";
+
+   phy_port0: port@11290800 {
+   reg = <0 0x11290800 0 0x800>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+
+   phy_port1: port@11291000 {
+   reg = <0 0x11291000 0 0x800>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+};
+
+Specifying phy control of devices
+-
+
+Device nodes should specify the configuration required in their "phys"
+property, containing a phandle to the phy port node and a device type;
+phy-names for each port are optional.
+
+Example:
+
+#include 
+
+usb30: usb@1127 {
+   ...
+   phys = <&phy_port0 PHY_TYPE_USB3>;
+   phy-names = "usb3-0";
+   ...
+};
-- 
1.8.1.1.dirty

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

[PATCH v5 5/5] arm64: dts: mediatek: add xHCI & usb phy for mt8173

[Chunfeng Yun]

add xHCI and phy drivers for MT8173-EVB

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 16 +++
 arch/arm64/boot/dts/mediatek/mt8173.dtsi| 44 +
 2 files changed, 60 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index f433c21..112f3f3 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -13,6 +13,7 @@
  */
 
 /dts-v1/;
+#include 
 #include "mt8173.dtsi"
 
 / {
@@ -32,6 +33,15 @@
};
 
chosen { };
+
+   usb_p1_vbus: regulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "usb_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&pio 130 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
 };
 
 &pwrap {
@@ -211,3 +221,9 @@
 &uart0 {
status = "okay";
 };
+
+&usb30 {
+   vusb33-supply = <&mt6397_vusb_reg>;
+   vbus-supply = <&usb_p1_vbus>;
+   mediatek,wakeup-src = <1>;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 0696f8f..f88b2f9 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include "mt8173-pinfunc.h"
 
@@ -393,6 +395,48 @@
#size-cells = <0>;
status = "disabled";
};
+
+   usb30: usb@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x4000>,
+ <0 0x1128 0 0x0800>;
+   interrupts = ;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+   clocks = <&topckgen CLK_TOP_USB30_SEL>,
+<&pericfg CLK_PERI_USB0>,
+<&pericfg CLK_PERI_USB1>;
+   clock-names = "sys_ck",
+ "wakeup_deb_p0",
+ "wakeup_deb_p1";
+   phys = <&phy_port0 PHY_TYPE_USB3>,
+  <&phy_port1 PHY_TYPE_USB2>;
+   usb3-lpm-capable;
+   mediatek,syscon-wakeup = <&pericfg>;
+   status = "okay";
+   };
+
+   u3phy: usb-phy@1129 {
+   compatible = "mediatek,mt8173-u3phy";
+   reg = <0 0x1129 0 0x800>;
+   clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+   clock-names = "u3phya_ref";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "okay";
+
+   phy_port0: port@11290800 {
+   reg = <0 0x11290800 0 0x800>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+
+   phy_port1: port@11291000 {
+   reg = <0 0x11291000 0 0x800>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+   };
};
 };
 
-- 
1.8.1.1.dirty

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

Re: [PATCH 1/2] usb: gadget: goku_udc: fix build break by adding missing 'break'

[Robert Baldyga]

Hi Felipe,

I see that you already fixed this in your tree. So only the second patch
is needed.

Thanks,
Robert

On 08/07/2015 02:13 PM, Robert Baldyga wrote:
> Add missing break after 'default' label to fix compilation error.
> 
> Signed-off-by: Robert Baldyga 
> ---
>  drivers/usb/gadget/udc/goku_udc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/gadget/udc/goku_udc.c 
> b/drivers/usb/gadget/udc/goku_udc.c
> index 2b628b3..dbb51a4 100644
> --- a/drivers/usb/gadget/udc/goku_udc.c
> +++ b/drivers/usb/gadget/udc/goku_udc.c
> @@ -1013,6 +1013,7 @@ static struct usb_ep *goku_match_ep(struct usb_gadget 
> *g,
>   }
>   break;
>   default:
> + break;
>   }
>  
>   return NULL;
> 

--
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/2] usb: gadget: goku_udc: fix build break by adding missing 'break'

[Robert Baldyga]

Add missing break after 'default' label to fix compilation error.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/goku_udc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/gadget/udc/goku_udc.c 
b/drivers/usb/gadget/udc/goku_udc.c
index 2b628b3..dbb51a4 100644
--- a/drivers/usb/gadget/udc/goku_udc.c
+++ b/drivers/usb/gadget/udc/goku_udc.c
@@ -1013,6 +1013,7 @@ static struct usb_ep *goku_match_ep(struct usb_gadget *g,
}
break;
default:
+   break;
}
 
return NULL;
-- 
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/2] usb: musb: gadget: fix build break by adding missing 'break'

[Robert Baldyga]

Add missing break after 'default' label to fix compilation error.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/musb/musb_gadget.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 5f52bcb..31049d3 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1706,6 +1706,7 @@ static struct usb_ep *musb_match_ep(struct usb_gadget *g,
ep = gadget_find_ep_by_name(g, "ep2out");
break;
default:
+   break;
}
 
if (ep && usb_gadget_ep_match_desc(g, ep, desc, ep_comp))
-- 
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] usb: devio: fix spacing

[Kris Borer]

Fix two occurrences of the checkpatch.pl error:

ERROR: space prohibited before that ',' (ctx:WxW)

Fix one occurrence of the checkpatch error:

ERROR: space required before the open parenthesis '('

Signed-off-by: Kris Borer 
---
 drivers/usb/core/devio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index ed6d1d5..38ae877c 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -103,7 +103,7 @@ MODULE_PARM_DESC(usbfs_snoop, "true to log all usbfs 
traffic");
 #define snoop(dev, format, arg...) \
do {\
if (usbfs_snoop)\
-   dev_info(dev , format , ## arg);\
+   dev_info(dev, format, ## arg);  \
} while (0)
 
 enum snoop_when {
@@ -1321,7 +1321,7 @@ static int proc_do_submiturb(struct usb_dev_state *ps, 
struct usbdevfs_urb *uurb
is_in = (uurb->endpoint & USB_ENDPOINT_DIR_MASK) != 0;
 
u = 0;
-   switch(uurb->type) {
+   switch (uurb->type) {
case USBDEVFS_URB_TYPE_CONTROL:
if (!usb_endpoint_xfer_control(&ep->desc))
return -EINVAL;
-- 
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 v4 2/5] dt-bindings: Add a binding for Mediatek xHCI host controller

[chunfeng yun]

hi,

On Fri, 2015-07-31 at 14:45 +0100, Mark Rutland wrote:
> Hi,
> 
> Sorry for my late reply to a prior version of this series, but I still
> have concerns with some of the properties.
> 
> I'll repeat those below.
> 
> On Fri, Jul 31, 2015 at 02:03:53PM +0100, Chunfeng Yun wrote:
> > add a DT binding documentation of xHCI host controller for the
> > MT8173 SoC from Mediatek.
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  .../devicetree/bindings/usb/mt8173-xhci.txt| 51 
> > ++
> >  1 file changed, 51 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
> > b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > new file mode 100644
> > index 000..364be5a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > @@ -0,0 +1,51 @@
> > +MT65XX xhci
> > +
> > +The device node for Mediatek SOC usb3.0 host controller
> > +
> > +Required properties:
> > + - compatible : Supports "mediatek,mt8173-xhci"
> 
> s/Supports/should contain/
> 
done
> > + - reg : Specifies physical base address and size of the registers,
> > +   the first one for MAC, the second for IPPC
> > + - interrupts : Interrupt mode, number and trigger mode
> 
> Just specify what this logically corresponds to; the format of the
> interrupts proeprty depends on the interrupt controller.
> 
done
> > + - power-domains : To enable usb's mtcmos
> 
> Please describe what this contains. I assume you exped a single power
> domain to be described, covering the whole xHCI controller?
> 
> > + - vusb33-supply : Regulator of usb avdd3.3v
> > + - clocks : Must support all clocks that xhci needs
> 
> - clocks: a list of phandle + clock-specifier pairs, one for each entry
>   in clock-names.
> 
> > + - clock-names : Should be "sys_mac" for sys and mac clocks, and
> > +   "wakeup_deb_p0", "wakeup_deb_p1" for wakeup debounce control
> > +   clocks
> 
> This would be better as a list, e.g.
> 
> - clock-names: should contain:
>   * "sys_mac" 
>   * "wakeup_deb_p0" 
>   * "wakeup_deb_p1" 
> 
done
> Is sys_mac a single clock input line? Or is it jsut the case that a
> single line feeds two inputs currently? if the latter they should be
> separate entries.
> 
It is a single clock for usb MAC, already rename it

> > + - phys : List of PHY specifiers (used by generic PHY framework).
> 
> The bracketed part should go. The bidnigns should know nothing of Linux
> internals.
> 
remove it
> > + - phy-names : Must be "usb-phy0", "usb-phy1",.., "usb-phyN", based on
> > +   the number of PHYs as specified in @phys property.
> 
> This is useless.
> 
> You either don't need names, and can acquire the phys by index, or you
> need names which correspond to those on the data sheet for the xHCI
> controller.
> 
Ok, re-write the phy driver, and here also make use of the new format.

> > + - mediatek,usb-wakeup : To access usb wakeup control register
> 
> Please describe what this points to (I guess it's a syscon)/
> 
> > + - mediatek,wakeup-src : 1: Ip sleep wakeup mode; 2: line state wakeup
> > +   mode; others means don't enable wakeup source of usb
> 
> This sounds like a runtime decision.
> 
No, the driver do not know whether to enable wakeup function or not and
also don't know enable which one, except tell it. 
And it will set different registers of @mediatek,usb-wakeup to enable
the selected wakeup mode when system enter suspend.

> _why_ do you think this needs to be in the DT?
> 
> > + - mediatek,u2port-num : The number should not greater than the number
> > +   of phys
> 
> This is useless. Either this is implied by the entries in the phys
> property, or it should be a runtime decision.
> 
Yes, it can be calculated from @phys, already remove it.

Thanks a lot for your suggestion
 
> Thanks,
> Mark.
> 
> > +
> > +Optional properties:
> > + - vbus-supply : Reference to the VBUS regulator;
> > +
> > +Example:
> > +usb: usb@1127 {
> > +   compatible = "mediatek,mt8173-xhci";
> > +   reg = <0 0x1127 0 0x4000>,
> > + <0 0x1128 0 0x0800>;
> > +   interrupts = ;
> > +   power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
> > +   clocks = <&topckgen CLK_TOP_USB30_SEL>,
> > +<&pericfg CLK_PERI_USB0>,
> > +<&pericfg CLK_PERI_USB1>;
> > +   clock-names = "sys_mac",
> > + "wakeup_deb_p0",
> > + "wakeup_deb_p1";
> > +   phys = <&u3phy 0>, <&u3phy 1>;
> > +   phy-names = "usb-phy0", "usb-phy1";
> > +   vusb33-supply = <&mt6397_vusb_reg>;
> > +   vbus-supply = <&usb_p1_vbus>;
> > +   usb3-lpm-capable;
> > +   mediatek,usb-wakeup = <&pericfg>;
> > +   mediatek,wakeup-src = <1>;
> > +   mediatek,u2port-num = <2>;
> > +   status = "okay";
> > +};
> > -- 
> > 1.8.1.1.dirty
> > 


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

Re: USB - Generic Serial device : Unable to read more than 4095 bytes

[arun k]

Hi,

I am stuck with the above issue,
I have some doubts regarding USB - Generic driver
1. Could you please explain me why USB - Generic driver is slow ?
2. Now I am try to study USB - Generic driver implementation , I am
confused with the function usb_serial_generic_read_bulk_callback() ,
could you please tell me from where this function is calling ?
3. If you have any detailed doc regarding the implementation of USB -
Generic serial driver, Please send to me,

Regards,
Arun



On Thu, Aug 6, 2015 at 3:42 PM, arun k  wrote:
> / # lsusb -v
> Bus 002 Device 006: ID 045b:0218
> Bus 001 Device 001: ID 1d6b:0002
> Bus 002 Device 001: ID 1d6b:0001
> Bus 003 Device 001: ID 1d6b:0002
> Bus 004 Device 001: ID 1d6b:0003
>
> In this my device is
> Bus 002 Device 006: ID 045b:0218
>
> I enabled data dumping in usb_serial_generic_read_bulk_callback()
> function and found data received in this function is losing.
> In this function data is received as 64 bytes packets and two
> continuous 64 bytes having no data loss but the next packets are lost
> ie
> 1st packet ok(64 byte)
> 2nd packet ok(64 byte)
> .
> . packet lossing
> .
> 7th packet ok(64 byte)
> 8th packet ok(64 byte)
> .
> .
> In this way data loss is happening. Number of packets losing is
> different not constant always.
>
>>> I think the generic USB driver ignores baud rate. Like Greg suggested, 
>>> >>you need to
>>>use the proper driver for your hardware.
>
> I did't find any other suitable driver inside Linux.
> I checked this device in windows in that usbser.sys is detecting(.inf
> file is attached with the mail).
>
>  Could you suggest any available drivers for my device. Sorry I am
> very new to Linux drivers.
> I will post my USB device descriptor values below
>
> [ 1291.908071] ## udev->descriptor.bLength  0x12
> [ 1291.908089] ## udev->descriptor.bDescriptorType  0x1
> [ 1291.908147] ## udev->descriptor.bcdUSB  0x200
> [ 1291.908165] ## udev->descriptor.bDeviceClass  0xef
> [ 1291.908181] ## udev->descriptor.bDeviceSubClass  0x2
> [ 1291.908196] ## udev->descriptor.bDeviceProtocol  0x1
> [ 1291.908211] ## udev->descriptor.bMaxPacketSize0  0x40
> [ 1291.908226] ## udev->descriptor.idVendor  0x45b
> [ 1291.908241] ## udev->descriptor.idProduct  0x218
> [ 1291.908255] ## udev->descriptor.bcdDevice  0x1
> [ 1291.908270] ## udev->descriptor.iManufacturer  0x0
> [ 1291.908284] ## udev->descriptor.iProduct  0x0
> [ 1291.908298] ## udev->descriptor.iSerialNumber  0x0
> [ 1291.908313] ## udev->descriptor.bNumConfigurations  0x1
>
> Regards,
> Arun
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Aug 5, 2015 at 9:31 PM, Peter Hurley  wrote:
>> On 08/04/2015 11:57 PM, arun k wrote:
 Ok, but does the sending device know how to process in-band software flow 
 control
 and is it set up to respond properly?
>>>
>>> I am not sure about this. I need to check this.
>>>
 Also, I doubt software flow control is going to work @ 4Mbaud line rate.
 If you're stuck using software flow control, start with a 115kbaud line 
 rate
 and see if that fixes your data loss problem
>>>
>>> I tried B115200 also but issue is still there.
>>
>> I think the generic USB driver ignores baud rate. Like Greg suggested, you 
>> need to
>> use the proper driver for your hardware.
>>
>> What is the output from 'lsusb -v' and please identify in that output which
>> device you are using.
>>
>>> I am using a USB device and that sending data at a rate of *409600 
>>> bytes/sec*. Is this data rate have any relation with issue.
>>
>> Yes. Also, can you test this on a newer kernel like 3.18?
>>
>> Regards,
>> Peter Hurley
>>
>>> On Wed, Aug 5, 2015 at 11:24 AM, Peter Hurley >> > wrote:
>>>
>>> On 08/04/2015 10:00 PM, arun k wrote:
>>> > I enabled software flow control like below
>>> >
>>> > tty.c_iflag |= (IXON | IXOFF | IXANY);
>>>
>>> Ok, but does the sending device know how to process in-band software 
>>> flow control
>>> and is it set up to respond properly?
>>>
>>> Also, I doubt software flow control is going to work @ 4Mbaud line rate.
>>> If you're stuck using software flow control, start with a 115kbaud line 
>>> rate
>>> and see if that fixes your data loss problem.
>>>
>>> Regards,
>>> Peter Hurley
>>>
>>>
>>> > On Wed, Aug 5, 2015 at 12:59 AM, Peter Hurley 
>>> mailto:pe...@hurleysoftware.com>> wrote:
>>> >> On 08/03/2015 10:47 PM, arun k wrote:
>>> >>> Thank you for the reply
>>> >>>
>>> > The tty layer is limiting you, just keep reading in a loop until 
>>> you
>>> > run out of data, you should not ever expect to read a specific 
>>> number of
>>> > bytes from a tty device at a time, the read call will tell you the
>>> > number that was read properly.
>>> >>>
>>> >>> I tried this method but in my case I found data loss. By changing 
>>> any buffer size modification in driver side , can we fix this issue ?
>>> >>
>>> >> The data loss i

Values for SetHubDepth and GetPortErrorCount

[Tal Shorer]

In include/linux/usb/hcd.h, we have

/* class requests from USB 3.0 hub spec, table 10-5 */
#define SetHubDepth (0x3000 | HUB_SET_DEPTH)
#define GetPortErrorCount (0x8000 | HUB_GET_PORT_ERR_COUNT)

However, from the usb 3.1 spec I downloaded at
http://www.usb.org/developers/docs/,
table 10-5 appears to be unrelated (Table 10-5. Enhanced SuperSpeed
Hub Descriptor).
Table 10-7 (Table 10-7. Hub Class Requests) lists the two values as:
Request bmRequestType bRequest wValue wIndex wLength Data
SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of
Link Errors on this port

It appears the correct bmRequestType values should be:
#define SetHubDepth (0x2000 | HUB_SET_DEPTH)
#define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT)

Which are the bmRequestType values of SetHubFeature and GetPortStatus
(and friends).

These lines were introduced in
commit 0eadcc09203349b11ca477ec367079b23d32ab91
Author: Tatyana Brokhman 
Date:   Mon Nov 1 18:18:24 2010 +0200

usb: USB3.0 ch11 definitions

Adding hub SuperSpeed usb definitions as defined by ch10 of the USB3.0
spec.

Signed-off-by: Tatyana Brokhman 
Signed-off-by: Greg Kroah-Hartman 

The values are only used by dummy_hcd which does nothing with them and
by max3421-hcd which returns an error.
Can anyone clarify what I'm missing or if the values are actually wrong?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] gadget: Support for the usb charger framework

[Baolin Wang]

On 7 August 2015 at 17:07, Peter Chen  wrote:
>
>> >>  /**
>> >>   * struct usb_udc - describes one usb device controller @@ -127,12
>> >> +128,45 @@ void usb_gadget_giveback_request(struct usb_ep *ep,  }
>> >> EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
>> >>
>> >> +int usb_gadget_register_notify(struct usb_gadget *gadget,
>> >> +struct notifier_block *nb) {
>> >> + unsigned long flags;
>> >> + int ret;
>> >> +
>> >> + spin_lock_irqsave(&gadget->lock, flags);
>> >
>> > I find you use so many spin_lock_irqsave, any reasons for that?
>> > Why mutex_lock can't be used?
>> >
>>
>> The spin_lock_irqsave() can make it as a atomic notifier, that can make sure 
>> the
>> gadget state event can be quickly reported to the user who register a 
>> notifier
>> on the gadget device. Is it OK?
>>
>
> I don't think it is a good reason, spin_lock_irqsave is usually used for 
> protecting
> data which is accessed at atomic environment.
>

Yes, we want the notify process is a atomic environment which do not
want to be interrupted by irq or other things to make the notice can
be quickly reported to the user.

Also i think the notify process is less cost, thus i use the spinlock. Thanks.

> Peter



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

RE: [PATCH 2/2] gadget: Support for the usb charger framework

[Peter Chen]

 
> >>  /**
> >>   * struct usb_udc - describes one usb device controller @@ -127,12
> >> +128,45 @@ void usb_gadget_giveback_request(struct usb_ep *ep,  }
> >> EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
> >>
> >> +int usb_gadget_register_notify(struct usb_gadget *gadget,
> >> +struct notifier_block *nb) {
> >> + unsigned long flags;
> >> + int ret;
> >> +
> >> + spin_lock_irqsave(&gadget->lock, flags);
> >
> > I find you use so many spin_lock_irqsave, any reasons for that?
> > Why mutex_lock can't be used?
> >
> 
> The spin_lock_irqsave() can make it as a atomic notifier, that can make sure 
> the
> gadget state event can be quickly reported to the user who register a notifier
> on the gadget device. Is it OK?
> 

I don't think it is a good reason, spin_lock_irqsave is usually used for 
protecting
data which is accessed at atomic environment. 

Peter

Re: [PATCH 0/2] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

On 7 August 2015 at 16:31, Peter Chen  wrote:
>
>>
>> Peter, Thanks for your reviewing and comments. Now I just introduce the
>> framework to review for more feedbacks and do not have a useful user to use
>> it. I just can show you some example code to show how to use it. Thanks.
>>
>
> Felipe may not accept the code which are no user on it, I remember he said it 
> before.
> Besides, if no user on it, how you test it?
>

Make sense of it. I'll try to build the user to test it. Thanks for
your reminding.

> Peter



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

Re: [PATCH 2/2] gadget: Support for the usb charger framework

[Baolin Wang]

On 7 August 2015 at 13:45, Peter Chen  wrote:
> On Thu, Aug 06, 2015 at 03:03:49PM +0800, Baolin Wang wrote:
>> The usb charger framework is based on usb gadget, and each usb gadget
>> can be one usb charger to set the current limitation.
>>
>> This patch adds a notifier mechanism for usb charger to report to usb
>> charger when the usb gadget state is changed.
>>
>> Also we introduce a callback 'get_charger_type' which will implemented
>> by user for usb gadget operations to get the usb charger type.
>>
>> Signed-off-by: Baolin Wang 
>> ---
>>  drivers/usb/gadget/udc/udc-core.c |   41 
>> +
>>  include/linux/usb/gadget.h|   20 ++
>>  2 files changed, 61 insertions(+)
>>
>> diff --git a/drivers/usb/gadget/udc/udc-core.c 
>> b/drivers/usb/gadget/udc/udc-core.c
>> index d69c355..d5368088 100644
>> --- a/drivers/usb/gadget/udc/udc-core.c
>> +++ b/drivers/usb/gadget/udc/udc-core.c
>> @@ -28,6 +28,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  /**
>>   * struct usb_udc - describes one usb device controller
>> @@ -127,12 +128,45 @@ void usb_gadget_giveback_request(struct usb_ep *ep,
>>  }
>>  EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
>>
>> +int usb_gadget_register_notify(struct usb_gadget *gadget,
>> +struct notifier_block *nb)
>> +{
>> + unsigned long flags;
>> + int ret;
>> +
>> + spin_lock_irqsave(&gadget->lock, flags);
>
> I find you use so many spin_lock_irqsave, any reasons for that?
> Why mutex_lock can't be used?
>

The spin_lock_irqsave() can make it as a atomic notifier, that can
make sure the gadget state event can be quickly reported to the user
who register a notifier on the gadget device. Is it OK?

> --
>
> Best Regards,
> Peter Chen



-- 
Baolin.wang
Best 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: [linux-sunxi] [PATCH] musb: sunxi: Ignore VBus errors in host-only mode

[Olliver Schinagl]

Hey Hans,

On 06-08-15 16:35, Hans de Goede wrote:

Hi,

On 06-08-15 10:22, Olliver Schinagl wrote:

Hey Hans,

I've tried getting your musb stuff working on a cubietruck, but i 
don't seem to see this patch on your linux-sunxi/sunxi-wip branch on 
github? Is your github branch fully functional at the moment?


What I have done so far, is build the kernel using sunxi_defconfig 
and enabled USB_MUSB_SUNXI with its dependancies (musb isn't enabled 
there by default): USB_SUPPORT [=y] && USB_MUSB_HDRC [=y] && 
ARCH_SUNXI [=y] && NOP_USB_XCEIV [=y] && PHY_SUN4I_USB [=y] && EXTCON 
[=y] && GENERIC_PHY [=y]  Selects: SUNXI_SRAM [=y]


I changed the dts from dr_mode='otg' to dr_mode='host', a) we only 
need host mode anyway (the id pin isn't properly connected)


If you change the dr_mode to host then you _must_ also remove any 
id_det and vbus_det
gpio settings from the usb_phy node in the dts, as the sun4i phy code 
detects

host vs otg mode by checking for the presence of these.

Yes, this fixes it and makes it work. Thanks.

Also I apologize for not noticing this patch in your queue before :) 
Looks like everything is all ready in your WIP branch.


Now, I see that Chen-Yu found the same problems here:
http://permalink.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/17843

So far, with your mentioned changes to remove the id and vbus gpio's you 
can have my


Tested-by: Olliver Schinagl 



> and b) I got an error about an known dr_mode before and this was the 
quick and easy way.


Dmesg produces the following related to musb.

[1.691062] usb_phy_generic.0.auto supply vcc not found, using 
dummy regulator
[1.691445] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk 
combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)

[1.691453] musb-hdrc: MHDRC RTL version 0.0
[1.691467] musb-hdrc: 11/11 max ep, 5184/8192 memory
[1.691543] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
[1.691553] musb-hdrc musb-hdrc.1.auto: new USB bus registered, 
assigned bus number 5

[1.692470] hub 5-0:1.0: USB hub found
[1.692529] hub 5-0:1.0: 1 port detected
[1.699956] sunxi-rtc 1c20d00.rtc: setting system clock to 
2015-08-06 07:59:08 UTC (1438847948)

[1.704733] usb0-vbus: disabling
[1.765695] ldo4: disabling
[1.808351] ldo3: disabling
[1.848769] vcc5v0: disabling
[1.848774] vcc3v0: disabling

The usb_phy_generic missing shouldn't be too bad? But the usb0-vbus 
being disabled obviously might be related to the musb port not working?


Correct.

For starters I would try the dts changes I suggested above.

Yep that fixed it.


Regards,

Hans


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

Re: [PATCH 1/2] gadget: Introduce the usb charger framework

[Baolin Wang]

On 7 August 2015 at 13:41, Peter Chen  wrote:
> On Thu, Aug 06, 2015 at 03:03:48PM +0800, Baolin Wang wrote:
>> This patch introduces the usb charger driver based on usb gadget that
>> makes an enhancement to a power driver. It works well in practice but
>> that requires a system with suitable hardware.
>>
>> The basic conception of the usb charger is that, when one usb charger
>> is added or removed by reporting from the usb gadget state change or
>> the extcon device state change, the usb charger will report to power
>> user to set the current limitation.
>>
>> The usb charger will register notifiees on the usb gadget or the extcon
>> device to get notified the usb charger state.
>>
>> Power user will register a notifiee on the usb charger to get notified
>> by status changes from the usb charger. It will report to power user
>> to set the current limitation when detecting the usb charger is added
>> or removed from extcon device state or usb gadget state.
>>
>> Signed-off-by: Baolin Wang 
>> ---
>>  drivers/usb/gadget/charger.c|  547 
>> +++
>>  include/linux/usb/usb_charger.h |  101 
>>  2 files changed, 648 insertions(+)
>>  create mode 100644 drivers/usb/gadget/charger.c
>>  create mode 100644 include/linux/usb/usb_charger.h
>>
>> diff --git a/drivers/usb/gadget/charger.c b/drivers/usb/gadget/charger.c
>> new file mode 100644
>> index 000..3ca0180
>> --- /dev/null
>> +++ b/drivers/usb/gadget/charger.c
>> @@ -0,0 +1,547 @@
>> +/*
>> + * usb charger.c -- USB charger driver
>> + *
>> + * 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.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define DEFAULT_CUR_PROTECT  (50)
>> +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)
>> +#define DEFAULT_DCP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
>> +#define DEFAULT_CDP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
>> +#define DEFAULT_ACA_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
>> +
>> +static LIST_HEAD(usb_charger_list);
>> +static DEFINE_MUTEX(usb_charger_list_lock);
>> +
>> +/*
>> + * usb_charger_find_by_name - Get the usb charger device by name.
>> + * @name - usb charger device name.
>> + *
>> + * notes: when this function walks the list and returns a charger
>> + * it's dropped the lock which means that something else could come
>> + * along and delete the charger before we dereference the pointer.
>> + * It's very unlikely but it's a possibility so you should take care
>> + * of it.
>> + * Thus when you get the usb charger by name, you should call
>> + * put_usb_charger() to derease the reference count of the usb charger.
>> + *
>> + * return the instance of usb charger device.
>> + */
>> +struct usb_charger *usb_charger_find_by_name(char *name)
>> +{
>> + struct usb_charger *uchger;
>> +
>> + if (!name)
>> + return ERR_PTR(-EINVAL);
>> +
>> + mutex_lock(&usb_charger_list_lock);
>> + list_for_each_entry(uchger, &usb_charger_list, entry) {
>> + if (!strcmp(uchger->name, name)) {
>> + get_usb_charger(uchger);
>> + mutex_unlock(&usb_charger_list_lock);
>> + return uchger;
>> + }
>> + }
>> + mutex_unlock(&usb_charger_list_lock);
>> +
>> + return NULL;
>> +}
>> +
>> +/*
>> + * usb_charger_register_notify() - Register a notifiee to get notified by
>> + *   any attach status changes from the usb charger type detection.
>> + * @uchger - the usb charger device which is monitored.
>> + * @nb - a notifier block to be registered.
>> + */
>> +void usb_charger_register_notify(struct usb_charger *uchger,
>> +  struct notifier_block *nb)
>> +{
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&uchger->lock, flags);
>> + raw_notifier_chain_register(&uchger->uchger_nh, nb);
>> + spin_unlock_irqrestore(&uchger->lock, flags);
>> +}
>> +
>> +/*
>> + * usb_charger_unregister_notify() - Unregister a notifiee from the usb 
>> charger.
>> + * @uchger - the usb charger device which is monitored.
>> + * @nb - a notifier block to be unregistered.
>> + */
>> +void usb_charger_unregister_notify(struct usb_charger *uchger,
>> +struct notifier_block *nb)
>> +{
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&uchger->lock, flags);
>> + raw_notifier_chain_unregister(&uchger->uchger_nh, nb);
>> + spin_unlock_irqrestore(&uchger->lock, flags);
>> +}
>> +
>> +/*
>> + * usb_charger_register_extcon_notifier() - Register a notifiee of the usb
>> + *   

RE: [PATCH 0/2] Introduce usb charger framework to deal with the usb gadget power negotation

[Peter Chen]

 
> 
> Peter, Thanks for your reviewing and comments. Now I just introduce the
> framework to review for more feedbacks and do not have a useful user to use
> it. I just can show you some example code to show how to use it. Thanks.
> 

Felipe may not accept the code which are no user on it, I remember he said it 
before.
Besides, if no user on it, how you test it?

Peter
N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

[PATCH v3 08/10] Doc: usb: ci-hdrc-usb2: add tx(rx)-burst-config-dword for binding doc

[Peter Chen]

It is used to override the default setting for burst size, changing
burst size takes effect only when the SBUSCFG.AHBBRST = 0.

Signed-off-by: Peter Chen 
---
 Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt 
b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
index d52a747..d71ef07 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
@@ -37,6 +37,14 @@ Optional properties:
   property is used to change AHB burst configuration, check the chipidea
   spec for meaning of each value. If this property is not existed, it
   will use the reset value.
+- tx-burst-size-dword: it is vendor dependent, the tx burst size in dword
+  (4 bytes), This register represents the maximum length of a the burst
+  in 32-bit words while moving data from system memory to the USB
+  bus, changing this value takes effect only the SBUSCFG.AHBBRST is 0.
+- rx-burst-size-dword: it is vendor dependent, the rx burst size in dword
+  (4 bytes), This register represents the maximum length of a the burst
+  in 32-bit words while moving data from the USB bus to system memory,
+  changing this value takes effect only the SBUSCFG.AHBBRST is 0.
 
 Example:
 
@@ -51,4 +59,6 @@ Example:
gadget-itc-setting = <0x4>; /* 4 micro-frames */
 /* Incremental burst of unspecified length */
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>; /* 64 bytes */
+   rx-burst-size-dword = <0x10>;
};
-- 
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 v3 06/10] usb: chipidea: add ahb burst configuration interface

[Peter Chen]

The users can change it through dts or platform data if they
want to change the default value.

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/bits.h  |  3 +++
 drivers/usb/chipidea/core.c  | 14 ++
 include/linux/usb/chipidea.h |  2 ++
 3 files changed, 19 insertions(+)

diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index 831a8f6..462ad02 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -25,6 +25,9 @@
 #define VERSION  (0xF << 25)
 #define CIVERSION(0x7 << 29)
 
+/* SBUSCFG */
+#define AHBBRST_MASK   0x7
+
 /* HCCPARAMS */
 #define HCCPARAMS_LEN BIT(17)
 
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 97f937f..bde49f3 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -438,6 +438,9 @@ void ci_platform_configure(struct ci_hdrc *ci)
 
hw_write(ci, OP_USBCMD, 0xff, ci->platdata->itc_setting << 16);
 
+   if (ci->platdata->flags & CI_HDRC_OVERRIDE_AHB_BURST)
+   hw_write_id_reg(ci, ID_SBUSCFG, AHBBRST_MASK,
+   ci->platdata->ahb_burst_config);
 }
 
 /**
@@ -646,6 +649,17 @@ static int ci_get_platdata(struct device *dev,
}
}
 
+   if (of_find_property(dev->of_node, "ahb-burst-config", NULL)) {
+   ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
+   &platdata->ahb_burst_config);
+   if (ret) {
+   dev_err(dev,
+   "failed to get ahb-burst-config\n");
+   return ret;
+   }
+   platdata->flags |= CI_HDRC_OVERRIDE_AHB_BURST;
+   }
+
return 0;
 }
 
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 034f7e1..fe3c8eb 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -33,6 +33,7 @@ struct ci_hdrc_platform_data {
 #define CI_HDRC_FORCE_FULLSPEEDBIT(6)
 #define CI_HDRC_TURN_VBUS_EARLY_ON BIT(7)
 #define CI_HDRC_SET_NON_ZERO_TTHA  BIT(8)
+#define CI_HDRC_OVERRIDE_AHB_BURST BIT(9)
enum usb_dr_modedr_mode;
 #define CI_HDRC_CONTROLLER_RESET_EVENT 0
 #define CI_HDRC_CONTROLLER_STOPPED_EVENT   1
@@ -42,6 +43,7 @@ struct ci_hdrc_platform_data {
booltpl_support;
/* interrupt threshold setting */
u32 itc_setting;
+   u32 ahb_burst_config;
 };
 
 /* Default offset of capability registers */
-- 
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 v3 02/10] usb: chipidea: define stream mode disable for both roles

[Peter Chen]

The system bus and chipidea IP have different limitations for
both host and device mode.
For example, with below errata, we need to enable SDIS(Stream Disable
Mode) at host mode. But we don't want it for device mode at the
same system.

TAR 9000378958
Title: Non-Double Word Aligned Buffer Address Sometimes Causes Host to
Hang on OUT Retry
Impacted Configuration: Host mode, all transfer types
Description:
The host core operating in streaming mode may under run while sending
the data packet of an OUT transaction. This under run can occur if
there are unexpected system delays in fetching the remaining packet
data from memory. The host forces a bad CRC on the packet, the device
detects the error and discards the packet. The host then retries a Bulk,
Interrupt, or Control transfer if an under run occurs according to the
USB specification. During simulations, it was found that the host does
not issue the retry of the failed bulk OUT. It does not issue any other
transactions except SOF packets that have incorrect frame numbers.

The second failure mode occurs if the under run occurs on an ISO OUT
transaction and the next ISO transaction is a zero byte packet. The host
does not issue any transactions (including SOFs). The device detects a
Suspend condition, reverts to full speed, and waits for resume signaling.

A third failure mode occurs when the host under runs on an ISO OUT and
the next ISO in the schedule is an ISO OUT with two max packets of 1024
bytes each. The host should issue MDATA for the first OUT followed by
DATA1 for the second. However, it drops the MDATA transaction, and
issues the DATA1 transaction.

The system impact of this bug is the same regardless of the failure mode
observed. The host core hangs, the ehci_ctrl state machine waits for the
protocol engine to send the completion status for the corrupted
transaction, which never occurs. No indication is sent to the host
controller driver, no register bits change and no interrupts occur.
Eventually the requesting application times out.

Detailed internal behavior:
The EHCI control state machine (ehci_ctrl) in the DMA block is responsible
for parsing the schedules and initiating all transactions. The ehci_ctrl
state machine passes the transaction details to the protocol block by
writing the transaction information in to the TxFIFO. It then asserts
the pe_hst_run_pkt signal to inform the host protocol state machine
(pe_hst_state) that there is a packet in the TxFIFO.
A tag of 0x0 indicates a start of packet with the data providing the
following information:

35:32 Tag
31:30 Reserved
29:23 Endpoint (lowest 4 bits)
22:16 Address
15:10 Reserved
9:8 Endpoint speed
7:6 Endpoint type
5:6 Data Toggle
3:0 PID
The pe_hst_state reads the packet information and constructs the packet
and issues it to the PHY interface.
The ehci_ctrl state machine writes the start transaction information in
to the TxFIFO as 0x03002910c for the OUT packet that had the under run
error. However, it writes 0xC3002910C for the retry of the Out
transaction, which is incorrect.
The pe_hst_state enters a bus timeout state after sending the bad CRC
for the packet that under ran. It then purges any data that was back
filled in to the TxFIFO for the packet that under ran. The pe_hst_state
machine stops purging the TxFIFO when it is empty or if it reads a
location that has a tag of 0x0, indicating a start of packet command.

The pe_hst_state reads 0xC3002910C and discards it as it does not decode
to a start of packet command. It continues to purge the OUT data that
has been pre-buffered for the OUT retry . The pe_hst_state detects the
hst_packet_run signal and attempts to read the PID and address
information from the TxFIFO. This location has packet data and so does
not decode to a valid PID and so falls through to the PE_HST_SOF_LOAD
state where the frame_num_counter is updated. The frame_num_counter
is updated with the data in the TxFIFO. In this case, the data is
incorrect as the ehci_ctrl state machine did not initiate the load.
The hst_pe_state machine detects the SOF request signal and sends an
SOF with the bad frame number. Meanwhile, the ehci_ctrl state machine
waits indefinitely in the run_pkt state waiting for the completion
status from pe_hst_state machine, which will never happen.

The ISO failure case is similar except that there is no retry for ISO.
The ehci_ctrl state machine moves to the next transfer in the periodic
schedule. If the under run occurs on the last entry of the periodic
list then it moves to the Async schedule.

In the case of ISO OUT simulations, the next ISO is a zero byte OUT
and again the start of packet command gets corrupted. The TxFIFO is
empty when the hst_pe_state attempts to read the Address and PID
information as the transaction is a zero byte packet. This results
in the hst_pe_state machine staying in the GET_PID state, which means
that it does not issue any transactions (including SOFs). The device
detects a Suspend condition and reverts to full s

Re: [PATCH 6/7] phy: omap-usb2: Add a new compatible string for USB2 PHY2

[Roger Quadros]

On 05/08/15 17:18, Kishon Vijay Abraham I wrote:
> Hi Roger,
> 
> On Wednesday 05 August 2015 01:55 PM, Roger Quadros wrote:
>> On 05/08/15 11:23, Roger Quadros wrote:
>>>
>>> On 04/08/15 18:20, Kishon Vijay Abraham I wrote:
 The USB2 PHY2 has a different register map compared to USB2 PHY1
 to power on/off the PHY. In order to handle it, add a new
 "compatible" string.

 Signed-off-by: Kishon Vijay Abraham I 
 ---
  Documentation/devicetree/bindings/phy/ti-phy.txt |2 ++
  drivers/phy/phy-omap-usb2.c  |9 +
  2 files changed, 11 insertions(+)

 diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
 b/Documentation/devicetree/bindings/phy/ti-phy.txt
 index 49e5b0c..a061077 100644
 --- a/Documentation/devicetree/bindings/phy/ti-phy.txt
 +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
 @@ -31,6 +31,8 @@ OMAP USB2 PHY
  
  Required properties:
   - compatible: Should be "ti,omap-usb2"
 + Should be "ti,dra7x-usb2-phy2" for the 2nd instance of USB2 PHY
 + in DRA7x
   - reg : Address and length of the register set for the device.
   - #phy-cells: determine the number of cells that should be given in the
 phandle while referencing this phy.
 diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
 index b5c266a..2f7220f 100644
 --- a/drivers/phy/phy-omap-usb2.c
 +++ b/drivers/phy/phy-omap-usb2.c
 @@ -159,6 +159,11 @@ static const struct usb_phy_data dra7x_usb2_data = {
.flags = OMAP_USB2_CALIBRATE_FALSE_DISCONNECT,
  };
  
 +static const struct usb_phy_data dra7x_usb2_phy2_data = {
 +  .label = "dra7x_usb2_phy2",
 +  .flags = OMAP_USB2_CALIBRATE_FALSE_DISCONNECT,
 +};
 +
  static const struct usb_phy_data am437x_usb2_data = {
.label = "am437x_usb2",
.flags =  0,
 @@ -178,6 +183,10 @@ static const struct of_device_id omap_usb2_id_table[] 
 = {
.data = &dra7x_usb2_data,
},
{
 +  .compatible = "ti,dra7x-usb2-phy2",
 +  .data = &dra7x_usb2_phy2_data,
>>>
>>> Why is this needed? You can reuse dra7x_usb2_data as is.
>>
>> OK. I see why we need it in the next patch.
>> Probably both patches could be squashed.
>>
>> What does .label indicate?
> 
> it's actually used only in usb_add_phy() (drivers/usb/phy/phy.c). I don't 
> think
> it's actually important unless you strongly feel so.

I leave it to you then :).

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

[PATCH v3 09/10] ARM: imx6: change default burst size for USB

[Peter Chen]

It can improve the USB performance when choosing larger
burst size at some systems (bus size is larger), there is
no side effect if this burst size is larger than bus size.

Signed-off-by: Peter Chen 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 8 
 arch/arm/boot/dts/imx6sl.dtsi  | 6 ++
 arch/arm/boot/dts/imx6sx.dtsi  | 6 ++
 3 files changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 42d62b0..b9f2e3a 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -854,6 +854,8 @@
fsl,usbphy = <&usbphy1>;
fsl,usbmisc = <&usbmisc 0>;
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
@@ -866,6 +868,8 @@
fsl,usbmisc = <&usbmisc 1>;
dr_mode = "host";
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
@@ -877,6 +881,8 @@
fsl,usbmisc = <&usbmisc 2>;
dr_mode = "host";
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
@@ -888,6 +894,8 @@
fsl,usbmisc = <&usbmisc 3>;
dr_mode = "host";
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 066fac9..627549f 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -689,6 +689,8 @@
fsl,usbphy = <&usbphy1>;
fsl,usbmisc = <&usbmisc 0>;
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
@@ -700,6 +702,8 @@
fsl,usbphy = <&usbphy2>;
fsl,usbmisc = <&usbmisc 1>;
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
@@ -711,6 +715,8 @@
fsl,usbmisc = <&usbmisc 2>;
dr_mode = "host";
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 3656a1d..6844e9e 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -747,6 +747,8 @@
fsl,usbmisc = <&usbmisc 0>;
fsl,anatop = <&anatop>;
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
@@ -758,6 +760,8 @@
fsl,usbphy = <&usbphy2>;
fsl,usbmisc = <&usbmisc 1>;
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
@@ -771,6 +775,8 @@
fsl,anatop = <&anatop>;
dr_mode = "host";
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@v

[PATCH v3 10/10] usb: chipidea: add tx/rx burst size configuration interface

[Peter Chen]

The user can adjust it through dts or platform data

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/bits.h  |  4 
 drivers/usb/chipidea/ci.h|  1 +
 drivers/usb/chipidea/core.c  | 35 +++
 include/linux/usb/chipidea.h |  4 
 4 files changed, 44 insertions(+)

diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index 462ad02..e462f55 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -61,6 +61,10 @@
 /* Set non-zero value for internal TT Hub address representation */
 #define TTCTRL_TTHA(0x7fUL << 24)
 
+/* BURSTSIZE */
+#define RX_BURST_MASK  0xff
+#define TX_BURST_MASK  0xff00
+
 /* PORTSC */
 #define PORTSC_CCSBIT(0)
 #define PORTSC_CSCBIT(1)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index b562544..41d7cf6 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -51,6 +51,7 @@ enum ci_hw_regs {
OP_DEVICEADDR,
OP_ENDPTLISTADDR,
OP_TTCTRL,
+   OP_BURSTSIZE,
OP_PORTSC,
OP_DEVLC,
OP_OTGSC,
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index bde49f3..3feebf7 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -86,6 +86,7 @@ static const u8 ci_regs_nolpm[] = {
[OP_DEVICEADDR] = 0x14U,
[OP_ENDPTLISTADDR]  = 0x18U,
[OP_TTCTRL] = 0x1CU,
+   [OP_BURSTSIZE]  = 0x20U,
[OP_PORTSC] = 0x44U,
[OP_DEVLC]  = 0x84U,
[OP_OTGSC]  = 0x64U,
@@ -109,6 +110,7 @@ static const u8 ci_regs_lpm[] = {
[OP_DEVICEADDR] = 0x14U,
[OP_ENDPTLISTADDR]  = 0x18U,
[OP_TTCTRL] = 0x1CU,
+   [OP_BURSTSIZE]  = 0x20U,
[OP_PORTSC] = 0x44U,
[OP_DEVLC]  = 0x84U,
[OP_OTGSC]  = 0xC4U,
@@ -441,6 +443,17 @@ void ci_platform_configure(struct ci_hdrc *ci)
if (ci->platdata->flags & CI_HDRC_OVERRIDE_AHB_BURST)
hw_write_id_reg(ci, ID_SBUSCFG, AHBBRST_MASK,
ci->platdata->ahb_burst_config);
+
+   /* override burst size, take effect only when ahb_burst_config is 0 */
+   if (!hw_read_id_reg(ci, ID_SBUSCFG, AHBBRST_MASK)) {
+   if (ci->platdata->flags & CI_HDRC_OVERRIDE_TX_BURST)
+   hw_write(ci, OP_BURSTSIZE, TX_BURST_MASK,
+   ci->platdata->tx_burst_size << __ffs(TX_BURST_MASK));
+
+   if (ci->platdata->flags & CI_HDRC_OVERRIDE_RX_BURST)
+   hw_write(ci, OP_BURSTSIZE, RX_BURST_MASK,
+   ci->platdata->rx_burst_size);
+   }
 }
 
 /**
@@ -660,6 +673,28 @@ static int ci_get_platdata(struct device *dev,
platdata->flags |= CI_HDRC_OVERRIDE_AHB_BURST;
}
 
+   if (of_find_property(dev->of_node, "tx-burst-size-dword", NULL)) {
+   ret = of_property_read_u32(dev->of_node, "tx-burst-size-dword",
+   &platdata->tx_burst_size);
+   if (ret) {
+   dev_err(dev,
+   "failed to get tx-burst-size-dword\n");
+   return ret;
+   }
+   platdata->flags |= CI_HDRC_OVERRIDE_TX_BURST;
+   }
+
+   if (of_find_property(dev->of_node, "rx-burst-size-dword", NULL)) {
+   ret = of_property_read_u32(dev->of_node, "rx-burst-size-dword",
+   &platdata->rx_burst_size);
+   if (ret) {
+   dev_err(dev,
+   "failed to get rx-burst-size-dword\n");
+   return ret;
+   }
+   platdata->flags |= CI_HDRC_OVERRIDE_RX_BURST;
+   }
+
return 0;
 }
 
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index fe3c8eb..a41833c 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -34,6 +34,8 @@ struct ci_hdrc_platform_data {
 #define CI_HDRC_TURN_VBUS_EARLY_ON BIT(7)
 #define CI_HDRC_SET_NON_ZERO_TTHA  BIT(8)
 #define CI_HDRC_OVERRIDE_AHB_BURST BIT(9)
+#define CI_HDRC_OVERRIDE_TX_BURST  BIT(10)
+#define CI_HDRC_OVERRIDE_RX_BURST  BIT(11)
enum usb_dr_modedr_mode;
 #define CI_HDRC_CONTROLLER_RESET_EVENT 0
 #define CI_HDRC_CONTROLLER_STOPPED_EVENT   1
@@ -44,6 +46,8 @@ struct ci_hdrc_platform_data {
/* interrupt threshold setting */
u32 itc_setting;
u32 ahb_burst_config;
+   u32 tx_burst_size;
+   u32 rx_burst_size;
 };
 
 /* Default offset of capability registers */
-- 
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 majo

[PATCH v3 03/10] usb: chipidea: imx: add stream mode enable for device mode at imx6sl/imx6sx

[Peter Chen]

Stream mode enable is known for better performance, this stream mode
enable patch has been passed with stress tests at device mode for
imx6sl and imx6sx, and no issue is found.

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 6d2a85a..3f41679 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -29,26 +29,31 @@ struct ci_hdrc_imx_platform_flag {
 };
 
 static const struct ci_hdrc_imx_platform_flag imx27_usb_data = {
+   CI_HDRC_DISABLE_STREAMING,
 };
 
 static const struct ci_hdrc_imx_platform_flag imx28_usb_data = {
.flags = CI_HDRC_IMX28_WRITE_FIX |
-   CI_HDRC_TURN_VBUS_EARLY_ON,
+   CI_HDRC_TURN_VBUS_EARLY_ON |
+   CI_HDRC_DISABLE_STREAMING,
 };
 
 static const struct ci_hdrc_imx_platform_flag imx6q_usb_data = {
.flags = CI_HDRC_SUPPORTS_RUNTIME_PM |
-   CI_HDRC_TURN_VBUS_EARLY_ON,
+   CI_HDRC_TURN_VBUS_EARLY_ON |
+   CI_HDRC_DISABLE_STREAMING,
 };
 
 static const struct ci_hdrc_imx_platform_flag imx6sl_usb_data = {
.flags = CI_HDRC_SUPPORTS_RUNTIME_PM |
-   CI_HDRC_TURN_VBUS_EARLY_ON,
+   CI_HDRC_TURN_VBUS_EARLY_ON |
+   CI_HDRC_DISABLE_HOST_STREAMING,
 };
 
 static const struct ci_hdrc_imx_platform_flag imx6sx_usb_data = {
.flags = CI_HDRC_SUPPORTS_RUNTIME_PM |
-   CI_HDRC_TURN_VBUS_EARLY_ON,
+   CI_HDRC_TURN_VBUS_EARLY_ON |
+   CI_HDRC_DISABLE_HOST_STREAMING,
 };
 
 static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
@@ -126,8 +131,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
struct ci_hdrc_platform_data pdata = {
.name   = dev_name(&pdev->dev),
.capoffset  = DEF_CAPOFFSET,
-   .flags  = CI_HDRC_DISABLE_STREAMING |
-   CI_HDRC_SET_NON_ZERO_TTHA,
+   .flags  = CI_HDRC_SET_NON_ZERO_TTHA,
};
int ret;
const struct of_device_id *of_id =
-- 
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 v3 07/10] usb: chipidea: usbmisc_imx: add non-burst setting for imx6

[Peter Chen]

With this setting and AHBBRST at SBUSCFG as "Incremental burst of
unspecified length", each non-burst size can be taken as single
transfer. It is benefit for non-burst size transfer.

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/usbmisc_imx.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/chipidea/usbmisc_imx.c 
b/drivers/usb/chipidea/usbmisc_imx.c
index 3cefd49..5ddab30 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -54,6 +54,7 @@
 #define MX53_USB_PHYCTRL1_PLLDIV_MASK  0x3
 #define MX53_USB_PLL_DIV_24_MHZ0x01
 
+#define MX6_BM_NON_BURST_SETTING   BIT(1)
 #define MX6_BM_OVER_CUR_DISBIT(7)
 #define MX6_BM_WAKEUP_ENABLE   BIT(10)
 #define MX6_BM_ID_WAKEUP   BIT(16)
@@ -255,14 +256,21 @@ static int usbmisc_imx6q_init(struct imx_usbmisc_data 
*data)
if (data->index > 3)
return -EINVAL;
 
+   spin_lock_irqsave(&usbmisc->lock, flags);
+
if (data->disable_oc) {
-   spin_lock_irqsave(&usbmisc->lock, flags);
reg = readl(usbmisc->base + data->index * 4);
writel(reg | MX6_BM_OVER_CUR_DIS,
usbmisc->base + data->index * 4);
-   spin_unlock_irqrestore(&usbmisc->lock, flags);
}
 
+   /* SoC non-burst setting */
+   reg = readl(usbmisc->base + data->index * 4);
+   writel(reg | MX6_BM_NON_BURST_SETTING,
+   usbmisc->base + data->index * 4);
+
+   spin_unlock_irqrestore(&usbmisc->lock, flags);
+
usbmisc_imx6q_set_wakeup(data, false);
 
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

[PATCH v3 01/10] usb: chipidea: udc: zero-length packet is only needed for TX

[Peter Chen]

The zero-length packet is the sendor tells the receiver that there
is no more data, so it is only needed at the TX side.

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/udc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 2a47720..15f55da 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -445,7 +445,7 @@ static int _hardware_enqueue(struct ci_hw_ep *hwep, struct 
ci_hw_req *hwreq)
rest -= count;
}
 
-   if (hwreq->req.zero && hwreq->req.length
+   if (hwreq->req.zero && hwreq->req.length && hwep->dir == TX
&& (hwreq->req.length % hwep->ep.maxpacket == 0))
add_td_to_list(hwep, hwreq, 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

[PATCH v3 04/10] Doc: usb: ci-hdrc-usb2: add ahb-burst-config for binding doc

[Peter Chen]

It is used to change ahb burst configuration for platforms, it is
vendor specific.

Signed-off-by: Peter Chen 
---
 Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt 
b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
index 4159c8c..d52a747 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
@@ -32,6 +32,11 @@ Optional properties:
 - external-vbus-divider: (FSL only) enables off-chip resistor divider for Vbus
 - itc-setting: interrupt threshold control register control, the setting
   should be aligned with ITC bits at register USBCMD.
+- ahb-burst-config: it is vendor dependent, the required value should be
+  aligned with AHBBRST at SBUSCFG, the range is from 0x0 to 0x7. This
+  property is used to change AHB burst configuration, check the chipidea
+  spec for meaning of each value. If this property is not existed, it
+  will use the reset value.
 
 Example:
 
@@ -44,4 +49,6 @@ Example:
phy-names = "usb-phy";
vbus-supply = <®_usb0_vbus>;
gadget-itc-setting = <0x4>; /* 4 micro-frames */
+/* Incremental burst of unspecified length */
+   ahb-burst-config = <0x0>;
};
-- 
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 v3 00/10] USB: chipidea misc patches

[Peter Chen]

Hi all,

In this series, I add several new interfaces for chipidea driver,
they are mainly for system configuration adjustment. The USB
performance may be improved with these configuration changing,
but each vendor driver owner needs to consult with your IC
owner which configuration parameters are suitable for your system
before changing it, and only change it if necessary.

The other changes are for imx, it shows how imx uses these interfaces.
Shawn, the patch [5/10] and [9/10] are dts changes, help to review it
please.

Changes for v3:
- Improve the binding doc according to Rob's comment [Patch 4/10, 8/10]

Changes for v2:
- Use the bit fields which are not used. [Patch 2/10, 6/10, 10/10]
- According to Greg and Sascha comments, format patch 2/10's
  commit log.
- using non-burst instead of unburst for patch 7/10

Peter Chen (10):
  usb: chipidea: udc: zero-length packet is only needed for TX
  usb: chipidea: define stream mode disable for both roles
  usb: chipidea: imx: add stream mode enable for device mode at
imx6sl/imx6sx
  Doc: usb: ci-hdrc-usb2: add ahb-burst-config for binding doc
  ARM: imx6: set ahb-burst-config as 0 for USB
  usb: chipidea: add ahb burst configuration interface
  usb: chipidea: usbmisc_imx: add non-burst setting for imx6
  Doc: usb: ci-hdrc-usb2: add tx(rx)-burst-config-dword for binding doc
  ARM: imx6: change default burst size for USB
  usb: chipidea: add tx/rx burst size configuration interface

 .../devicetree/bindings/usb/ci-hdrc-usb2.txt   | 17 ++
 arch/arm/boot/dts/imx6qdl.dtsi | 12 +
 arch/arm/boot/dts/imx6sl.dtsi  |  9 
 arch/arm/boot/dts/imx6sx.dtsi  |  9 
 drivers/usb/chipidea/bits.h|  7 +++
 drivers/usb/chipidea/ci.h  |  1 +
 drivers/usb/chipidea/ci_hdrc_imx.c | 16 +++---
 drivers/usb/chipidea/core.c| 62 +-
 drivers/usb/chipidea/udc.c |  2 +-
 drivers/usb/chipidea/usbmisc_imx.c | 12 -
 include/linux/usb/chipidea.h   | 11 +++-
 11 files changed, 147 insertions(+), 11 deletions(-)

-- 
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 v3 05/10] ARM: imx6: set ahb-burst-config as 0 for USB

[Peter Chen]

After setting ahb burst configuration as 0, we can increase tx/rx
burst size, it will improve the USB performance

Signed-off-by: Peter Chen 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 4 
 arch/arm/boot/dts/imx6sl.dtsi  | 3 +++
 arch/arm/boot/dts/imx6sx.dtsi  | 3 +++
 3 files changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index e6d1359..42d62b0 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -853,6 +853,7 @@
clocks = <&clks IMX6QDL_CLK_USBOH3>;
fsl,usbphy = <&usbphy1>;
fsl,usbmisc = <&usbmisc 0>;
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
@@ -864,6 +865,7 @@
fsl,usbphy = <&usbphy2>;
fsl,usbmisc = <&usbmisc 1>;
dr_mode = "host";
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
@@ -874,6 +876,7 @@
clocks = <&clks IMX6QDL_CLK_USBOH3>;
fsl,usbmisc = <&usbmisc 2>;
dr_mode = "host";
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
@@ -884,6 +887,7 @@
clocks = <&clks IMX6QDL_CLK_USBOH3>;
fsl,usbmisc = <&usbmisc 3>;
dr_mode = "host";
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index a78e715..066fac9 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -688,6 +688,7 @@
clocks = <&clks IMX6SL_CLK_USBOH3>;
fsl,usbphy = <&usbphy1>;
fsl,usbmisc = <&usbmisc 0>;
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
@@ -698,6 +699,7 @@
clocks = <&clks IMX6SL_CLK_USBOH3>;
fsl,usbphy = <&usbphy2>;
fsl,usbmisc = <&usbmisc 1>;
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
@@ -708,6 +710,7 @@
clocks = <&clks IMX6SL_CLK_USBOH3>;
fsl,usbmisc = <&usbmisc 2>;
dr_mode = "host";
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 708175d..3656a1d 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -746,6 +746,7 @@
fsl,usbphy = <&usbphy1>;
fsl,usbmisc = <&usbmisc 0>;
fsl,anatop = <&anatop>;
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
@@ -756,6 +757,7 @@
clocks = <&clks IMX6SX_CLK_USBOH3>;
fsl,usbphy = <&usbphy2>;
fsl,usbmisc = <&usbmisc 1>;
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
@@ -768,6 +770,7 @@
phy_type = "hsic";
fsl,anatop = <&anatop>;
dr_mode = "host";
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
-- 
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 0/2] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

On 7 August 2015 at 13:34, Peter Chen  wrote:
> On Thu, Aug 06, 2015 at 03:03:47PM +0800, Baolin Wang wrote:
>> Currently the Linux kernel does not provide any standard integration of this
>> feature that integrates the USB subsystem with the system power regulation
>> provided by PMICs meaning that either vendors must add this in their kernels
>> or USB gadget devices based on Linux (such as mobile phones) may not behave
>> as they should.
>>
>> Providing a standard framework for doing this in the kernel.
>
> Baolin, thanks for introducing a framework for doing it, we do support
> USB Charger for chipidea driver at internal tree, but it is specific
> for imx, and still have some problems to upstream due to need to
> change some common code.
>
> One suggestion, would you add your user next time? In that case, we can
> know better for this framework.
>

Peter, Thanks for your reviewing and comments. Now I just introduce
the framework to review for more feedbacks and do not have a useful
user to use it. I just can show you some example code to show how to
use it. Thanks.

>>
>> Baolin Wang (2):
>>   gadget: Introduce the usb charger framework
>>   gadget: Support for the usb charger framework
>>
>>  drivers/usb/gadget/charger.c  |  547 
>> +
>>  drivers/usb/gadget/udc/udc-core.c |   41 +++
>>  include/linux/usb/gadget.h|   20 ++
>>  include/linux/usb/usb_charger.h   |  101 +++
>>  4 files changed, 709 insertions(+)
>>  create mode 100644 drivers/usb/gadget/charger.c
>>  create mode 100644 include/linux/usb/usb_charger.h
>>
>> --
>> 1.7.9.5
>>
>
> --
>
> Best Regards,
> Peter Chen



-- 
Baolin.wang
Best 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