RE: [PATCH 2/3] usb: dwc3: host: Do not use dma_set_coherent_mask

[Sriram Dash]

>From: Arnd Bergmann [mailto:a...@arndb.de]
>On Tuesday, October 25, 2016 4:26:27 PM CEST Sriram Dash wrote:
>> Do not require dma_set_coherent_mask for hcd
>>
>> Signed-off-by: Arnd Bergmann 
>
>Aside from the comments I had for patch 3, you are doing two different things
>here:
>
>> diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
>> index 89a2f71..4d7439c 100644
>> --- a/drivers/usb/dwc3/dwc3-st.c
>> +++ b/drivers/usb/dwc3/dwc3-st.c
>> @@ -218,7 +218,6 @@ static int st_dwc3_probe(struct platform_device *pdev)
>>  if (IS_ERR(regmap))
>>  return PTR_ERR(regmap);
>>
>> -dma_set_coherent_mask(dev, dev->coherent_dma_mask);
>>  dwc3_data->dev = dev;
>>  dwc3_data->regmap = regmap;
>>
>
>This one was setting the mask for the device itself (incorrectly), so it can be
>removed along with the dma_coerce_mask_and_coherent() call in
>dwc3_exynos_probe, or as a separate patch. It is an independent cleanup.
>
>> --- a/drivers/usb/chipidea/core.c
>> +++ b/drivers/usb/chipidea/core.c
>> @@ -833,9 +833,6 @@ struct platform_device *ci_hdrc_add_device(struct
>> device *dev,
>>
>> -dma_set_coherent_mask(>dev, dev->coherent_dma_mask);
>>
>>  ret = platform_device_add_resources(pdev, res, nres);
>>  if (ret)
>
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -1059,12 +1059,6 @@ static int dwc3_probe(struct platform_device
>> *pdev)
>>
>>  spin_lock_init(>lock);
>>
>> -dma_set_coherent_mask(dev, dev->parent-
>>coherent_dma_mask);
>
>> --- a/drivers/usb/dwc3/host.c
>> +++ b/drivers/usb/dwc3/host.c
>> @@ -72,11 +72,7 @@ int dwc3_host_init(struct dwc3 *dwc)
>>  return -ENOMEM;
>>  }
>>
>> -dma_set_coherent_mask(>dev, dwc->dev->coherent_dma_mask);
>> -
>
>These three all set the mask for the *child* devices, as that is no longer 
>needed
>after the change in patch 1/3.
>I'd suggest leaving those changes together with the rest of that patch.
>
>However, it's probably better to split up that patch along the boundaries of 
>the
>drivers, starting with the USB core:
>

Ok. Will do the needful in the next version.

>1/4 usb: separate out sysdev pointer from usb_bus
>2/4 usb: chipidea: use bus->sysdev for DMA configuration
>3/4 usb: xhci: use bus->sysdev for DMA configuration
>4/4 usb: dwc3: use bus->sysdev for DMA configuration
>
>   Arnd
--
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] Staging: wilc1000: Remove unused structure

[Greg KH]

On Wed, Oct 26, 2016 at 11:00:07PM +0300, Muraru Mihaela wrote:
> On Tue, Oct 25, 2016 at 08:37:50AM +0200, Greg KH wrote:
> > On Mon, Oct 24, 2016 at 10:56:45PM +0300, Mihaela Muraru wrote:
> > > This is a parch to the emxx_udc.c file that remove the
> > > 'usb_device_descriptor' structure because it is not used in the current
> > > file or in other one.
> > > 
> > > Signed-off-by: Mihaela Muraru 
> > > ---
> > >  drivers/staging/emxx_udc/emxx_udc.c | 19 ---
> > >  1 file changed, 19 deletions(-)
> > 
> > Why did you send this to the linux-usb mailing list?  Didn't
> > scripts/get_maintainer.pl give you a proper list to use?
> 
> Because the only mail address  that I receive from scripts/get_maintainer.pl 
> it 
> is yours, and I can't send it only to you I need a mail list. 
> 
> Can you help me with this?

Really?  get_maintainer.pl works for me here:

$ ./scripts/get_maintainer.pl --file drivers/staging/emxx_udc/emxx_udc.c
Greg Kroah-Hartman  (supporter:STAGING 
SUBSYSTEM,commit_signer:12/12=100%)
Arnd Bergmann  
(commit_signer:2/12=17%,authored:2/12=17%,added_lines:37/89=42%,removed_lines:9/86=10%)
Felipe Balbi  (commit_signer:1/12=8%)
Janani Ravichandran  
(commit_signer:1/12=8%,authored:1/12=8%,added_lines:7/89=8%)
Anjali Menon  
(commit_signer:1/12=8%,added_lines:18/89=20%,removed_lines:20/86=23%)
Rehas Sachdeva  (authored:1/12=8%)
Anson Jacob  (authored:1/12=8%)
Sandhya Bankar  (authored:1/12=8%)
Dilek Uzulmez  
(added_lines:10/89=11%,removed_lines:10/86=12%)
Gargi Sharma  (added_lines:8/89=9%,removed_lines:7/86=8%)
Geliang Tang  (removed_lines:25/86=29%)
de...@driverdev.osuosl.org (open list:STAGING SUBSYSTEM)
linux-ker...@vger.kernel.org (open list)


See that line describing the devel@driverdev mailing list?  That's the right
one to use...  Or, you can look in the MAINTAINERS file itself which says:
STAGING SUBSYSTEM
M:  Greg Kroah-Hartman 
T:  git 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
L:  de...@driverdev.osuosl.org
S:  Supported
F:  drivers/staging/

Nothing talks about linux-usb@vger at all, how did you get this list for this
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: [PATCH v2 2/4] usb: musb: core: added helper function for parsing DT

[David Lechner]

On 10/26/2016 10:03 AM, Alexandre Bailon wrote:

From: Petr Kulhavy 

This adds the function musb_get_mode() to get the DT property "dr_mode"

Signed-off-by: Petr Kulhavy 
Acked-by: Sergei Shtylyov 
Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/musb_core.c | 19 +++
 drivers/usb/musb/musb_core.h |  5 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 27dadc0..bba07e7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "musb_core.h"
 #include "musb_trace.h"
@@ -130,6 +131,24 @@ static inline struct musb *dev_to_musb(struct device *dev)
return dev_get_drvdata(dev);
 }

+enum musb_mode musb_get_mode(struct device *dev)
+{
+   enum usb_dr_mode mode;
+
+   mode = usb_get_dr_mode(dev);
+   switch (mode) {
+   case USB_DR_MODE_HOST:
+   return MUSB_HOST;
+   case USB_DR_MODE_PERIPHERAL:
+   return MUSB_PERIPHERAL;
+   case USB_DR_MODE_OTG:
+   case USB_DR_MODE_UNKNOWN:
+   default:
+   return MUSB_OTG;
+   }
+}
+EXPORT_SYMBOL_GPL(musb_get_mode);
+
 /*-*/

 #ifndef CONFIG_BLACKFIN
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 2cb88a49..a406468 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -617,4 +617,9 @@ static inline void musb_platform_post_root_reset_end(struct 
musb *musb)
musb->ops->post_root_reset_end(musb);
 }

+/* gets the "dr_mode" property from DT and converts it into musb_mode
+ * if the property is not found or not recognized returns MUSB_OTG
+ */
+extern enum musb_mode musb_get_mode(struct device *dev);
+
 #endif /* __MUSB_CORE_H__ */



Tested working on LEGO MINDSTORMS EV3 using dr_mode = "peripheral" and 
no vbus-supply.


Tested-By: David Lechner 
--
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 3/4] usb: musb: da8xx: Add DT support for the DA8xx driver

[David Lechner]

On 10/26/2016 10:03 AM, Alexandre Bailon wrote:

From: Petr Kulhavy 

This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver

Signed-off-by: Petr Kulhavy 
Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/da8xx.c | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 210b7e4..bfa571d 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -6,6 +6,9 @@
  * Based on the DaVinci "glue layer" code.
  * Copyright (C) 2005-2006 by Texas Instruments
  *
+ * DT support
+ * Copyright (c) 2016 Petr Kulhavy 
+ *
  * This file is part of the Inventra Controller Driver for Linux.
  *
  * The Inventra Controller Driver for Linux is free software; you
@@ -433,6 +436,21 @@ static int da8xx_musb_exit(struct musb *musb)
return 0;
 }

+static inline u8 get_vbus_power(struct device *dev)
+{
+   struct regulator *vbus_supply;
+   int current_uA;
+
+   vbus_supply = regulator_get_optional(dev, "vbus");
+   if (IS_ERR(vbus_supply))
+   return 255;
+   current_uA = regulator_get_current_limit(vbus_supply);
+   regulator_put(vbus_supply);
+   if (current_uA <= 0 || current_uA > 51)
+   return 255;
+   return current_uA / 1000 / 2;
+}
+
 static const struct musb_platform_ops da8xx_ops = {
.quirks = MUSB_DMA_CPPI | MUSB_INDEXED_EP,
.init   = da8xx_musb_init,
@@ -458,6 +476,12 @@ static const struct platform_device_info da8xx_dev_info = {
.dma_mask   = DMA_BIT_MASK(32),
 };

+static const struct musb_hdrc_config da8xx_config = {
+   .ram_bits = 10,
+   .num_eps = 5,
+   .multipoint = 1,
+};
+
 static int da8xx_probe(struct platform_device *pdev)
 {
struct resource musb_resources[2];
@@ -465,7 +489,9 @@ static int da8xx_probe(struct platform_device *pdev)
struct da8xx_glue   *glue;
struct platform_device_info pinfo;
struct clk  *clk;
+   struct device_node  *np = pdev->dev.of_node;
int ret;
+   struct resource *res;


res is not used anywhere



glue = devm_kzalloc(>dev, sizeof(*glue), GFP_KERNEL);
if (!glue)
@@ -486,6 +512,18 @@ static int da8xx_probe(struct platform_device *pdev)
glue->dev= >dev;
glue->clk= clk;

+   if (IS_ENABLED(CONFIG_OF) && np) {
+   pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   /* FIXME */


Why FIXME? I don't see anything that needs to be fixed here.


+   return -ENOMEM;
+   }
+
+   pdata->config= _config;
+   pdata->mode  = musb_get_mode(>dev);
+   pdata->power = get_vbus_power(>dev);
+   }
+
pdata->platform_ops  = _ops;

glue->usb_phy = usb_phy_generic_register();
@@ -536,11 +574,20 @@ static int da8xx_remove(struct platform_device *pdev)
return 0;
 }



Shouldn't you have #ifdef CONFIG_OF here since you are using 
of_match_ptr() below?



+static const struct of_device_id da8xx_id_table[] = {
+   {
+   .compatible = "ti,da830-musb",
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, da8xx_id_table);


#endif


+
 static struct platform_driver da8xx_driver = {
.probe  = da8xx_probe,
.remove = da8xx_remove,
.driver = {
.name   = "musb-da8xx",
+   .of_match_table = of_match_ptr(da8xx_id_table),
},
 };




Tested working on LEGO MINDSTORMS EV3 using dr_mode = "peripheral" and 
no vbus-supply.


Tested-By: David Lechner 

--
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: OHCI: make ohci-da8xx a separate driver

[David Lechner]

On 10/26/2016 04:08 PM, ahas...@baylibre.com wrote:

From: Manjunath Goudar 

Separate the Davinci OHCI host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM

Signed-off-by: Manjunath Goudar 
[Axel: adapted and rebased, fixed minor comments]
Signed-off-by: Axel Haslam 
---


This is working for me as a module on LEGO MINDSTORMS EV3.

Tested-By: David Lechner 

--
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: OHCI: make ohci-da8xx a separate driver

[David Lechner]

On 10/26/2016 04:08 PM, ahas...@baylibre.com wrote:


+module_exit(ohci_da8xx_exit);
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:ohci");


The "ohci" in MODULE_ALIAS() should also be replaced with hcd_name.


--
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 13/15] Documentation: devicetree: dwc2: Add host DMA binding

[Rob Herring]

On Wed, Oct 19, 2016 at 06:22:52PM -0700, John Youn wrote:
> Add the host-dma property to devicetree. This controls whether to use
> DMA in host mode.
> 
> Signed-off-by: John Youn 
> ---
>  Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt 
> b/Documentation/devicetree/bindings/usb/dwc2.txt
> index 2c30a54..17f7624 100644
> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
> @@ -25,6 +25,7 @@ Optional properties:
>  Refer to phy/phy-bindings.txt for generic phy consumer properties
>  - dr_mode: shall be one of "host", "peripheral" and "otg"
>Refer to usb/generic.txt
> +- host-dma: turn on or off host buffer DMA (1 or 0).

Why not boolean? Seems like disabling would be rare, so name the 
property something like host-dma-disable. Also, it needs a vendor 
prefix.

Rob
--
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: OHCI: make ohci-da8xx a separate driver

[ahaslam]

From: Manjunath Goudar 

Separate the Davinci OHCI host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM

Signed-off-by: Manjunath Goudar 
[Axel: adapted and rebased, fixed minor comments]
Signed-off-by: Axel Haslam 
---

This was a previews patch submited by Manjunath [1]
that was never taken in because of an undefined symbol
when loading as a module. That symbol is not present anymore
so we can safly build the driver as a module.

I rebased, fixing the minor remaining comments.

Axel.
http://patches.linaro.org/patch/18234/

 drivers/usb/host/Kconfig  |   4 +-
 drivers/usb/host/Makefile |   1 +
 drivers/usb/host/ohci-da8xx.c | 181 +-
 drivers/usb/host/ohci-hcd.c   |  18 -
 4 files changed, 74 insertions(+), 130 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 83b6cec..6361fc7 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -479,9 +479,9 @@ config USB_OHCI_HCD_OMAP3
  OMAP3 and later chips.
 
 config USB_OHCI_HCD_DAVINCI
-   bool "OHCI support for TI DaVinci DA8xx"
+   tristate "OHCI support for TI DaVinci DA8xx"
depends on ARCH_DAVINCI_DA8XX
-   depends on USB_OHCI_HCD=y
+   depends on USB_OHCI_HCD
select PHY_DA8XX_USB
default y
help
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 6ef785b..2644537 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_USB_OHCI_HCD_AT91)   += ohci-at91.o
 obj-$(CONFIG_USB_OHCI_HCD_S3C2410) += ohci-s3c2410.o
 obj-$(CONFIG_USB_OHCI_HCD_LPC32XX) += ohci-nxp.o
 obj-$(CONFIG_USB_OHCI_HCD_PXA27X)  += ohci-pxa27x.o
+obj-$(CONFIG_USB_OHCI_HCD_DAVINCI) += ohci-da8xx.o
 
 obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 3656d7c..4e2a61f 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -11,16 +11,30 @@
  * kind, whether express or implied.
  */
 
+#include 
+#include 
 #include 
 #include 
+#include 
+#include 
 #include 
-#include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
-#ifndef CONFIG_ARCH_DAVINCI_DA8XX
-#error "This file is DA8xx bus glue.  Define CONFIG_ARCH_DAVINCI_DA8XX."
-#endif
+#include "ohci.h"
+
+#define DRIVER_DESC "DA8XX"
+
+static const char hcd_name[] = "ohci";
+
+static struct hc_driver __read_mostly ohci_da8xx_hc_driver;
+
+static int (*orig_ohci_hub_control)(struct usb_hcd  *hcd, u16 typeReq,
+   u16 wValue, u16 wIndex, char *buf, u16 wLength);
+static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
 
 static struct clk *usb11_clk;
 static struct phy *usb11_phy;
@@ -74,7 +88,7 @@ static void ohci_da8xx_ocic_handler(struct 
da8xx_ohci_root_hub *hub,
hub->set_power(port, 0);
 }
 
-static int ohci_da8xx_init(struct usb_hcd *hcd)
+static int ohci_da8xx_reset(struct usb_hcd *hcd)
 {
struct device *dev  = hcd->self.controller;
struct da8xx_ohci_root_hub *hub = dev_get_platdata(dev);
@@ -94,7 +108,7 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
 */
ohci->num_ports = 1;
 
-   result = ohci_init(ohci);
+   result = ohci_setup(hcd);
if (result < 0) {
ohci_da8xx_disable();
return result;
@@ -122,30 +136,12 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
return result;
 }
 
-static void ohci_da8xx_stop(struct usb_hcd *hcd)
-{
-   ohci_stop(hcd);
-   ohci_da8xx_disable();
-}
-
-static int ohci_da8xx_start(struct usb_hcd *hcd)
-{
-   struct ohci_hcd *ohci   = hcd_to_ohci(hcd);
-   int result;
-
-   result = ohci_run(ohci);
-   if (result < 0)
-   ohci_da8xx_stop(hcd);
-
-   return result;
-}
-
 /*
  * Update the status data from the hub with the over-current indicator change.
  */
 static int ohci_da8xx_hub_status_data(struct usb_hcd *hcd, char *buf)
 {
-   int length  = ohci_hub_status_data(hcd, buf);
+   int length  = orig_ohci_hub_status_data(hcd, buf);
 
/* See if we have OCIC bit set on port 1 */
if (ocic_mask & (1 << 1)) {
@@ -227,66 +223,13 @@ static int ohci_da8xx_hub_control(struct usb_hcd *hcd, 
u16 typeReq, u16 wValue,
}
}
 
-   return ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+   return orig_ohci_hub_control(hcd, typeReq, wValue,
+   wIndex, buf, wLength);
 }
 
-static const struct hc_driver ohci_da8xx_hc_driver = {
-   .description= hcd_name,
-   .product_desc   = "DA8xx OHCI",
-   .hcd_priv_size  = 

Re: [PATCH] phy: Add reset callback for not generic phy

[Kishon Vijay Abraham I]

On Wednesday 26 October 2016 02:17 AM, John Youn wrote:
> On 10/25/2016 7:15 AM, Randy Li wrote:
>> I forget to add a dummy function in case the CONFIG_GENERIC_PHY
>> is disabled.
>>
>> Signed-off-by: Randy Li 
> 
> Fixes: cac18ecb6f44 ("phy: Add reset callback")
> Tested-by: John Youn 
> 
> Hi Kishon,
> 
> Can you take this for 4.9-rc?

sure, merged now.

Thanks
Kishon

> 
> Thanks,
> John
> 
> 
> 
>> ---
>>  include/linux/phy/phy.h | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
>> index ee1bed7..78bb0d7 100644
>> --- a/include/linux/phy/phy.h
>> +++ b/include/linux/phy/phy.h
>> @@ -253,6 +253,13 @@ static inline int phy_set_mode(struct phy *phy, enum 
>> phy_mode mode)
>>  return -ENOSYS;
>>  }
>>  
>> +static inline int phy_reset(struct phy *phy)
>> +{
>> +if (!phy)
>> +return 0;
>> +return -ENOSYS;
>> +}
>> +
>>  static inline int phy_get_bus_width(struct phy *phy)
>>  {
>>  return -ENOSYS;
>>
>>
> 
> 
> 
--
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] Staging: wilc1000: Remove unused structure

[Muraru Mihaela]

On Tue, Oct 25, 2016 at 08:37:50AM +0200, Greg KH wrote:
> On Mon, Oct 24, 2016 at 10:56:45PM +0300, Mihaela Muraru wrote:
> > This is a parch to the emxx_udc.c file that remove the
> > 'usb_device_descriptor' structure because it is not used in the current
> > file or in other one.
> > 
> > Signed-off-by: Mihaela Muraru 
> > ---
> >  drivers/staging/emxx_udc/emxx_udc.c | 19 ---
> >  1 file changed, 19 deletions(-)
> 
> Why did you send this to the linux-usb mailing list?  Didn't
> scripts/get_maintainer.pl give you a proper list to use?

Because the only mail address  that I receive from scripts/get_maintainer.pl it 
is yours, and I can't send it only to you I need a mail list. 

Can you help me with this?

thanks,

mihaela

> Please fix up and resend.
> 
> 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 2/4] USB: ch341: reinitialize chip on reconfiguration

[Aidan Thornton]

On Mon, Oct 24, 2016 at 4:24 PM, Johan Hovold  wrote:
> On Sat, Oct 22, 2016 at 10:14:21PM +0100, Aidan Thornton wrote:
>> Sent, but please pay close attention to the new note in patch 2 about
>> higher baud rates. It turns out the timings for baud rates above 500kbaud
>> are out of spec. This isn't a regression on the CH340G - they're exactly
>> the same before and after, so far as I can tell - but it might be on the
>> CH341 if baud rate setting worked better there before. Grigori might have
>> to take a look at that. Sorry for the inconvenience. (I'm not sure an
>> in-spec 576kbaud is even possible on the CH340G.)
>
> Thanks for pointing that out. According to the datasheets these devices
> are supposed to support rates up to 2 Mbaud, but perhaps the
> (reverse-engineered?) baud-rate algorithm is still too limited.
>
> I'm inclined to just merge these and try to deal with any potential fall
> out later. I've asked Winchiphead if they can provide some further
> insight. Let's see how it goes.

Thanks for the merge! Hopefully there shouldn't be any major fallout
(touch wood). I think it's just a rounding error in the calculation -
after looking at the datasheet it doesn't list 576000 as supported,
which is probably why that's not possible - but the fix wasn't
immediately obvious
--
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] usb: musb: remove duplicated actions

[Kirill Esipov]

Removing unnecessary duplicated actions that we've got while merging:
19915e623458 ("Merge 4.1-rc7 into usb-next")

Signed-off-by: Kirill Esipov 
---
 drivers/usb/musb/musb_core.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 27dadc0..e01116e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2114,11 +2114,6 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
musb->io.ep_offset = musb_flat_ep_offset;
musb->io.ep_select = musb_flat_ep_select;
}
-   /* And override them with platform specific ops if specified. */
-   if (musb->ops->ep_offset)
-   musb->io.ep_offset = musb->ops->ep_offset;
-   if (musb->ops->ep_select)
-   musb->io.ep_select = musb->ops->ep_select;
 
/* At least tusb6010 has its own offsets */
if (musb->ops->ep_offset)
-- 
2.7.4

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

Re: [PATCH v2 2/3] phy: da8xx-usb: Configure CFGCHIP2 to support OTG workaround

[Alexandre Bailon]

On 10/26/2016 05:40 PM, David Lechner wrote:
> On 10/26/2016 05:58 AM, Alexandre Bailon wrote:
>> If we configure the da8xx OTG phy in OTG mode, neither device or host
>> mode will work. That is because the PHY is not able to detect and notify
>> the driver that value of ID pin changed.
>> To work despite this hardware limitation, the da8xx glue implement a
>> workaround.
>> But to work, the workaround require the VBUS sense and the session end
>> comparator to enabled.
>> Enable them if the phy is configured in OTG mode.
>>
>> Signed-off-by: Alexandre Bailon 
>> ---
>>  drivers/phy/phy-da8xx-usb.c | 17 -
>>  1 file changed, 12 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
>> index 32ae78c..fd39292 100644
>> --- a/drivers/phy/phy-da8xx-usb.c
>> +++ b/drivers/phy/phy-da8xx-usb.c
>> @@ -93,24 +93,31 @@ static int da8xx_usb20_phy_power_off(struct phy *phy)
>>  static int da8xx_usb20_phy_set_mode(struct phy *phy, enum phy_mode mode)
>>  {
>>  struct da8xx_usb_phy *d_phy = phy_get_drvdata(phy);
>> +int ret;
>>  u32 val;
>>
>> +ret = regmap_read(d_phy->regmap, CFGCHIP(2), );
>> +if (ret)
>> +return ret;
>> +
>> +val &= ~CFGCHIP2_OTGMODE_MASK;
>> +
>>  switch (mode) {
>>  case PHY_MODE_USB_HOST:/* Force VBUS valid, ID = 0 */
>> -val = CFGCHIP2_OTGMODE_FORCE_HOST;
>> +val |= CFGCHIP2_OTGMODE_FORCE_HOST;
>>  break;
>>  case PHY_MODE_USB_DEVICE:/* Force VBUS valid, ID = 1 */
>> -val = CFGCHIP2_OTGMODE_FORCE_DEVICE;
>> +val |= CFGCHIP2_OTGMODE_FORCE_DEVICE;
>>  break;
>>  case PHY_MODE_USB_OTG:/* Don't override the VBUS/ID
>> comparators */
>> -val = CFGCHIP2_OTGMODE_NO_OVERRIDE;
>> +val |= CFGCHIP2_OTGMODE_NO_OVERRIDE |
>> +CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN;
> 
> The AM1808 TRM indicates that CFGCHIP2_SESENDEN and CFGCHIP2_VBDTCTEN
> (and CFGCHIP2_DATPOL) should be on for normal operation of the USB 2.0
> PHY. They do not appear to be associated with the OTG mode specifically.
I agree but the function assigned to these bit is highly tied to OTG.
And in TI BSP, there is a comment that let me think that is only needed
for OTG.
/*
 * We have to override VBUS/ID signals when MUSB is configured into the
 * host-only mode -- ID pin will float if no cable is connected, so the
 * controller won't be able to drive VBUS thinking that it's a B-device.
 * Otherwise, we want to use the OTG mode and enable VBUS comparators.
 */
cfgchip2 &= ~CFGCHIP2_OTGMODE;
#ifdef  CONFIG_USB_MUSB_HOST
cfgchip2 |=  CFGCHIP2_FORCE_HOST;
#else
cfgchip2 |=  CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN;
#endif
> 
> It seems to me that it would be more appropriate to set these in
> da8xx_usb20_phy_power_on() instead of here in da8xx_usb20_phy_set_mode().
I tried both the phy forced in device or host mode with theses bit set
or clear and I haven't see any issues, so I think we could set them in
da8xx_usb20_phy_power_on() as you suggested.
> 
> 
>>  break;
>>  default:
>>  return -EINVAL;
>>  }
>>
>> -regmap_write_bits(d_phy->regmap, CFGCHIP(2), CFGCHIP2_OTGMODE_MASK,
>> -  val);
>> +regmap_write(d_phy->regmap, CFGCHIP(2), val);
>>
>>  return 0;
>>  }
>>
> 
> Also cc'ing phy maintainer since this is a phy driver.
> 
> 

--
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 2/3] phy: da8xx-usb: Configure CFGCHIP2 to support OTG workaround

[David Lechner]

On 10/26/2016 05:58 AM, Alexandre Bailon wrote:

If we configure the da8xx OTG phy in OTG mode, neither device or host
mode will work. That is because the PHY is not able to detect and notify
the driver that value of ID pin changed.
To work despite this hardware limitation, the da8xx glue implement a
workaround.
But to work, the workaround require the VBUS sense and the session end
comparator to enabled.
Enable them if the phy is configured in OTG mode.

Signed-off-by: Alexandre Bailon 
---
 drivers/phy/phy-da8xx-usb.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
index 32ae78c..fd39292 100644
--- a/drivers/phy/phy-da8xx-usb.c
+++ b/drivers/phy/phy-da8xx-usb.c
@@ -93,24 +93,31 @@ static int da8xx_usb20_phy_power_off(struct phy *phy)
 static int da8xx_usb20_phy_set_mode(struct phy *phy, enum phy_mode mode)
 {
struct da8xx_usb_phy *d_phy = phy_get_drvdata(phy);
+   int ret;
u32 val;

+   ret = regmap_read(d_phy->regmap, CFGCHIP(2), );
+   if (ret)
+   return ret;
+
+   val &= ~CFGCHIP2_OTGMODE_MASK;
+
switch (mode) {
case PHY_MODE_USB_HOST: /* Force VBUS valid, ID = 0 */
-   val = CFGCHIP2_OTGMODE_FORCE_HOST;
+   val |= CFGCHIP2_OTGMODE_FORCE_HOST;
break;
case PHY_MODE_USB_DEVICE:   /* Force VBUS valid, ID = 1 */
-   val = CFGCHIP2_OTGMODE_FORCE_DEVICE;
+   val |= CFGCHIP2_OTGMODE_FORCE_DEVICE;
break;
case PHY_MODE_USB_OTG:  /* Don't override the VBUS/ID comparators */
-   val = CFGCHIP2_OTGMODE_NO_OVERRIDE;
+   val |= CFGCHIP2_OTGMODE_NO_OVERRIDE |
+   CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN;


The AM1808 TRM indicates that CFGCHIP2_SESENDEN and CFGCHIP2_VBDTCTEN 
(and CFGCHIP2_DATPOL) should be on for normal operation of the USB 2.0 
PHY. They do not appear to be associated with the OTG mode specifically.


It seems to me that it would be more appropriate to set these in 
da8xx_usb20_phy_power_on() instead of here in da8xx_usb20_phy_set_mode().




break;
default:
return -EINVAL;
}

-   regmap_write_bits(d_phy->regmap, CFGCHIP(2), CFGCHIP2_OTGMODE_MASK,
- val);
+   regmap_write(d_phy->regmap, CFGCHIP(2), val);

return 0;
 }



Also cc'ing phy maintainer since this is a phy driver.


--
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: musb: remove duplicated actions

[Bin Liu]

Hi,

On Wed, Oct 26, 2016 at 05:24:27PM +0300, Kirill Esipov wrote:
> Removing unnecessary duplicated actions that we've got while merging:
> 19915e623458 ("Merge 4.1-rc7 into usb-next")
> 
> Signed-off-by: Kirill Esipov 
> ---
>  drivers/usb/musb/musb_core.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index 27dadc0..2b04f07 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -2120,12 +2120,6 @@ musb_init_controller(struct device *dev, int nIrq, 
> void __iomem *ctrl)
>   if (musb->ops->ep_select)
>   musb->io.ep_select = musb->ops->ep_select;
>  
> - /* At least tusb6010 has its own offsets */

I prefer to keep this comment and drop the first one
"/* And override them with platform specific ops if specified. */"
as it doesn't provide any value.

> - if (musb->ops->ep_offset)
> - musb->io.ep_offset = musb->ops->ep_offset;
> - if (musb->ops->ep_select)
> - musb->io.ep_select = musb->ops->ep_select;
> -
>   if (musb->ops->fifo_mode)
>   fifo_mode = musb->ops->fifo_mode;
>   else
> -- 
> 2.7.4

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

[PATCH v2 1/4] dt/bindings: Add binding for the DA8xx MUSB driver

[Alexandre Bailon]

From: Petr Kulhavy 

DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.

Signed-off-by: Petr Kulhavy 
Signed-off-by: Alexandre Bailon 
---
 .../devicetree/bindings/usb/da8xx-usb.txt  | 43 ++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt

diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt 
b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
new file mode 100644
index 000..5663d79
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
@@ -0,0 +1,43 @@
+TI DA8xx MUSB
+~
+For DA8xx/OMAP-L1x/AM17xx/AM18xx platforms.
+
+Required properties:
+
+ - compatible : Should be set to "ti,da830-musb".
+
+ - reg: Offset and length of the USB controller register set.
+
+ - interrupts: The USB interrupt number.
+
+ - interrupt-names: Should be set to "mc".
+
+ - dr_mode: The USB operation mode. Should be one of "host", "peripheral" or 
"otg".
+
+ - phys: Phandle for the PHY device
+
+ - phy-names: Should be "usb-phy"
+
+Optional properties:
+
+ - vbus-supply: Phandle to a regulator providing the USB bus power.
+
+Example:
+   usb_phy: usb-phy {
+   compatible = "ti,da830-usb-phy";
+   #phy-cells = <0>;
+   status = "okay";
+   };
+   usb20: usb@1e0 {
+   compatible = "ti,da830-musb";
+   reg =   <0x0020 0x1>;
+   interrupts = <58>;
+   interrupt-names = "mc";
+
+   dr_mode = "host";
+   vbus-supply = <_vbus>;
+   phys = <_phy 0>;
+   phy-names = "usb-phy";
+
+   status = "okay";
+   };
-- 
2.7.3

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

[PATCH v2 4/4] ARM: dts: da850: Add the usb otg device node

[Alexandre Bailon]

This adds the device tree node for the usb otg
controller present in the da850 family of SoC's.
This also enables the otg usb controller for the lcdk board.

Signed-off-by: Alexandre Bailon 
---
 arch/arm/boot/dts/da850-lcdk.dts |  8 
 arch/arm/boot/dts/da850.dtsi | 15 +++
 2 files changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21..9f5040c 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -158,6 +158,14 @@
rx-num-evt = <32>;
 };
 
+_phy {
+   status = "okay";
+   };
+
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f79e1b9..322a31a 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -372,6 +372,21 @@
>;
status = "disabled";
};
+   usb_phy: usb-phy {
+   compatible = "ti,da830-usb-phy";
+   #phy-cells = <1>;
+   status = "disabled";
+   };
+   usb0: usb@20 {
+   compatible = "ti,da830-musb";
+   reg = <0x20 0x1>;
+   interrupts = <58>;
+   interrupt-names = "mc";
+   dr_mode = "otg";
+   phys = <_phy 0>;
+   phy-names = "usb-phy";
+   status = "disabled";
+   };
gpio: gpio@226000 {
compatible = "ti,dm6441-gpio";
gpio-controller;
-- 
2.7.3

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

[PATCH v2 3/4] usb: musb: da8xx: Add DT support for the DA8xx driver

[Alexandre Bailon]

From: Petr Kulhavy 

This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver

Signed-off-by: Petr Kulhavy 
Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/da8xx.c | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 210b7e4..bfa571d 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -6,6 +6,9 @@
  * Based on the DaVinci "glue layer" code.
  * Copyright (C) 2005-2006 by Texas Instruments
  *
+ * DT support
+ * Copyright (c) 2016 Petr Kulhavy 
+ *
  * This file is part of the Inventra Controller Driver for Linux.
  *
  * The Inventra Controller Driver for Linux is free software; you
@@ -433,6 +436,21 @@ static int da8xx_musb_exit(struct musb *musb)
return 0;
 }
 
+static inline u8 get_vbus_power(struct device *dev)
+{
+   struct regulator *vbus_supply;
+   int current_uA;
+
+   vbus_supply = regulator_get_optional(dev, "vbus");
+   if (IS_ERR(vbus_supply))
+   return 255;
+   current_uA = regulator_get_current_limit(vbus_supply);
+   regulator_put(vbus_supply);
+   if (current_uA <= 0 || current_uA > 51)
+   return 255;
+   return current_uA / 1000 / 2;
+}
+
 static const struct musb_platform_ops da8xx_ops = {
.quirks = MUSB_DMA_CPPI | MUSB_INDEXED_EP,
.init   = da8xx_musb_init,
@@ -458,6 +476,12 @@ static const struct platform_device_info da8xx_dev_info = {
.dma_mask   = DMA_BIT_MASK(32),
 };
 
+static const struct musb_hdrc_config da8xx_config = {
+   .ram_bits = 10,
+   .num_eps = 5,
+   .multipoint = 1,
+};
+
 static int da8xx_probe(struct platform_device *pdev)
 {
struct resource musb_resources[2];
@@ -465,7 +489,9 @@ static int da8xx_probe(struct platform_device *pdev)
struct da8xx_glue   *glue;
struct platform_device_info pinfo;
struct clk  *clk;
+   struct device_node  *np = pdev->dev.of_node;
int ret;
+   struct resource *res;
 
glue = devm_kzalloc(>dev, sizeof(*glue), GFP_KERNEL);
if (!glue)
@@ -486,6 +512,18 @@ static int da8xx_probe(struct platform_device *pdev)
glue->dev   = >dev;
glue->clk   = clk;
 
+   if (IS_ENABLED(CONFIG_OF) && np) {
+   pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   /* FIXME */
+   return -ENOMEM;
+   }
+
+   pdata->config   = _config;
+   pdata->mode = musb_get_mode(>dev);
+   pdata->power= get_vbus_power(>dev);
+   }
+
pdata->platform_ops = _ops;
 
glue->usb_phy = usb_phy_generic_register();
@@ -536,11 +574,20 @@ static int da8xx_remove(struct platform_device *pdev)
return 0;
 }
 
+static const struct of_device_id da8xx_id_table[] = {
+   {
+   .compatible = "ti,da830-musb",
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, da8xx_id_table);
+
 static struct platform_driver da8xx_driver = {
.probe  = da8xx_probe,
.remove = da8xx_remove,
.driver = {
.name   = "musb-da8xx",
+   .of_match_table = of_match_ptr(da8xx_id_table),
},
 };
 
-- 
2.7.3

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

[PATCH v2 2/4] usb: musb: core: added helper function for parsing DT

[Alexandre Bailon]

From: Petr Kulhavy 

This adds the function musb_get_mode() to get the DT property "dr_mode"

Signed-off-by: Petr Kulhavy 
Acked-by: Sergei Shtylyov 
Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/musb_core.c | 19 +++
 drivers/usb/musb/musb_core.h |  5 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 27dadc0..bba07e7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "musb_core.h"
 #include "musb_trace.h"
@@ -130,6 +131,24 @@ static inline struct musb *dev_to_musb(struct device *dev)
return dev_get_drvdata(dev);
 }
 
+enum musb_mode musb_get_mode(struct device *dev)
+{
+   enum usb_dr_mode mode;
+
+   mode = usb_get_dr_mode(dev);
+   switch (mode) {
+   case USB_DR_MODE_HOST:
+   return MUSB_HOST;
+   case USB_DR_MODE_PERIPHERAL:
+   return MUSB_PERIPHERAL;
+   case USB_DR_MODE_OTG:
+   case USB_DR_MODE_UNKNOWN:
+   default:
+   return MUSB_OTG;
+   }
+}
+EXPORT_SYMBOL_GPL(musb_get_mode);
+
 /*-*/
 
 #ifndef CONFIG_BLACKFIN
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 2cb88a49..a406468 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -617,4 +617,9 @@ static inline void musb_platform_post_root_reset_end(struct 
musb *musb)
musb->ops->post_root_reset_end(musb);
 }
 
+/* gets the "dr_mode" property from DT and converts it into musb_mode
+ * if the property is not found or not recognized returns MUSB_OTG
+ */
+extern enum musb_mode musb_get_mode(struct device *dev);
+
 #endif /* __MUSB_CORE_H__ */
-- 
2.7.3

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

[PATCH v2 0/4] Add DT support for DA8xx

[Alexandre Bailon]

The purpose of this series is to add DT support to the da8xx USB OTG.
This series should apply and build without any issues but it has
some dependencies on "Add DT support for ohci-da8xx" series.
Without it, the phy init will fail and then the da8xx driver will also fail.

Changes in v2:
* Remove unrelated changes in patch 3
* Rename the device node in patch 4

Alexandre Bailon (1):
  ARM: dts: da850: Add the usb otg device node

Petr Kulhavy (3):
  dt/bindings: Add binding for the DA8xx MUSB driver
  usb: musb: core: added helper function for parsing DT
  usb: musb: da8xx: Add DT support for the DA8xx driver

 .../devicetree/bindings/usb/da8xx-usb.txt  | 43 
 arch/arm/boot/dts/da850-lcdk.dts   |  8 
 arch/arm/boot/dts/da850.dtsi   | 15 +++
 drivers/usb/musb/da8xx.c   | 47 ++
 drivers/usb/musb/musb_core.c   | 19 +
 drivers/usb/musb/musb_core.h   |  5 +++
 6 files changed, 137 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt

-- 
2.7.3

--
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: xhci: Don't drive port 2.0 reset while resuming

[Alan Stern]

On Wed, 26 Oct 2016, Sriram Dash wrote:

> >From: Mathias Nyman [mailto:mathias.ny...@linux.intel.com]

> >I don't think usb core tries to drive reset while port is still resuming
> >
> 
> I am skeptical about it and hope somebody may help us on this.

You can see for yourself.  In drivers/usb/core/hub.c, the 
usb_reset_device() routine calls usb_autoresume_device() before calling 
usb_reset_and_verify_device().  Therefore the port will have finished
resuming before the reset signal is sent.

Alan Stern

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

Re: musb RPM sleep-while-atomic in 4.9-rc1

[Tony Lindgren]

* Johan Hovold  [161026 07:21]:
> On Tue, Oct 25, 2016 at 08:11:10AM -0700, Tony Lindgren wrote:
> > * Johan Hovold  [161025 01:33]:
> > > On Mon, Oct 24, 2016 at 10:35:38AM -0700, Tony Lindgren wrote:
> > > 
> > > > From: Tony Lindgren 
> > > > Date: Mon, 24 Oct 2016 09:18:02 -0700
> > > > Subject: [PATCH] usb: musb: Fix sleeping function called from invalid
> > > >  context for hdrc glue
> > > > 
> > > > Commit 65b3f50ed6fa ("usb: musb: Add PM runtime support for MUSB DSPS
> > > > glue layer") wrongly added a call for pm_runtime_get_sync to otg_timer
> > > > that runs in softirq context. That causes a "BUG: sleeping function 
> > > > called
> > > > from invalid context" every time when polling the cable status:
> > > > 
> > > > [] (__might_sleep) from [] 
> > > > (__pm_runtime_resume+0x9c/0xa0)
> > > > [] (__pm_runtime_resume) from [] 
> > > > (otg_timer+0x3c/0x254)
> > > > [] (otg_timer) from [] (call_timer_fn+0xfc/0x41c)
> > > > [] (call_timer_fn) from [] 
> > > > (expire_timers+0x120/0x210)
> > > > [] (expire_timers) from [] 
> > > > (run_timer_softirq+0xa4/0xdc)
> > > > [] (run_timer_softirq) from [] 
> > > > (__do_softirq+0x12c/0x594)
> > > > 
> > > > I did not notice that as I did not have CONFIG_DEBUG_ATOMIC_SLEEP 
> > > > enabled.
> > > > 
> > > > Let's fix the issue by adding dsps_check_status() and 
> > > > dsps_runtime_resume()
> > > > functions. And let's have otg_timer() check for the PM runtime status, 
> > > > and
> > > > if not already enabled, have dsps_runtime_resume() call 
> > > > dsps_check_status()
> > > > directly.
> > > 
> > > While this makes the sleeping-while-atomic warning go away, it does not
> > > seem correct. In case we were suspended, the glue layer will now call
> > > dsps_check_status while the controller (child) is still suspended:
> > > 
> > > [8.577538] musb-hdrc musb-hdrc.0.auto: otg_timer
> > > [8.582642] musb-dsps 47401400.usb: dsps_runtime_resume
> > > [8.600651] musb-hdrc musb-hdrc.0.auto: dsps_check_status
> > > [8.630617] musb-hdrc musb-hdrc.0.auto: musb_runtime_resume
> > 
> > Hmm that's a good point yeah. If we start doing something generic in
> > musb-core.c musb_runtime_resume, things could go wrong in the future.
> > 
> > With this particular hardware musb registers are always accessible
> > though when the parent of the two musb instances musb_am335x is done.
> > 
> > We could just reprogam the otg timer if !pm_runtime_active(dev). But
> > the sucky things with that approach is that when idle we have two
> > timers, one to wake-up, then another one to check the status.
> 
> Maybe add another callback from musb_runtime_resume that can be used for
> such deferred work instead?

OK that's a good idea :)

Tony
--
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: musb: remove duplicated actions

[Kirill Esipov]

Removing unnecessary duplicated actions that we've got while merging:
19915e623458 ("Merge 4.1-rc7 into usb-next")

Signed-off-by: Kirill Esipov 
---
 drivers/usb/musb/musb_core.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 27dadc0..2b04f07 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2120,12 +2120,6 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
if (musb->ops->ep_select)
musb->io.ep_select = musb->ops->ep_select;
 
-   /* At least tusb6010 has its own offsets */
-   if (musb->ops->ep_offset)
-   musb->io.ep_offset = musb->ops->ep_offset;
-   if (musb->ops->ep_select)
-   musb->io.ep_select = musb->ops->ep_select;
-
if (musb->ops->fifo_mode)
fifo_mode = musb->ops->fifo_mode;
else
-- 
2.7.4

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

Re: musb RPM sleep-while-atomic in 4.9-rc1

[Johan Hovold]

On Tue, Oct 25, 2016 at 08:11:10AM -0700, Tony Lindgren wrote:
> * Johan Hovold  [161025 01:33]:
> > On Mon, Oct 24, 2016 at 10:35:38AM -0700, Tony Lindgren wrote:
> > 
> > > From: Tony Lindgren 
> > > Date: Mon, 24 Oct 2016 09:18:02 -0700
> > > Subject: [PATCH] usb: musb: Fix sleeping function called from invalid
> > >  context for hdrc glue
> > > 
> > > Commit 65b3f50ed6fa ("usb: musb: Add PM runtime support for MUSB DSPS
> > > glue layer") wrongly added a call for pm_runtime_get_sync to otg_timer
> > > that runs in softirq context. That causes a "BUG: sleeping function called
> > > from invalid context" every time when polling the cable status:
> > > 
> > > [] (__might_sleep) from [] 
> > > (__pm_runtime_resume+0x9c/0xa0)
> > > [] (__pm_runtime_resume) from [] 
> > > (otg_timer+0x3c/0x254)
> > > [] (otg_timer) from [] (call_timer_fn+0xfc/0x41c)
> > > [] (call_timer_fn) from [] (expire_timers+0x120/0x210)
> > > [] (expire_timers) from [] 
> > > (run_timer_softirq+0xa4/0xdc)
> > > [] (run_timer_softirq) from [] 
> > > (__do_softirq+0x12c/0x594)
> > > 
> > > I did not notice that as I did not have CONFIG_DEBUG_ATOMIC_SLEEP enabled.
> > > 
> > > Let's fix the issue by adding dsps_check_status() and 
> > > dsps_runtime_resume()
> > > functions. And let's have otg_timer() check for the PM runtime status, and
> > > if not already enabled, have dsps_runtime_resume() call 
> > > dsps_check_status()
> > > directly.
> > 
> > While this makes the sleeping-while-atomic warning go away, it does not
> > seem correct. In case we were suspended, the glue layer will now call
> > dsps_check_status while the controller (child) is still suspended:
> > 
> > [8.577538] musb-hdrc musb-hdrc.0.auto: otg_timer
> > [8.582642] musb-dsps 47401400.usb: dsps_runtime_resume
> > [8.600651] musb-hdrc musb-hdrc.0.auto: dsps_check_status
> > [8.630617] musb-hdrc musb-hdrc.0.auto: musb_runtime_resume
> 
> Hmm that's a good point yeah. If we start doing something generic in
> musb-core.c musb_runtime_resume, things could go wrong in the future.
> 
> With this particular hardware musb registers are always accessible
> though when the parent of the two musb instances musb_am335x is done.
> 
> We could just reprogam the otg timer if !pm_runtime_active(dev). But
> the sucky things with that approach is that when idle we have two
> timers, one to wake-up, then another one to check the status.

Maybe add another callback from musb_runtime_resume that can be used for
such deferred work instead?

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

Re: link state problem with dwc3 in supper-speed device mode

[Bin Liu]

On Wed, Oct 26, 2016 at 04:35:29PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Bin Liu  writes:
> > On Wed, Oct 26, 2016 at 04:13:11PM +0300, Felipe Balbi wrote:
> >> 
> >> Hi,
> >> 
> >> Bin Liu  writes:
> >> >> >> >> > There is no VBUS detection on this device and board. Is the VBUS
> >> >> >> >> > detection needed for dwc3 to work in device mode? 
> >> >> >> >> 
> >> >> >> >> In the case of DRA7x, you don't *really* need detection. All you 
> >> >> >> >> need to
> >> >> >> >> do is correctly update UTMI mailbox.
> >> >> >> >
> >> >> >> > But the UTMI mailbox is driven by extcon events, right? The board
> >> >> >> > doesn't have external circuit or gpio to detect VBUS.
> >> >> >> 
> >> >> >> Then you should use ID event to *also* fiddle with VBUSVALID bit. 
> >> >> >> That
> >> >> >> used to work just fine, I guess commit below broke it:
> >> >> >
> >> >> > I don't understand how this dra7-evm worked before. dwc3 is in SS 
> >> >> > device
> >> >> > mode, microB cable does not ground ID pin, so there is ID event when
> >> >> > attach/detach dwc3 to the host. I am confused...
> >> >> 
> >> >> Please read about the mailbox in your SoC. Try to figure out how it
> >> >> works and what it does. What happens, internally, when you write
> >> >> VBUS_VALID and/or IDGND bits. What does that mean to dwc3? When can dwc3
> >> >> connect its data pullups? What information does it need in order to do
> >> >> that? Many of these questions will be answered ;-)
> >> >
> >> > Yes, got the issue figured out, it is missing hardware trigger to the
> >> > mailbox.
> >> 
> >> you can verify that by writing to UTMI mailbox with devmem2 ;-)
> >
> > Yes, I did that. That is how I got the conclusion.
> >
> > dwc3 only generates disconnect interrupt when the mailbox clears the
> > VBUS bits, for both SS and HS.
> 
> Well, the truth is the following:
> 
> DWC3, as with any USB Device controller, needs to know about VBUS level
> if it wants to follow the USB spec. The de-facto way of telling UDCs
> about VBUS level is UTMI or ULPI. When silicon vendors started
> integrating USB2 PHYs in the SoC, VBUS comparators ended up being left
> out. I speculate the reason for that is that mixed signal processes are
> more complex and/or expensive but, regardless of the reason, VBUS
> comparators were left out.
> 
> So then we needed a new way of generating the UTMI message that the USB2
> PHY can't generate. Hence the UTMI mailbox.
> 
> What you see happening here is DWC3 not having the information it needs
> to tell SW that VBUS is gone. From DWC3's perspective, VBUS is still
> valid. DWC3 can't sample VBUS level by itself, it needs to trust what
> comes over UTMI/ULPI.
> 
> hope this clears it out

Yes, this is all understood now. Initially I was puzzled by the fact
that high-speed seems to work, at least from what it looks like.  Then
it turned out that is cause of LPM. The issue is clear now.

Thanks,
-Bin.
--
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: link state problem with dwc3 in supper-speed device mode

[Felipe Balbi]

Hi,

Bin Liu  writes:
> On Wed, Oct 26, 2016 at 04:13:11PM +0300, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Bin Liu  writes:
>> >> >> >> > There is no VBUS detection on this device and board. Is the VBUS
>> >> >> >> > detection needed for dwc3 to work in device mode? 
>> >> >> >> 
>> >> >> >> In the case of DRA7x, you don't *really* need detection. All you 
>> >> >> >> need to
>> >> >> >> do is correctly update UTMI mailbox.
>> >> >> >
>> >> >> > But the UTMI mailbox is driven by extcon events, right? The board
>> >> >> > doesn't have external circuit or gpio to detect VBUS.
>> >> >> 
>> >> >> Then you should use ID event to *also* fiddle with VBUSVALID bit. That
>> >> >> used to work just fine, I guess commit below broke it:
>> >> >
>> >> > I don't understand how this dra7-evm worked before. dwc3 is in SS device
>> >> > mode, microB cable does not ground ID pin, so there is ID event when
>> >> > attach/detach dwc3 to the host. I am confused...
>> >> 
>> >> Please read about the mailbox in your SoC. Try to figure out how it
>> >> works and what it does. What happens, internally, when you write
>> >> VBUS_VALID and/or IDGND bits. What does that mean to dwc3? When can dwc3
>> >> connect its data pullups? What information does it need in order to do
>> >> that? Many of these questions will be answered ;-)
>> >
>> > Yes, got the issue figured out, it is missing hardware trigger to the
>> > mailbox.
>> 
>> you can verify that by writing to UTMI mailbox with devmem2 ;-)
>
> Yes, I did that. That is how I got the conclusion.
>
> dwc3 only generates disconnect interrupt when the mailbox clears the
> VBUS bits, for both SS and HS.

Well, the truth is the following:

DWC3, as with any USB Device controller, needs to know about VBUS level
if it wants to follow the USB spec. The de-facto way of telling UDCs
about VBUS level is UTMI or ULPI. When silicon vendors started
integrating USB2 PHYs in the SoC, VBUS comparators ended up being left
out. I speculate the reason for that is that mixed signal processes are
more complex and/or expensive but, regardless of the reason, VBUS
comparators were left out.

So then we needed a new way of generating the UTMI message that the USB2
PHY can't generate. Hence the UTMI mailbox.

What you see happening here is DWC3 not having the information it needs
to tell SW that VBUS is gone. From DWC3's perspective, VBUS is still
valid. DWC3 can't sample VBUS level by itself, it needs to trust what
comes over UTMI/ULPI.

hope this clears it out

-- 
balbi


signature.asc
Description: PGP signature

Re: link state problem with dwc3 in supper-speed device mode

[Bin Liu]

On Wed, Oct 26, 2016 at 04:13:11PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Bin Liu  writes:
> >> >> >> > There is no VBUS detection on this device and board. Is the VBUS
> >> >> >> > detection needed for dwc3 to work in device mode? 
> >> >> >> 
> >> >> >> In the case of DRA7x, you don't *really* need detection. All you 
> >> >> >> need to
> >> >> >> do is correctly update UTMI mailbox.
> >> >> >
> >> >> > But the UTMI mailbox is driven by extcon events, right? The board
> >> >> > doesn't have external circuit or gpio to detect VBUS.
> >> >> 
> >> >> Then you should use ID event to *also* fiddle with VBUSVALID bit. That
> >> >> used to work just fine, I guess commit below broke it:
> >> >
> >> > I don't understand how this dra7-evm worked before. dwc3 is in SS device
> >> > mode, microB cable does not ground ID pin, so there is ID event when
> >> > attach/detach dwc3 to the host. I am confused...
> >> 
> >> Please read about the mailbox in your SoC. Try to figure out how it
> >> works and what it does. What happens, internally, when you write
> >> VBUS_VALID and/or IDGND bits. What does that mean to dwc3? When can dwc3
> >> connect its data pullups? What information does it need in order to do
> >> that? Many of these questions will be answered ;-)
> >
> > Yes, got the issue figured out, it is missing hardware trigger to the
> > mailbox.
> 
> you can verify that by writing to UTMI mailbox with devmem2 ;-)

Yes, I did that. That is how I got the conclusion.

dwc3 only generates disconnect interrupt when the mailbox clears the
VBUS bits, for both SS and HS.

Regards,
-Bin.
--
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: musb: remove duplicated actions

[Sergei Shtylyov]

On 10/26/2016 03:01 PM, Kirill Esipov wrote:


Removing unnecessary duplicated actions that we've got while merging:
"Merge 4.1-rc7 into usb-next" 19915e623458


   See Documentation/SubmittingPatches, it should be: 19915e623458 ("Merge 
4.1-rc7 into usb-next"). Perhaps the MUSB maintainer can fix this..



Signed-off-by: Kirill Esipov 

[...]

MBR, Sergei

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

Re: link state problem with dwc3 in supper-speed device mode

[Felipe Balbi]

Hi,

Bin Liu  writes:
>> >> >> > There is no VBUS detection on this device and board. Is the VBUS
>> >> >> > detection needed for dwc3 to work in device mode? 
>> >> >> 
>> >> >> In the case of DRA7x, you don't *really* need detection. All you need 
>> >> >> to
>> >> >> do is correctly update UTMI mailbox.
>> >> >
>> >> > But the UTMI mailbox is driven by extcon events, right? The board
>> >> > doesn't have external circuit or gpio to detect VBUS.
>> >> 
>> >> Then you should use ID event to *also* fiddle with VBUSVALID bit. That
>> >> used to work just fine, I guess commit below broke it:
>> >
>> > I don't understand how this dra7-evm worked before. dwc3 is in SS device
>> > mode, microB cable does not ground ID pin, so there is ID event when
>> > attach/detach dwc3 to the host. I am confused...
>> 
>> Please read about the mailbox in your SoC. Try to figure out how it
>> works and what it does. What happens, internally, when you write
>> VBUS_VALID and/or IDGND bits. What does that mean to dwc3? When can dwc3
>> connect its data pullups? What information does it need in order to do
>> that? Many of these questions will be answered ;-)
>
> Yes, got the issue figured out, it is missing hardware trigger to the
> mailbox.

you can verify that by writing to UTMI mailbox with devmem2 ;-)

-- 
balbi


signature.asc
Description: PGP signature

RE: [PATCH v2] usb: xhci: Don't drive port 2.0 reset while resuming

[Sriram Dash]

>From: Mathias Nyman [mailto:mathias.ny...@linux.intel.com]
>On 25.10.2016 13:45, Sriram Dash wrote:
>> For the USB3.0 controller, USB 2.0 reset not driven while port is in
>> Resume state. So, do not program the USB 2.0 reset
>> (PORTSC[PR]=1) while in Resume state.
>>
>> Signed-off-by: Rajat Srivastava 
>> Signed-off-by: Sriram Dash 
>> Signed-off-by: Rajesh Bhagat 
>> ---
>
>What is the actual issue that you are fixing here?

This was an erratum from Synopsis STAR: 9000962562

>Is there some device that is in resume (PLS==XDEV_RESUME) while driving reset?
>

We have not reproduced this as such.

>I just sent a pach for increasing the resume time signaling to 40ms when 
>clearing
>the PORT_FEAT_SUSPEND.
>Does that work for you?
>
>If not, then we should look closer at why clearing the suspend does not work
>properly.
>One issue could be that ClearPortFeature PORT_FEAT_SUSPEND does not really
>read or wait for for changes in port status. It blindly sets the states based 
>on time
>passed.
>
>Or if it's after system suspend there might be something in bus_resume that is 
>not
>working.
>
>I don't think usb core tries to drive reset while port is still resuming
>

I am skeptical about it and hope somebody may help us on this.

>-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: link state problem with dwc3 in supper-speed device mode

[Bin Liu]

On Wed, Oct 26, 2016 at 10:20:11AM +0300, Roger Quadros wrote:
> Hi,
> 
> On 25/10/16 23:55, Bin Liu wrote:
> > Felipe,
> > 
> > On Tue, Oct 25, 2016 at 08:57:26AM -0500, Bin Liu wrote:
> >> On Tue, Oct 25, 2016 at 04:44:13PM +0300, Felipe Balbi wrote:
> >>
> >> [snip]
> >>
>  Just reviewed this patch, it seems to be the regression. But SS should
>  not generate ID pin event either, right? SS uses far-end termination, it
>  does not have ID pin as USB2.0. I will try to revert this patch to find
>  out...
> >>>
> >>> it's not about speed :-) ID pin is used nevertheless to choose role, but
> >>
> >> Yeah, you are right. I messed it up with type-C, somehow thought ID pin
> >> is not required for SS :-(
> >>
> >>> some TI boards didn't provide any methods for VBUS sampling, so ID pin
> >>> was used to tell DWC3 if it should be host/device AND if VBUS_VALID or
> >>> not.
> >>>
> >>> Note that we end up lying to the controller because we could set
> >>> VBUS_VALID before VBUS really is valid, but it's better than never
> >>> seeing a connection at all ;-)
> >>
> >> Make more sense now :-) I will play with the patch mentioned, and ensure
> >> any future boards have vbus sampling so we can decouple it with ID pin
> >> events in the UTMI mailbox.
> >>
> >> Still need to figure out why highspeed is not affected...
> > 
> > Ok, I think I understand most part of the problems now.
> > 
> > VBUS detect is required for disconnect event, so AM57x board design
> > should have a GPIO for VBUS detect to feed to extcon.
> > 
> > 1. why only SS is affected on dra7-evm?
> > 
> > This is because of USB3.0 LPM. With g_zero, dwc3 SS in device mode goes
> > to U2 after been enumerated, in which state dwc3 is unable to detect any
> > change other than link change. But dwc3 HS stays in U0 after been
> > enumerated, so the link goes to RX.Detect after detach from the host. So
> > dwc3 HS can still detect the connect to host even with lack of
> > disconnect interrupt.
> > 
> > 2. why dra7-evm used to work?
> > 
> > Very likely the kernel at that time does not support LPM, so
> > dwc3 SS is still in U0 after been enumerated, the same case as in HS
> > above. At least this is what I see with kernel 3.14, in which dwc3 SS
> > doesn't go to U2.
> 
> So does this mean that it still won't work with the suspected patch
> removed? As there is no way of telling about VBUS status on dra7-evm.

I didn't revert the suspected patch, as I don't think it will make it
work. microB cable doesn't ground ID pin, so detaching the cable won't
trigger the UTMI mailbox at all, the patch is not in the path.

I verified the mailbox notifier is not called when remove the cable.

> 
> How can we workaround this on that evm? is disabling LPM on dra7-evm possible?

I don't think there is any workaround, other than a board change. I
tried to disable LPM, and it did solve the issue, but it generates new
problem - USB3 LPM compliance.

Regards,
-Bin.
--
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 v10 1/1] USB: serial: cp210x: Adding GPIO support for CP2105

[Johan Hovold]

On Wed, Oct 26, 2016 at 01:50:14PM +0200, Linus Walleij wrote:
> On Wed, Oct 26, 2016 at 11:09 AM, Johan Hovold  wrote:
> > On Tue, Oct 25, 2016 at 11:34:40AM +0200, Linus Walleij wrote:
> 
> >> I was thinking on either reusing the .names field of the
> >> struct gpiochip to name the lines for the userspace
> >> chardev. With the sideeffect of the names getting reflected
> >> also to sysfs if using that.
> >
> > Simply reusing .names would cause problems since the old sysfs name
> > space is flat, so you would be unable to use more than one pluggable
> > expander (unless also encoding the topology in the name).
> 
> Hm it seems we should actually #ifdef that field for sysfs then,
> it has no applicability outside the legacy sysfs.

Might make sense. If I remember correctly, this isn't the first time
we've had this discussion. ;)

> > Providing default names from the driver could perhaps be useful at
> > times. For this particular chip the names would still be GPIO_0, GPIO_1
> > and GPIO_2 (possibly with a suffix depending on which of the two
> > controllers they hang off of) however, which may not be much better than
> > using chip->base + offset. I'd assume this to be the common case.
> 
> The chardev names are pertaining to a certain device like
> "gpiochip1" already so the names only need to be unique
> per-instance.

Yeah, I was referring to the legacy sysfs interface above.

> If we made them globally unique we could just use the .names
> in gpiochip anyways, but that seems ugly.

Agreed.

> What about suppling
> 
> gpiochip_set_names(struct gpio_chip *gc,
>char **names);
> 
> As the size of the array is implicit from ngpios and the function
> would be kernel-internal anyways.

You'd at least want to provide a way to set these names before the
gpiochip is registered if you go down this path.

But the point I was trying to make above was whether it was at all worth
it. If the pins are truly general purpose, you would typically not be
providing any more information than the pin chip-offset (e.g. GPIO_1).

But sure, some device might use "a", "b", "c, or whatever...

> > Device-tree overlays is what I see a real use for where different
> > overlays can be applied based on topology data to describe what is
> > actually connected to a pin in a specific setup. And that seems like
> > something that could be useful for normal (static) DT systems as well
> > (e.g. describe what's actually connected to those Beaglebone pins).
> 
> Yeah these overlays ... discussed that a lot recently.
> It fits the Beaglebone indeed.

Not just Beaglebone. It would be generally useful for anything
hotpluggable (e.g. we intended to use this for Greybus) where you need
to describe something non-discoverable (e.g. i2c, spi, gpio) that's
sitting behind a controller on a discoverable bus (e.g. greybus or usb).

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

Re: link state problem with dwc3 in supper-speed device mode

[Bin Liu]

On Wed, Oct 26, 2016 at 11:35:47AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Bin Liu  writes:
> >> >> > There is no VBUS detection on this device and board. Is the VBUS
> >> >> > detection needed for dwc3 to work in device mode? 
> >> >> 
> >> >> In the case of DRA7x, you don't *really* need detection. All you need to
> >> >> do is correctly update UTMI mailbox.
> >> >
> >> > But the UTMI mailbox is driven by extcon events, right? The board
> >> > doesn't have external circuit or gpio to detect VBUS.
> >> 
> >> Then you should use ID event to *also* fiddle with VBUSVALID bit. That
> >> used to work just fine, I guess commit below broke it:
> >
> > I don't understand how this dra7-evm worked before. dwc3 is in SS device
> > mode, microB cable does not ground ID pin, so there is ID event when
> > attach/detach dwc3 to the host. I am confused...
> 
> Please read about the mailbox in your SoC. Try to figure out how it
> works and what it does. What happens, internally, when you write
> VBUS_VALID and/or IDGND bits. What does that mean to dwc3? When can dwc3
> connect its data pullups? What information does it need in order to do
> that? Many of these questions will be answered ;-)

Yes, got the issue figured out, it is missing hardware trigger to the
mailbox.

> 
> Hint: dwc3 doesn't know about any GPIOs or VBUS comparators or whatever
> you may place in the PCB. DWC3 only understands PIPE3 and
> ULPI/UTMI. So how does the mailbox come in the picture? Why do we need
> it? Is it replacing any other component? Which component would that be?

Thanks.
-Bin.

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

[PATCH v2] usb: musb: remove duplicated actions

[Kirill Esipov]

Removing unnecessary duplicated actions that we've got while merging:
"Merge 4.1-rc7 into usb-next" 19915e623458

Signed-off-by: Kirill Esipov 
---
 drivers/usb/musb/musb_core.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 27dadc0..2b04f07 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2120,12 +2120,6 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
if (musb->ops->ep_select)
musb->io.ep_select = musb->ops->ep_select;
 
-   /* At least tusb6010 has its own offsets */
-   if (musb->ops->ep_offset)
-   musb->io.ep_offset = musb->ops->ep_offset;
-   if (musb->ops->ep_select)
-   musb->io.ep_select = musb->ops->ep_select;
-
if (musb->ops->fifo_mode)
fifo_mode = musb->ops->fifo_mode;
else
-- 
2.7.4

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

Re: [PATCH v10 1/1] USB: serial: cp210x: Adding GPIO support for CP2105

[Linus Walleij]

On Wed, Oct 26, 2016 at 11:09 AM, Johan Hovold  wrote:
> On Tue, Oct 25, 2016 at 11:34:40AM +0200, Linus Walleij wrote:

>> I was thinking on either reusing the .names field of the
>> struct gpiochip to name the lines for the userspace
>> chardev. With the sideeffect of the names getting reflected
>> also to sysfs if using that.
>
> Simply reusing .names would cause problems since the old sysfs name
> space is flat, so you would be unable to use more than one pluggable
> expander (unless also encoding the topology in the name).

Hm it seems we should actually #ifdef that field for sysfs then,
it has no applicability outside the legacy sysfs.

> Providing default names from the driver could perhaps be useful at
> times. For this particular chip the names would still be GPIO_0, GPIO_1
> and GPIO_2 (possibly with a suffix depending on which of the two
> controllers they hang off of) however, which may not be much better than
> using chip->base + offset. I'd assume this to be the common case.

The chardev names are pertaining to a certain device like
"gpiochip1" already so the names only need to be unique
per-instance.

If we made them globally unique we could just use the .names
in gpiochip anyways, but that seems ugly.

What about suppling

gpiochip_set_names(struct gpio_chip *gc,
   char **names);

As the size of the array is implicit from ngpios and the function
would be kernel-internal anyways.

> Device-tree overlays is what I see a real use for where different
> overlays can be applied based on topology data to describe what is
> actually connected to a pin in a specific setup. And that seems like
> something that could be useful for normal (static) DT systems as well
> (e.g. describe what's actually connected to those Beaglebone pins).

Yeah these overlays ... discussed that a lot recently.
It fits the Beaglebone indeed.

Yours,
Linus Walleij
--
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: musb: remove duplicated actions

[Sergei Shtylyov]

Hello.

On 10/26/2016 2:12 PM, Kirill Esipov wrote:


Remove unnecessary duplicate actions (that we've got here:
19915e623458004547c1c2490b09bb923fe69337)


   You should also specify the commit's summary line in (""). And it's enough 
to specify 12 digits of SHA1 ID.



Signed-off-by: Kirill Esipov 

[...]

MBR, Sergei

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

[PATCH] usb: musb: remove duplicated actions

[Kirill Esipov]

Remove unnecessary duplicate actions (that we've got here:
19915e623458004547c1c2490b09bb923fe69337)

Signed-off-by: Kirill Esipov 
---
 drivers/usb/musb/musb_core.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 27dadc0..2b04f07 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2120,12 +2120,6 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
if (musb->ops->ep_select)
musb->io.ep_select = musb->ops->ep_select;
 
-   /* At least tusb6010 has its own offsets */
-   if (musb->ops->ep_offset)
-   musb->io.ep_offset = musb->ops->ep_offset;
-   if (musb->ops->ep_select)
-   musb->io.ep_select = musb->ops->ep_select;
-
if (musb->ops->fifo_mode)
fifo_mode = musb->ops->fifo_mode;
else
-- 
2.7.4

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

[PATCH v2 0/3] usb: musb: da8xx: Fix few issues

[Alexandre Bailon]

Currently, the USB OTG of the da8xx doesn't work.
This series intend to fix them.

Change in v2:
* Fix the error path da8xx_musb_init()

Alexandre Bailon (3):
  usb: musb: da8xx: Call earlier clk_prepare_enable()
  phy: da8xx-usb: Configure CFGCHIP2 to support OTG workaround
  usb: musb: da8xx: Only execute the OTG workaround when phy in OTG mode

 drivers/phy/phy-da8xx-usb.c | 17 -
 drivers/usb/musb/da8xx.c| 28 +++-
 2 files changed, 31 insertions(+), 14 deletions(-)

-- 
2.7.3

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

[PATCH v2 3/3] usb: musb: da8xx: Only execute the OTG workaround when phy in OTG mode

[Alexandre Bailon]

When the phy is forced in host mode, only the first hot plug and
hot remove works. That is actually because the driver execute the
OTG workaround, whereas it is not applicable in host or device mode.
Indeed, to work correctly, the VBUS sense and session end comparator
must be enabled, what is only possible when the phy is in OTG mode.
Only execute the workaround if the phy is in OTG mode.

Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/da8xx.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 6749aa1..b8a6b65 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -145,6 +145,17 @@ static void otg_timer(unsigned long _musb)
unsigned long   flags;
 
/*
+* We should only execute the OTG workaround when the phy is in OTG
+* mode. The workaround require the VBUS sense and the session end
+* comparator to be enabled, what is only possible if the phy is in
+* OTG mode. As the workaround is only required to detect if the
+* controller must act as host or device, we can safely exit OTG is
+* not in use.
+*/
+   if (musb->port_mode != MUSB_PORT_MODE_DUAL_ROLE)
+   return;
+
+   /*
 * We poll because DaVinci's won't expose several OTG-critical
 * status change events (from the transceiver) otherwise.
 */
-- 
2.7.3

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

[PATCH v2 1/3] usb: musb: da8xx: Call earlier clk_prepare_enable()

[Alexandre Bailon]

The first attempt to read a register may fail because the clock may not
be enabled, and then the probe of musb driver will fail.
Call clk_prepare_enable() before the first register read.

Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/da8xx.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 210b7e4..6749aa1 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -366,6 +366,12 @@ static int da8xx_musb_init(struct musb *musb)
 
musb->mregs += DA8XX_MENTOR_CORE_OFFSET;
 
+   ret = clk_prepare_enable(glue->clk);
+   if (ret) {
+   dev_err(glue->dev, "failed to enable clock\n");
+   return ret;
+   }
+
/* Returns zero if e.g. not clocked */
rev = musb_readl(reg_base, DA8XX_USB_REVISION_REG);
if (!rev)
@@ -377,12 +383,6 @@ static int da8xx_musb_init(struct musb *musb)
goto fail;
}
 
-   ret = clk_prepare_enable(glue->clk);
-   if (ret) {
-   dev_err(glue->dev, "failed to enable clock\n");
-   goto fail;
-   }
-
setup_timer(_workaround, otg_timer, (unsigned long)musb);
 
/* Reset the controller */
@@ -392,7 +392,7 @@ static int da8xx_musb_init(struct musb *musb)
ret = phy_init(glue->phy);
if (ret) {
dev_err(glue->dev, "Failed to init phy.\n");
-   goto err_phy_init;
+   goto fail;
}
 
ret = phy_power_on(glue->phy);
@@ -412,9 +412,8 @@ static int da8xx_musb_init(struct musb *musb)
 
 err_phy_power_on:
phy_exit(glue->phy);
-err_phy_init:
-   clk_disable_unprepare(glue->clk);
 fail:
+   clk_disable_unprepare(glue->clk);
return ret;
 }
 
-- 
2.7.3

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

[PATCH v2 2/3] phy: da8xx-usb: Configure CFGCHIP2 to support OTG workaround

[Alexandre Bailon]

If we configure the da8xx OTG phy in OTG mode, neither device or host
mode will work. That is because the PHY is not able to detect and notify
the driver that value of ID pin changed.
To work despite this hardware limitation, the da8xx glue implement a
workaround.
But to work, the workaround require the VBUS sense and the session end
comparator to enabled.
Enable them if the phy is configured in OTG mode.

Signed-off-by: Alexandre Bailon 
---
 drivers/phy/phy-da8xx-usb.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
index 32ae78c..fd39292 100644
--- a/drivers/phy/phy-da8xx-usb.c
+++ b/drivers/phy/phy-da8xx-usb.c
@@ -93,24 +93,31 @@ static int da8xx_usb20_phy_power_off(struct phy *phy)
 static int da8xx_usb20_phy_set_mode(struct phy *phy, enum phy_mode mode)
 {
struct da8xx_usb_phy *d_phy = phy_get_drvdata(phy);
+   int ret;
u32 val;
 
+   ret = regmap_read(d_phy->regmap, CFGCHIP(2), );
+   if (ret)
+   return ret;
+
+   val &= ~CFGCHIP2_OTGMODE_MASK;
+
switch (mode) {
case PHY_MODE_USB_HOST: /* Force VBUS valid, ID = 0 */
-   val = CFGCHIP2_OTGMODE_FORCE_HOST;
+   val |= CFGCHIP2_OTGMODE_FORCE_HOST;
break;
case PHY_MODE_USB_DEVICE:   /* Force VBUS valid, ID = 1 */
-   val = CFGCHIP2_OTGMODE_FORCE_DEVICE;
+   val |= CFGCHIP2_OTGMODE_FORCE_DEVICE;
break;
case PHY_MODE_USB_OTG:  /* Don't override the VBUS/ID comparators */
-   val = CFGCHIP2_OTGMODE_NO_OVERRIDE;
+   val |= CFGCHIP2_OTGMODE_NO_OVERRIDE |
+   CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN;
break;
default:
return -EINVAL;
}
 
-   regmap_write_bits(d_phy->regmap, CFGCHIP(2), CFGCHIP2_OTGMODE_MASK,
- val);
+   regmap_write(d_phy->regmap, CFGCHIP(2), val);
 
return 0;
 }
-- 
2.7.3

--
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/6] Documentation: devicetree: dwc3: Add interrupt moderation

[Mark Rutland]

On Tue, Oct 25, 2016 at 12:42:46PM -0700, John Youn wrote:
> Add interrupt moderation interval binding for dwc3.
> 
> Signed-off-by: John Youn 
> ---
>  Documentation/devicetree/bindings/usb/dwc3.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
> b/Documentation/devicetree/bindings/usb/dwc3.txt
> index e3e6983..17de9fc 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -53,6 +53,7 @@ Optional properties:
>   - snps,quirk-frame-length-adjustment: Value for GFLADJ_30MHZ field of GFLADJ
>   register for post-silicon frame length adjustment when the
>   fladj_30mhz_sdbnd signal is invalid or incorrect.
> + - snps,imod_interval: the interrupt moderation interval.

As otherwise commented, s/_/-/

What is "interrupt moderation"? The cover mentions that this is to be
used for some kind of workaround, but it's not clear to me what this is,
and as such, whether it makes sense to describe it in this manner.

Thanks,
Mark.

>  
>   -  tx-fifo-resize: determines if the FIFO *has* to be 
> reallocated.
>  
> -- 
> 2.10.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] Documentation: devicetree: dwc3: Add interrupt moderation

[Sergei Shtylyov]

Hello.

On 10/25/2016 10:42 PM, John Youn wrote:


Add interrupt moderation interval binding for dwc3.

Signed-off-by: John Youn 
---
 Documentation/devicetree/bindings/usb/dwc3.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e3e6983..17de9fc 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -53,6 +53,7 @@ Optional properties:
  - snps,quirk-frame-length-adjustment: Value for GFLADJ_30MHZ field of GFLADJ
register for post-silicon frame length adjustment when the
fladj_30mhz_sdbnd signal is invalid or incorrect.
+ - snps,imod_interval: the interrupt moderation interval.


   Hyphens are preferred in the DT node/prop names.

[...]

MBR, Sergei

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

Re: Identifying Synopsys USB3 Controller on Baytrail Device

[Felipe Balbi]

Hi,

Joseph Kogut  writes:
> Hi David,
>
> I know this is a pretty old thread. I tried searching for the LKML
> etiquette on something like this and came up empty. If I should start
> a new thread, let me know.
>
> After what I learned from the last thread, I dropped the idea of using
> the device controller from the Dell tablet I had. A few months later,
> I learned that some overseas electronics companies are now making
> dual-boot tablets, that support both Android and generic x86 operating
> systems through an IA32 UEFI firmware. I did some research on the
> devices, and found that they support interaction over USB with the
> Android tools ADB and fastboot, which indicated to me that they likely
> had a working USB device controller.
>
> With my curiosity piqued, I acquired one. My testing confirmed that
> the installed Android OS had the capability of utilizing both the host
> and device controllers, and allowed file transfer over MTP, as well as
> USB networking.
>
> After discovering that much of the kernel code supporting Baytrail had
> yet to be mainlined, I shelved the device for a few months.
>
> In the last few days, I've revisited the tablet, and replaced the
> second OS that came on it with a Linux distribution running the
> mainline kernel, compiled with DWC3 and OTG support. After booting the
> tablet and attempting to load a gadget module, I had a bout of deja
> vu. The device controller doesn't appear in the list of PCI devices.
>
> When attempting to load a gadget module, the kernel log reports:
>
>> udc-core: couldn't find an available UDC
>
> After reviewing this thread, I confirmed that the device id 8086:0f37
> does not appear in the output of 'lspci -nn', but 8086:0f35 does.
>
> The dual-boot capability of the device seems to be implemented by
> switching between two distinct firmwares, but I can't be sure. If that
> is the case, I'm wondering if the PC compatible firmware just doesn't
> expose the device controller for some reason. Alternatively, like
> Felipe mentioned, I wonder if there's not a muxer between the phy and
> device/host controllers that needs to be configured somehow.
>
> Do you have any light to shed on this?

You can extract ACPI tables to figure this one out:

# acpidump -o acpi.bin

Then copy that over to your PC using, e.g. MTP and run:

$ acpixtract -a acpi.bin

followed by:

$ iasl -d *.dat

Then you can look in dsdt.dsl for XDCI or OTGD, or whatever might look
like the peripheral controller. Look at the _STA method and see what it
returns. Devices only show up on PCI bus when _STA is non-zero (usually,
it returns 0xF). I'd assume there's a If() condition for the reported OS
type.

To test things out, you can overwrite FW DSDT with your own, but be
very, very careful when doing so. I recommend reading on Google and
Documentation directory before attempting.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH/RFT v2 07/17] ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable

[Sekhar Nori]

On Tuesday 25 October 2016 09:35 PM, David Lechner wrote:
> On 10/25/2016 05:12 AM, Sekhar Nori wrote:
>> On Monday 24 October 2016 10:16 PM, ahas...@baylibre.com wrote:
>>> diff --git a/arch/arm/mach-davinci/usb-da8xx.c
>>> b/arch/arm/mach-davinci/usb-da8xx.c
>>> index 9e41a7f..982e105 100644
>>> --- a/arch/arm/mach-davinci/usb-da8xx.c
>>> +++ b/arch/arm/mach-davinci/usb-da8xx.c
>>> @@ -53,11 +53,19 @@ int __init da8xx_register_usb_refclkin(int rate)
>>>
>>>  static void usb20_phy_clk_enable(struct clk *clk)
>>>  {
>>> +struct clk *usb20_clk;
>>>  u32 val;
>>>  u32 timeout = 50; /* 500 msec */
>>>
>>>  val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
>>>
>>> +usb20_clk = clk_get(NULL, "usb20");
>>
>> We should not be using a NULL device pointer here. Can you pass the musb
>> device pointer available in the same file? Also, da850_clks[] in da850.c
>> needs to be fixed to add the matching device name.
> 
> This clock can be used for usb 1.1 PHY even when musb is not being used,
> so I don't think we can depend on having a musb device here.

Replied to this against the same question in v6 patch series you posted.

> Also, in a previous review, it was decided that the usb clocks should
> *not* be added to da850_clks[] [1]. Instead, they are dynamically
> registered elsewhere.

Thats only the USB phy clocks since there is associated
enable()/disable()/set_parent() code which is better kept outside of
da850.c for readability. No other reason. Lookup for the USB 2.0 module
clock is already present in da850.c

Thanks,
Sekhar
--
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/4] usb: musb: da8xx: Add DT support for the DA8xx driver

[Alexandre Bailon]

On 10/25/2016 07:38 PM, Sergei Shtylyov wrote:
> Hello.
> 
> On 10/25/2016 05:39 PM, Alexandre Bailon wrote:
> 
>> From: Petr Kulhavy 
>>
>> This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver
>>
>> Signed-off-by: Petr Kulhavy 
>> Signed-off-by: Alexandre Bailon 
>> ---
>>  drivers/usb/musb/da8xx.c | 76
>> ++--
>>  1 file changed, 67 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
>> index 210b7e4..d465087 100644
>> --- a/drivers/usb/musb/da8xx.c
>> +++ b/drivers/usb/musb/da8xx.c
>> @@ -6,6 +6,9 @@
>>   * Based on the DaVinci "glue layer" code.
>>   * Copyright (C) 2005-2006 by Texas Instruments
>>   *
>> + * DT support
>> + * Copyright (c) 2016 Petr Kulhavy 
>> + *
>>   * This file is part of the Inventra Controller Driver for Linux.
>>   *
>>   * The Inventra Controller Driver for Linux is free software; you
> [...]
>> @@ -499,15 +537,21 @@ static int da8xx_probe(struct platform_device
>> *pdev)
>>  memset(musb_resources, 0x00, sizeof(*musb_resources) *
>>  ARRAY_SIZE(musb_resources));
>>
>> -musb_resources[0].name = pdev->resource[0].name;
>> -musb_resources[0].start = pdev->resource[0].start;
>> -musb_resources[0].end = pdev->resource[0].end;
>> -musb_resources[0].flags = pdev->resource[0].flags;
>> +res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +if (!res) {
>> +dev_err(>dev, "failed to get memory.\n");
>> +ret = -EINVAL;
>> +goto err_unregister_usb_phy;
>> +}
>> +musb_resources[0] = *res;
> 
>What does this change have to do with the DT conversion?
Nothing. I will remove it.
> 
>>
>> -musb_resources[1].name = pdev->resource[1].name;
>> -musb_resources[1].start = pdev->resource[1].start;
>> -musb_resources[1].end = pdev->resource[1].end;
>> -musb_resources[1].flags = pdev->resource[1].flags;
>> +res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>> +if (!res) {
>> +dev_err(>dev, "failed to get irq.\n");
>> +ret = -EINVAL;
>> +goto err_unregister_usb_phy;
>> +}
>> +musb_resources[1] = *res;
> 
>And this?
>I'm also concerned that you'd copy the resource linkage fields which
> the existing code avoids...
> 
> [...]
> 
> MBR, Sergei
> 

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

Re: [PATCH 2/3] phy: da8xx-usb: Configure CFGCHIP2 to support OTG workaround

[Alexandre Bailon]

On 10/25/2016 09:16 PM, David Lechner wrote:
> On 10/25/2016 08:52 AM, Alexandre Bailon wrote:
>> If we configure the da8xx OTG phy in OTG mode, neither device or host
>> mode will work. That is because the PHY is not able to detect and notify
>> the driver that value of ID pin changed.
>> To work despite this hardware limitation, the da8xx glue implement a
>> workaround.
>> But to work, the workaround require the VBUS sense and the session end
>> comparator to enabled.
>> Enable them if the phy is configured in OTG mode.
>>
>> Signed-off-by: Alexandre Bailon 
>> ---
>>  drivers/phy/phy-da8xx-usb.c | 17 -
>>  1 file changed, 12 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
>> index 32ae78c..fd39292 100644
>> --- a/drivers/phy/phy-da8xx-usb.c
>> +++ b/drivers/phy/phy-da8xx-usb.c
>> @@ -93,24 +93,31 @@ static int da8xx_usb20_phy_power_off(struct phy *phy)
>>  static int da8xx_usb20_phy_set_mode(struct phy *phy, enum phy_mode mode)
>>  {
>>  struct da8xx_usb_phy *d_phy = phy_get_drvdata(phy);
>> +int ret;
>>  u32 val;
>>
>> +ret = regmap_read(d_phy->regmap, CFGCHIP(2), );
>> +if (ret)
>> +return ret;
>> +
>> +val &= ~CFGCHIP2_OTGMODE_MASK;
>> +
>>  switch (mode) {
>>  case PHY_MODE_USB_HOST:/* Force VBUS valid, ID = 0 */
>> -val = CFGCHIP2_OTGMODE_FORCE_HOST;
>> +val |= CFGCHIP2_OTGMODE_FORCE_HOST;
>>  break;
>>  case PHY_MODE_USB_DEVICE:/* Force VBUS valid, ID = 1 */
>> -val = CFGCHIP2_OTGMODE_FORCE_DEVICE;
>> +val |= CFGCHIP2_OTGMODE_FORCE_DEVICE;
>>  break;
>>  case PHY_MODE_USB_OTG:/* Don't override the VBUS/ID
>> comparators */
>> -val = CFGCHIP2_OTGMODE_NO_OVERRIDE;
>> +val |= CFGCHIP2_OTGMODE_NO_OVERRIDE |
>> +CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN;
> 
> Do we need to clear CFGCHIP2_SESENDEN and/or CFGCHIP2_VBDTCTEN in case
> PHY_MODE_USB_HOST: or case PHY_MODE_USB_DEVICE:? Or are they ignored in
> those modes?
Actually, I don't know. The datasheet is quite confusing.
The "USB PHY Initialization" section seems to speak only about OTG mode.
But my observation let me think they are ignored when the phy is forced
in device or host mode.
> 
>>  break;
>>  default:
>>  return -EINVAL;
>>  }
>>
>> -regmap_write_bits(d_phy->regmap, CFGCHIP(2), CFGCHIP2_OTGMODE_MASK,
>> -  val);
>> +regmap_write(d_phy->regmap, CFGCHIP(2), val);
>>
>>  return 0;
>>  }
>>
> 

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

Re: [PATCH v10 1/1] USB: serial: cp210x: Adding GPIO support for CP2105

[Johan Hovold]

On Tue, Oct 25, 2016 at 11:34:40AM +0200, Linus Walleij wrote:
> Good work on this patch, nice that it got merged.
> 
> I was just thinking that as an add-on, you may want to name
> the gpio lines so they have meaningful names in userspace
> when you use this with the chardev (I have reasons to believe
> these GPIOs will be used from userspace, tell me if that
> is wrong).
>
> We currently support naming lines for devicetree and
> ACPI (in -next).
> 
> I was thinking on either reusing the .names field of the
> struct gpiochip to name the lines for the userspace
> chardev. With the sideeffect of the names getting reflected
> also to sysfs if using that.

Simply reusing .names would cause problems since the old sysfs name
space is flat, so you would be unable to use more than one pluggable
expander (unless also encoding the topology in the name).

> We could otherwise add a special function to name the
> lines from drivers like this that hang off a pluggable bus.
> 
> Johan/Martyn what is your idea?

Providing default names from the driver could perhaps be useful at
times. For this particular chip the names would still be GPIO_0, GPIO_1
and GPIO_2 (possibly with a suffix depending on which of the two
controllers they hang off of) however, which may not be much better than
using chip->base + offset. I'd assume this to be the common case.

Device-tree overlays is what I see a real use for where different
overlays can be applied based on topology data to describe what is
actually connected to a pin in a specific setup. And that seems like
something that could be useful for normal (static) DT systems as well
(e.g. describe what's actually connected to those Beaglebone pins).

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

[PATCH 1/1] usb: gadget: f_uac2: fix error handling at afunc_bind

[Peter Chen]

The current error handling flow uses incorrect goto label, fix it

Cc: 
Fixes: d12a8727171c ("usb: gadget: function: Remove
redundant usb_free_all_descriptors")
Signed-off-by: Peter Chen 
---
 drivers/usb/gadget/function/f_uac2.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/gadget/function/f_uac2.c 
b/drivers/usb/gadget/function/f_uac2.c
index cd214ec8..3f4e478 100644
--- a/drivers/usb/gadget/function/f_uac2.c
+++ b/drivers/usb/gadget/function/f_uac2.c
@@ -1067,13 +1067,13 @@ afunc_bind(struct usb_configuration *cfg, struct 
usb_function *fn)
agdev->out_ep = usb_ep_autoconfig(gadget, _epout_desc);
if (!agdev->out_ep) {
dev_err(dev, "%s:%d Error!\n", __func__, __LINE__);
-   goto err;
+   return ret;
}
 
agdev->in_ep = usb_ep_autoconfig(gadget, _epin_desc);
if (!agdev->in_ep) {
dev_err(dev, "%s:%d Error!\n", __func__, __LINE__);
-   goto err;
+   return ret;
}
 
uac2->p_prm.uac2 = uac2;
@@ -1091,13 +1091,14 @@ afunc_bind(struct usb_configuration *cfg, struct 
usb_function *fn)
ret = usb_assign_descriptors(fn, fs_audio_desc, hs_audio_desc, NULL,
 NULL);
if (ret)
-   goto err;
+   return ret;
 
prm = >uac2.c_prm;
prm->max_psize = hs_epout_desc.wMaxPacketSize;
prm->rbuf = kzalloc(prm->max_psize * USB_XFERS, GFP_KERNEL);
if (!prm->rbuf) {
prm->max_psize = 0;
+   ret = -ENOMEM;
goto err_free_descs;
}
 
@@ -1106,20 +1107,21 @@ afunc_bind(struct usb_configuration *cfg, struct 
usb_function *fn)
prm->rbuf = kzalloc(prm->max_psize * USB_XFERS, GFP_KERNEL);
if (!prm->rbuf) {
prm->max_psize = 0;
-   goto err_free_descs;
+   ret = -ENOMEM;
+   goto err_no_memory;
}
 
ret = alsa_uac2_init(agdev);
if (ret)
-   goto err_free_descs;
+   goto err_no_memory;
return 0;
 
-err_free_descs:
-   usb_free_all_descriptors(fn);
-err:
+err_no_memory:
kfree(agdev->uac2.p_prm.rbuf);
kfree(agdev->uac2.c_prm.rbuf);
-   return -EINVAL;
+err_free_descs:
+   usb_free_all_descriptors(fn);
+   return ret;
 }
 
 static int
-- 
2.7.4

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

Re: [PATCH/RFT v2 02/17] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration.

[Sekhar Nori]

On Tuesday 25 October 2016 09:23 PM, David Lechner wrote:
> Hi Sekhar,
> 
> On 10/25/2016 05:17 AM, Sekhar Nori wrote:
>> On Tuesday 25 October 2016 03:07 PM, Axel Haslam wrote:
>>> Hi Sekar,
>>>
>>> On Tue, Oct 25, 2016 at 10:10 AM, Sekhar Nori  wrote:
 On Monday 24 October 2016 10:16 PM, ahas...@baylibre.com wrote:
> From: David Lechner 
>
> The CFGCHIP registers are used by a number of devices, so using a
> syscon
> device to share them. The first consumer of this will by the
> phy-da8xx-usb
> driver.
>
> Signed-off-by: David Lechner 
> [Axel: minor fix: change id to -1]

 Can you please clarify this change? There could be other syscon devices
 on the chip for other common registers. Why use the singular device-id?

>>>
>>> in the case of non DT boot, the phy driver is looking for "syscon" :
>>>
>>> d_phy->regmap = syscon_regmap_lookup_by_pdevname("syscon");
>>>
>>> if we register the syscon driver with id = 0, the actual name of the
>>> syscon
>>> device will be "syscon.0" and the phy driver will fail to probe, because
>>> the strncmp match in the syscon driver (syscon_match_pdevname)
>>> will fail.
>>>
>>> should i change the phy driver instead?
>>
>> Yes, please. Forcing only one syscon region for the whole chip will be
>> too restrictive, I am pretty sure.
>>
>> Thanks,
>> Sekhar
>>
> 
> In the previous review, you requested that this be changed to -1 [1].
> 
> If we change it back to 0, it will also require reverting a patch to the
> phy driver that has already been merged[2].

Sigh. Sorry about going around in circles on this one. Lets go with what
you have. If and when there is a need for another syscon node, the
driver and platform code can be updated. At least we will know why the
change is being done at that time.

Thanks,
Sekhar
--
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: link state problem with dwc3 in supper-speed device mode

[Felipe Balbi]

Hi,

Bin Liu  writes:
>> >> > There is no VBUS detection on this device and board. Is the VBUS
>> >> > detection needed for dwc3 to work in device mode? 
>> >> 
>> >> In the case of DRA7x, you don't *really* need detection. All you need to
>> >> do is correctly update UTMI mailbox.
>> >
>> > But the UTMI mailbox is driven by extcon events, right? The board
>> > doesn't have external circuit or gpio to detect VBUS.
>> 
>> Then you should use ID event to *also* fiddle with VBUSVALID bit. That
>> used to work just fine, I guess commit below broke it:
>
> I don't understand how this dra7-evm worked before. dwc3 is in SS device
> mode, microB cable does not ground ID pin, so there is ID event when
> attach/detach dwc3 to the host. I am confused...

Please read about the mailbox in your SoC. Try to figure out how it
works and what it does. What happens, internally, when you write
VBUS_VALID and/or IDGND bits. What does that mean to dwc3? When can dwc3
connect its data pullups? What information does it need in order to do
that? Many of these questions will be answered ;-)

Hint: dwc3 doesn't know about any GPIOs or VBUS comparators or whatever
you may place in the PCB. DWC3 only understands PIPE3 and
ULPI/UTMI. So how does the mailbox come in the picture? Why do we need
it? Is it replacing any other component? Which component would that be?

cheers

-- 
balbi


signature.asc
Description: PGP signature

Re: link state problem with dwc3 in supper-speed device mode

[Roger Quadros]

Hi,

On 25/10/16 23:55, Bin Liu wrote:
> Felipe,
> 
> On Tue, Oct 25, 2016 at 08:57:26AM -0500, Bin Liu wrote:
>> On Tue, Oct 25, 2016 at 04:44:13PM +0300, Felipe Balbi wrote:
>>
>> [snip]
>>
 Just reviewed this patch, it seems to be the regression. But SS should
 not generate ID pin event either, right? SS uses far-end termination, it
 does not have ID pin as USB2.0. I will try to revert this patch to find
 out...
>>>
>>> it's not about speed :-) ID pin is used nevertheless to choose role, but
>>
>> Yeah, you are right. I messed it up with type-C, somehow thought ID pin
>> is not required for SS :-(
>>
>>> some TI boards didn't provide any methods for VBUS sampling, so ID pin
>>> was used to tell DWC3 if it should be host/device AND if VBUS_VALID or
>>> not.
>>>
>>> Note that we end up lying to the controller because we could set
>>> VBUS_VALID before VBUS really is valid, but it's better than never
>>> seeing a connection at all ;-)
>>
>> Make more sense now :-) I will play with the patch mentioned, and ensure
>> any future boards have vbus sampling so we can decouple it with ID pin
>> events in the UTMI mailbox.
>>
>> Still need to figure out why highspeed is not affected...
> 
> Ok, I think I understand most part of the problems now.
> 
> VBUS detect is required for disconnect event, so AM57x board design
> should have a GPIO for VBUS detect to feed to extcon.
> 
> 1. why only SS is affected on dra7-evm?
> 
> This is because of USB3.0 LPM. With g_zero, dwc3 SS in device mode goes
> to U2 after been enumerated, in which state dwc3 is unable to detect any
> change other than link change. But dwc3 HS stays in U0 after been
> enumerated, so the link goes to RX.Detect after detach from the host. So
> dwc3 HS can still detect the connect to host even with lack of
> disconnect interrupt.
> 
> 2. why dra7-evm used to work?
> 
> Very likely the kernel at that time does not support LPM, so
> dwc3 SS is still in U0 after been enumerated, the same case as in HS
> above. At least this is what I see with kernel 3.14, in which dwc3 SS
> doesn't go to U2.

So does this mean that it still won't work with the suspected patch
removed? As there is no way of telling about VBUS status on dra7-evm.

How can we workaround this on that evm? is disabling LPM on dra7-evm possible?
> 
> 
> Thanks for helping me understanding this. I will ensure any future board
> design will have VBUS detect.
> 

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

Re: [GIT PULL] usb: chipidea: fixes for v4.9

[Greg KH]

On Wed, Oct 26, 2016 at 11:03:20AM +0800, Peter Chen wrote:
> The following changes since commit b76032396d7958f006bccf5fb2535beb5526837c:
> 
>   usb: renesas_usbhs: add wait after initialization for R-Car Gen3 
> (2016-10-24 14:35:46 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/ 
> tags/usb-ci-v4.9-rc2

Pulled and pushed out, 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