Re: [PATCH] usb: dwc2: introduce config parameter to ignore supplies vusb_a and vusb_d

[Heiner Kallweit]

Am 31.01.2017 um 03:32 schrieb John Youn:
> On 1/28/2017 2:06 PM, Heiner Kallweit wrote:
>> Supplies for vusb_a and vusb_d are needed only on a minority of systems
>> supported by the dwc2 driver (AFAIK systems with Samsung SoCs).
>>
>> On all other systems this results in these harmless but annoying
>> warnings:
>>
>> c900.usb supply vusb_d not found, using dummy regulator
>> c900.usb supply vusb_a not found, using dummy regulator
>>
>> Introduce a configuration parameter to ignore the supplies on
>> systems not needing it.
> 
> You can probably just check for the existence of those bindings. Or
> possibly use devm_regulator_get_optional().
> 
Right, that we could do to silence the warning. But then we would
loose the warning on systems where these supplies are mandatory
(in case somebody adds a system with such a SoC and forgets to define
the supplies in the DT).

> Also, reviewing this code, it looks like vusb_d and vusb_a should have
> been documented as dwc2 bindings but never were...
> 
> John
> 

--
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: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[gre...@linuxfoundation.org]

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?


http://daringfireball.net/2007/07/on_top

On Tue, Jan 31, 2017 at 05:21:46AM +, Ajay Kaher wrote:
> 
>  
> At boot time, probe function of multiple connected devices
> (proprietary devices) execute simultaneously.

What exactly do you mean here?  How can probe happen "simultaneously"?
The USB core prevents this, right?

And what do you mean exactly by "(proprietary devices)"?

> And because of the following code path race condition happens:
> probe->usb_register_dev->init_usb_class

Why is this just showing up now, and hasn't been an issue for the decade
or so this code has been around?  What changed?

> Tested with these changes, and problem has been solved.

What changes?

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: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Ajay Kaher]

 
At boot time, probe function of multiple connected devices
(proprietary devices) execute simultaneously. And because
of the following code path race condition happens:
probe->usb_register_dev->init_usb_class

Tested with these changes, and problem has been solved.

thanks,
ajay kaher


- Original Message -
Sender : gre...@linuxfoundation.org 
Date   : 2017-01-30 14:36 (GMT+5:30)
Title  : Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race 
Condition when two USB class drivers try to call init_usb_class simultaneously
 
On Mon, Jan 30, 2017 at 08:25:25AM +, Ajay Kaher wrote:
>  
 
First off, you are sending html email, which the mailing list keeps
rejecting, why are you ignoring that?
 
 
 
> 
> There is race condition when two USB class drivers try to call
> 
> init_usb_class at the same time and leads to crash.
> 
>  
> 
> The main reason for this is one of the Class drivers allocates memory
> for usb_class structure and initializes its member. In the meantime NULL
> check for usb_class structure fails and assumes that usb_class structure
> is properly initialized and crashed while trying to access its members.
> 
>  
> 
> To avoid this race condition locking required before calling
> init_usb_class from function usb_register_dev.
> 
>  
> 
>  
> 
> Signed-off-by: Ajay Kaher
 
Does this look correct?  Please work with some of the samsung kernel
developers for how to properly submit a patch.
 
And finally, how are two drivers calling init_usb_class() at the same
time?  What code path causes that?  Have you seen this happen, and if
so, what drivers caused it?
 
thanks,
 
greg k-h
 
 

Re: [PATCH v4 1/5] usb: dwc2: Add support for STM32F429/439/469 USB OTG HS/FS in FS mode (internal PHY)

[John Youn]

On 1/28/2017 6:21 PM, Bruno Herrera wrote:
> This patch introduces a new parameter to activate USB OTG HS/FS core embedded
> phy transceiver. The STM32F4x9 SoC uses the GGPIO register to enable the 
> transceiver.
> Also add the dwc2_core_params structure for stm32f4 otg fs.
>

Could you fix the "checkpatch --strict" issues?

Thanks,
John


> Signed-off-by: Bruno Herrera 
> ---
>  drivers/usb/dwc2/core.h   |  4 
>  drivers/usb/dwc2/hcd.c| 13 -
>  drivers/usb/dwc2/hw.h |  2 ++
>  drivers/usb/dwc2/params.c | 20 
>  4 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index b9b62f1..ed8ce42 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -423,6 +423,9 @@ enum dwc2_ep0_state {
>   *   needed.
>   *   0 - No (default)
>   *   1 - Yes
> + * @activate_transceiver: Activate internal transceiver using GGPIO register.
> + *   0 - Deactivate the transceiver (default)
> + *   1 - Activate the transceiver
>   * @g_dma:  Enables gadget dma usage (default: autodetect).
>   * @g_dma_desc: Enables gadget descriptor DMA (default: autodetect).
>   * @g_rx_fifo_size:  The periodic rx fifo size for the device, in
> @@ -477,6 +480,7 @@ struct dwc2_core_params {
>   bool uframe_sched;
>   bool external_id_pin_ctl;
>   bool hibernation;
> + bool activate_transceiver;
>   u16 max_packet_count;
>   u32 max_transfer_size;
>   u32 ahbcfg;
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index a73722e..190a441 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -121,7 +121,7 @@ static void dwc2_init_fs_ls_pclk_sel(struct dwc2_hsotg 
> *hsotg)
>
>  static int dwc2_fs_phy_init(struct dwc2_hsotg *hsotg, bool select_phy)
>  {
> - u32 usbcfg, i2cctl;
> + u32 usbcfg, ggpio, i2cctl;
>   int retval = 0;
>
>   /*
> @@ -145,6 +145,17 @@ static int dwc2_fs_phy_init(struct dwc2_hsotg *hsotg, 
> bool select_phy)
>   return retval;
>   }
>   }
> +
> + ggpio = dwc2_readl(hsotg->regs + GGPIO);
> + if (!(ggpio & GGPIO_STM32_OTG_GCCFG_PWRDWN) &&
> + (hsotg->params.activate_transceiver > 0)) {
> + dev_dbg(hsotg->dev, "Activating transceiver\n");
> + /* STM32F4x9 uses the GGPIO register as general core
> +  * configuration register.
> +  */
> + ggpio |= GGPIO_STM32_OTG_GCCFG_PWRDWN;
> + dwc2_writel(ggpio, hsotg->regs + GGPIO);
> + }
>   }
>
>   /*
> diff --git a/drivers/usb/dwc2/hw.h b/drivers/usb/dwc2/hw.h
> index bde7248..9b432c1 100644
> --- a/drivers/usb/dwc2/hw.h
> +++ b/drivers/usb/dwc2/hw.h
> @@ -225,6 +225,8 @@
>
>  #define GPVNDCTL HSOTG_REG(0x0034)
>  #define GGPIOHSOTG_REG(0x0038)
> +#define GGPIO_STM32_OTG_GCCFG_PWRDWN (1 << 16)
> +
>  #define GUID HSOTG_REG(0x003c)
>  #define GSNPSID  HSOTG_REG(0x0040)
>  #define GHWCFG1  HSOTG_REG(0x0044)
> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
> index 2990c34..a35abba 100644
> --- a/drivers/usb/dwc2/params.c
> +++ b/drivers/usb/dwc2/params.c
> @@ -120,6 +120,23 @@ static void dwc2_set_amcc_params(struct dwc2_hsotg 
> *hsotg)
>   p->ahbcfg = GAHBCFG_HBSTLEN_INCR16 << GAHBCFG_HBSTLEN_SHIFT;
>  }
>
> +static void dwc2_set_stm32f4x9_fsotg_params(struct dwc2_hsotg *hsotg)
> +{
> + struct dwc2_core_params *p = >params;
> +
> + p->otg_cap = DWC2_CAP_PARAM_NO_HNP_SRP_CAPABLE;
> + p->speed = DWC2_SPEED_PARAM_FULL;
> + p->host_rx_fifo_size = 128;
> + p->host_nperio_tx_fifo_size = 96;
> + p->host_perio_tx_fifo_size = 96;
> + p->max_packet_count = 256;
> + p->phy_type = DWC2_PHY_TYPE_PARAM_FS;
> + p->i2c_enable = false;
> + p->uframe_sched = false;
> + p->activate_transceiver = true;
> +
> +}
> +
>  const struct of_device_id dwc2_of_match_table[] = {
>   { .compatible = "brcm,bcm2835-usb", .data = dwc2_set_bcm_params },
>   { .compatible = "hisilicon,hi6220-usb", .data = dwc2_set_his_params  },
> @@ -133,6 +150,9 @@ const struct of_device_id dwc2_of_match_table[] = {
>   { .compatible = "amlogic,meson-gxbb-usb",
> .data = dwc2_set_amlogic_params },
>   { .compatible = "amcc,dwc-otg", .data = dwc2_set_amcc_params },
> + { .compatible = "st,stm32f4x9-fsotg",
> +   .data = dwc2_set_stm32f4x9_fsotg_params },
> + { .compatible = "st,stm32f4x9-hsotg" },
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
>

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a 

Re: [PATCH] usb: dwc2: introduce config parameter to ignore supplies vusb_a and vusb_d

[John Youn]

On 1/28/2017 2:06 PM, Heiner Kallweit wrote:
> Supplies for vusb_a and vusb_d are needed only on a minority of systems
> supported by the dwc2 driver (AFAIK systems with Samsung SoCs).
>
> On all other systems this results in these harmless but annoying
> warnings:
>
> c900.usb supply vusb_d not found, using dummy regulator
> c900.usb supply vusb_a not found, using dummy regulator
>
> Introduce a configuration parameter to ignore the supplies on
> systems not needing it.

You can probably just check for the existence of those bindings. Or
possibly use devm_regulator_get_optional().

Also, reviewing this code, it looks like vusb_d and vusb_a should have
been documented as dwc2 bindings but never were...

John
--
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: Atheros bluetooth controller --have to powercycle usb port after suspend/resume

[Leif Liddy]

Please disregard this email thread as this is has been identified as a
bluetooth driver issue. Email has been forward to the linux-bluetooth
email address.





On Mon, Jan 30, 2017 at 11:34 PM, Leif Liddy  wrote:
> Hello,
>
> I have a Samsung ATIV Book 9 12.2 (2015) that has an Atheros bluetooth
> controller that's connect to the internal usb bus.
>
> Bus 001 Device 002: ID 0cf3:e300 Atheros Communications, Inc.
>
> After I suspend and resume the laptop,  I can longer connect to the
> bluetooth controller. The systems log shows the following:
>
> 193.828240] Bluetooth: hci0 command 0x200c tx timeout
> [11195.876185] Bluetooth: hci0 command 0x200b tx timeout
> [11197.923994] Bluetooth: hci0 command 0x200c tx timeout
> [11199.971846] Bluetooth: hci0 command 0x200c tx timeout
> ...
>
> **I normally have to suspend it for at least 10-20 minutes before this
> occurs. If I suspend the laptop for just a few minutes, there's no
> issue.
>
> I have tried almost everything to get the bluetooth controller back
> online. I've unload/loaded all bluetooth (and network) modules, tried
> restarting the bluetooth service.
>
> Nothing worked until I tried:
> echo 0 > /sys/bus/usb/devices/1-4/authorized
> echo 1 > /sys/bus/usb/devices/1-4/authorized
>
> This brings the bluetooth controller back online immediately. I would
> like to know if there's is a kernel-level fix for this issue. I just
> need someone to point me in the right direction to identify the source
> of this issue. I can provide you with any system information or logs
> that you need. I'm pretty sure this is a usb-specific issue not a
> bluetooth one, but I could be wrong.
>
> I'm running Fedora 25 with the latest stable kernel: 4.9.5-200.fc25.x86_64
>
> Thanks!
>
> -Leif Liddy
--
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

linux USB dwc3 not working

[andy_purcell]

Hello,

I am starting work on a board that has the Intel Skylake chipset, which has 
hardware for doing USB-device. 
The Intel chipset USB-device hardware is the Synopsys DesignWare Controller 3, 
aka "dwc3". 
The Linux source tree has code for dwc3, so I thought to try running Linux on 
this board.

The USB-device function is hard-wired on my board to be USB-device.
Cannot be OTG. Cannot be USB-host.

I boot Ubuntu Desktop 16.04, kernel = 4.4.0-59, to test the USB-device function.
Using a script, I set up the USB-device to be RNDIS, using functionfs.
I connect a USB cable from my board to a USB-host. 
My USB analyzer shows nothing happens. No connection, no SETUP packets, nothing.

To troubleshoot, I try turning on some test modes, using the Linux debugfs 
interface.
The debugfs interface is in this directory: 
/sys/kernel/debug/dwc3.0.auto 
I see link_state, mode, regdump, testmode files. 

* echo "test_j" > testmode
I see D+ go high, D- stays low. 
* echo "test_k" > testmode
No change on D+
No change on D- 
This is not correct. 
* echo "test_se0_nak" > testmode
No changes. 
* echo "test_packet" 
D+ goes low, D- remains low. 

OK, so here are my questions. 

1)  Should I expect Ubuntu 16.04 dwc3 code to work? 
(uname -a shows kernel level is 4.4.0-59)  
I ask, because kernel.org shows recent changes in dwc3 code. 

2)  The Linux dwc3 code appears to be written to work with several 
different USB phy's. 
I see dwc3-exynos.c, dwc3-keystone.c, dwc3-omap.c, dwc3-pci.c, 
dwc3-of-simple.c, etc. 
The schematic for my board shows there is no external USB2 phy and no 
external USB3 phy.
For my board, the phy's are internal to the Skylake chipset.
a.  Should the Linux dwc3 code work without an external phy?
b.  Is there some configuration I need to do for my board?

Andy Purcell

--
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: host - Fix possible NULL derefrence.

[Greg Kroah-Hartman]

On Mon, Jan 30, 2017 at 08:03:23AM +0100, Thierry Reding wrote:
> On Mon, Jan 30, 2017 at 07:45:21AM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Jan 30, 2017 at 10:36:29AM +0530, Shailendra Verma wrote:
> > > of_device_get_match_data could return NULL, and so can cause
> > > a NULL pointer dereference later.
> > > 
> > > Signed-off-by: Shailendra Verma 
> > > ---
> > >  drivers/usb/host/xhci-tegra.c |4 
> > >  1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
> > > index a59fafb..890c778 100644
> > > --- a/drivers/usb/host/xhci-tegra.c
> > > +++ b/drivers/usb/host/xhci-tegra.c
> > > @@ -903,6 +903,10 @@ static int tegra_xusb_probe(struct platform_device 
> > > *pdev)
> > >   return -ENOMEM;
> > >  
> > >   tegra->soc = of_device_get_match_data(>dev);
> > > + if (!tegra->soc) {
> > 
> > How would the driver be loaded and the probe function called if this
> > returns NULL?
> > 
> > Is this ever possible?
> 
> No, it isn't. I've been NAK'ing this kind of patch for a while now.
> There are two variants of this patch going about:
> 
>   1) checking the return value of of_match_device()
>   2) checking the return value of of_device_get_match_data()
> 
> The same may also apply to of_match_node(), but I haven't seen that used
> very much lately.
> 
> For of_match_device() the problem could technically occur if used in non
> OF setups, because the device could be instantiated by hand in board
> setup code. Tegra has been OF-only for a couple of years now, so there
> is no way this can happen today.
> 
> of_device_get_match_data() is somewhat more complicated because it could
> still return NULL if the OF table entry had its .data field set to NULL.
> However in all drivers that I know that would be considered a bug, so
> might as well let things crash at this point to make it immediately
> obvious.
> 
> I had once been tempted to write a checkpatch rule for this, but I'm not
> sure it's as easy as just warning if there's a check, because there are
> some legitimate cases, even if they're very rare.

Thanks for the info, patch is now dropped.

Shailendra, please be more careful.

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

[PATCH] usb: dwc3 dwc3_exynos_probe() change goto labels to meaningful names

[Shuah Khan]

Change goto labels to meaningful names from a series of errNs.

Signed-off-by: Shuah Khan 
---

Rebased to usb-next

 drivers/usb/dwc3/dwc3-exynos.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 1515d45..98f74ff 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -147,53 +147,53 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
exynos->vdd33 = devm_regulator_get(dev, "vdd33");
if (IS_ERR(exynos->vdd33)) {
ret = PTR_ERR(exynos->vdd33);
-   goto err2;
+   goto vdd33_err;
}
ret = regulator_enable(exynos->vdd33);
if (ret) {
dev_err(dev, "Failed to enable VDD33 supply\n");
-   goto err2;
+   goto vdd33_err;
}
 
exynos->vdd10 = devm_regulator_get(dev, "vdd10");
if (IS_ERR(exynos->vdd10)) {
ret = PTR_ERR(exynos->vdd10);
-   goto err3;
+   goto vdd10_err;
}
ret = regulator_enable(exynos->vdd10);
if (ret) {
dev_err(dev, "Failed to enable VDD10 supply\n");
-   goto err3;
+   goto vdd10_err;
}
 
ret = dwc3_exynos_register_phys(exynos);
if (ret) {
dev_err(dev, "couldn't register PHYs\n");
-   goto err4;
+   goto phys_err;
}
 
if (node) {
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
dev_err(dev, "failed to add dwc3 core\n");
-   goto err5;
+   goto populate_err;
}
} else {
dev_err(dev, "no device node, failed to add dwc3 core\n");
ret = -ENODEV;
-   goto err5;
+   goto populate_err;
}
 
return 0;
 
-err5:
+populate_err:
platform_device_unregister(exynos->usb2_phy);
platform_device_unregister(exynos->usb3_phy);
-err4:
+phys_err:
regulator_disable(exynos->vdd10);
-err3:
+vdd10_err:
regulator_disable(exynos->vdd33);
-err2:
+vdd33_err:
clk_disable_unprepare(exynos->axius_clk);
 axius_clk_err:
clk_disable_unprepare(exynos->susp_clk);
-- 
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 v4 0/3] dmaengine: cppi41: Add dma support to da8xx

[Alexandre Bailon]

This series add support of DA8xx to CPPI 4.1 driver.
As the CPPI 4.1 is now generic, we only had to add the glue for DA8xx.

This serie should applied on top of 
"[PATCH v3 0/7] dmaengine: cppi41: Make CPPI 4.1 driver more generic".

Changes in v4:
 - Fix the address overlaping between usb and cppi41 nodes.

Changes in v3:
 - Fix few typos
 - Don't use a wildcard for the compatible property

Changes in v2:
- most of patches of v1 has been moved to the series
  "[PATCH v2 0/7] dmaengine: cppi41: Make CPPI 4.1 driver more generic".
- some patches of v1 has been removed because they were no required
  anymore because CPPI 4.1 driver has been made more generic.
- In v1, the driver were managing the clock for DA8xx paltform.
  This is not needed as CPPI 4.1 will be a child of MUSB DA8xx glue,
  we can use PM runtime and let the DA8xx glue driver manage it.

Alexandre Bailon (3):
  dt/bindings: da8xx-usb: Add binding for the CPPI 4.1 DMA controller
  dmaengine: cppi41: Add support of DA8xx to CPPI 4.1
  dmaengine: cppi41: Fix teardown warnings

 .../devicetree/bindings/usb/da8xx-usb.txt  | 41 +-
 drivers/dma/Kconfig|  6 ++--
 drivers/dma/cppi41.c   | 27 --
 3 files changed, 68 insertions(+), 6 deletions(-)

-- 
2.10.2

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

[PATCH v4 2/3] dmaengine: cppi41: Add support of DA8xx to CPPI 4.1

[Alexandre Bailon]

The DA8xx has a CPPI 4.1 DMA controller.
This is add the glue layer required to make it work on DA8xx.

Signed-off-by: Alexandre Bailon 
---
 drivers/dma/Kconfig  |  6 +++---
 drivers/dma/cppi41.c | 23 +++
 2 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 0d6a96e..2a31e1a 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -514,12 +514,12 @@ config TIMB_DMA
  Enable support for the Timberdale FPGA DMA engine.
 
 config TI_CPPI41
-   tristate "AM33xx CPPI41 DMA support"
-   depends on ARCH_OMAP
+   tristate "CPPI 4.1 DMA support"
+   depends on (ARCH_OMAP || ARCH_DAVINCI_DA8XX)
select DMA_ENGINE
help
  The Communications Port Programming Interface (CPPI) 4.1 DMA engine
- is currently used by the USB driver on AM335x platforms.
+ is currently used by the USB driver on AM335x and DA8xx platforms.
 
 config TI_DMA_CROSSBAR
bool
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 21a4f79..5c501da 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -221,6 +221,20 @@ static const struct chan_queues am335x_usb_queues_rx[] = {
[29] = { .submit = 30, .complete = 155},
 };
 
+static const struct chan_queues da8xx_usb_queues_tx[] = {
+   [0] = { .submit =  16, .complete = 24},
+   [1] = { .submit =  18, .complete = 24},
+   [2] = { .submit =  20, .complete = 24},
+   [3] = { .submit =  22, .complete = 24},
+};
+
+static const struct chan_queues da8xx_usb_queues_rx[] = {
+   [0] = { .submit =  1, .complete = 26},
+   [1] = { .submit =  3, .complete = 26},
+   [2] = { .submit =  5, .complete = 26},
+   [3] = { .submit =  7, .complete = 26},
+};
+
 struct cppi_glue_infos {
const struct chan_queues *queues_rx;
const struct chan_queues *queues_tx;
@@ -949,8 +963,17 @@ static const struct cppi_glue_infos am335x_usb_infos = {
.qmgr_num_pend = 5,
 };
 
+static const struct cppi_glue_infos da8xx_usb_infos = {
+   .queues_rx = da8xx_usb_queues_rx,
+   .queues_tx = da8xx_usb_queues_tx,
+   .td_queue = { .submit = 31, .complete = 0 },
+   .first_completion_queue = 24,
+   .qmgr_num_pend = 2,
+};
+
 static const struct of_device_id cppi41_dma_ids[] = {
{ .compatible = "ti,am3359-cppi41", .data = _usb_infos},
+   { .compatible = "ti,da830-cppi41", .data = _usb_infos},
{},
 };
 MODULE_DEVICE_TABLE(of, cppi41_dma_ids);
-- 
2.10.2

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

[PATCH v4 3/3] dmaengine: cppi41: Fix teardown warnings

[Alexandre Bailon]

During the teardown of a RX channel, because there is only one
completion queue available for RX channel, descriptor of another
channel may be popped which will cause 2 warnings:
- the first one because we popped a wrong descriptor
  (neither the channel's descriptor, nor the teardown descriptor).
- the second one happen during the teardown of another channel,
  because we can't find the channel descriptor
  (that is, the one that caused the first warning).
To avoid that, use one free queue instead of a transmit completion queue.

Note that fix doesn't fix all the teardown warnings:
I still get some when I run some corner case.

Signed-off-by: Alexandre Bailon 
---
 drivers/dma/cppi41.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 5c501da..9fdd824 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -629,7 +629,7 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
if (!c->is_tx) {
reg |= GCR_STARV_RETRY;
reg |= GCR_DESC_TYPE_HOST;
-   reg |= c->q_comp_num;
+   reg |= cdd->td_queue.complete;
}
reg |= GCR_TEARDOWN;
cppi_writel(reg, c->gcr_reg);
@@ -640,7 +640,7 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
if (!c->td_seen || !c->td_desc_seen) {
 
desc_phys = cppi41_pop_desc(cdd, cdd->td_queue.complete);
-   if (!desc_phys)
+   if (!desc_phys && c->is_tx)
desc_phys = cppi41_pop_desc(cdd, c->q_comp_num);
 
if (desc_phys == c->desc_phys) {
-- 
2.10.2

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

[PATCH v5] ARM: dts: da850: Add the CPPI 4.1 DMA to the USB OTG controller

[Alexandre Bailon]

This adds the CPPI 4.1 DMA controller to the USB OTG controller.

Changes since v4:
 - Fix the overlaping address between usb and cppi41 nodes.

Signed-off-by: Alexandre Bailon 
---
 arch/arm/boot/dts/da850.dtsi | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 104155d..70ad3e8 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -395,13 +395,38 @@
};
usb0: usb@20 {
compatible = "ti,da830-musb";
-   reg = <0x20 0x1>;
+   reg = <0x20 0x1000>;
+   ranges;
interrupts = <58>;
interrupt-names = "mc";
dr_mode = "otg";
phys = <_phy 0>;
phy-names = "usb-phy";
status = "disabled";
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   dmas = < 0 0  1 0
+2 0  3 0
+0 1  1 1
+2 1  3 1>;
+   dma-names =
+   "rx1", "rx2", "rx3", "rx4",
+   "tx1", "tx2", "tx3", "tx4";
+
+   cppi41dma: dma-controller@201000 {
+   compatible = "ti,da830-cppi41";
+   reg =  <0x201000 0x1000
+   0x202000 0x1000
+   0x204000 0x4000>;
+   reg-names = "controller",
+   "scheduler", "queuemgr";
+   interrupts = <58>;
+   #dma-cells = <2>;
+   #dma-channels = <4>;
+   status = "okay";
+   };
};
mdio: mdio@224000 {
compatible = "ti,davinci_mdio";
-- 
2.10.2

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

[PATCH v4 1/3] dt/bindings: da8xx-usb: Add binding for the CPPI 4.1 DMA controller

[Alexandre Bailon]

DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx CPPI 4.1 DMA controller.

Signed-off-by: Alexandre Bailon 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/usb/da8xx-usb.txt  | 41 +-
 1 file changed, 40 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt 
b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
index ccb844a..717c5f6 100644
--- a/Documentation/devicetree/bindings/usb/da8xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
@@ -18,10 +18,26 @@ Required properties:
 
  - phy-names: Should be "usb-phy"
 
+ - dmas: specifies the dma channels
+
+ - dma-names: specifies the names of the channels. Use "rxN" for receive
+   and "txN" for transmit endpoints. N specifies the endpoint number.
+
 Optional properties:
 
  - vbus-supply: Phandle to a regulator providing the USB bus power.
 
+DMA
+~~~
+- compatible: ti,da830-cppi41
+- reg: offset and length of the following register spaces: CPPI DMA Controller,
+  CPPI DMA Scheduler, Queue Manager
+- reg-names: "controller", "scheduler", "queuemgr"
+- #dma-cells: should be set to 2. The first number represents the
+  channel number (0 … 3 for endpoints 1 … 4).
+  The second number is 0 for RX and 1 for TX transfers.
+- #dma-channels: should be set to 4 representing the 4 endpoints.
+
 Example:
usb_phy: usb-phy {
compatible = "ti,da830-usb-phy";
@@ -30,7 +46,10 @@ Example:
};
usb0: usb@20 {
compatible = "ti,da830-musb";
-   reg =   <0x0020 0x1>;
+   reg = <0x0020 0x1000>;
+   ranges;
+   #address-cells = <1>;
+   #size-cells = <1>;
interrupts = <58>;
interrupt-names = "mc";
 
@@ -39,5 +58,25 @@ Example:
phys = <_phy 0>;
phy-names = "usb-phy";
 
+   dmas = < 0 0  1 0
+2 0  3 0
+0 1  1 1
+2 1  3 1>;
+   dma-names =
+   "rx1", "rx2", "rx3", "rx4",
+   "tx1", "tx2", "tx3", "tx4";
+
status = "okay";
+
+   cppi41dma: dma-controller@201000 {
+   compatible = "ti,da830-cppi41";
+   reg =  <0x201000 0x1000
+   0x202000 0x1000
+   0x204000 0x4000>;
+   reg-names = "controller", "scheduler", "queuemgr";
+   interrupts = <58>;
+   #dma-cells = <2>;
+   #dma-channels = <4>;
+   };
+
};
-- 
2.10.2

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

Re: Advanced Format SAT devices show incorrect physical block size

[Pali Rohár]

On Monday 30 January 2017 17:17:03 Alan Stern wrote:
> On Sun, 29 Jan 2017, Pali Rohár wrote:
> > On Wednesday 11 January 2017 16:23:29 Alan Stern wrote:
> > > On Tue, 10 Jan 2017, James Bottomley wrote:
> > > > On Tue, 2017-01-10 at 16:00 -0500, Alan Stern wrote:
> > > > > In theory, I suppose we could change the kernel so that it
> > > > > would default to READ CAPACITY(16) for devices that report a
> > > > > SCSI level
> > > > > 
> > > > > >= 3, or something along those lines.  In general we hesitate
> > > > > >to
> > > > > 
> > > > > make changes of this sort, because they almost always end up
> > > > > breaking _some_ devices -- and if that happens then the
> > > > > change is reverted, with no exceptions.  Linus has a very
> > > > > strict rule about not breaking working systems.
> > > > 
> > > > You shouldn't have to change anything: it already does
> > > > (otherwise how else would we detect physical exponent for
> > > > proper SCSI devices) see sd.c:sd_try_rc16_first().  It always
> > > > returns false for USB because you set sdev->try_rc_10_first
> > > 
> > > In fact, this approach probably won't work.  See Bugzilla entries
> > > #43265 and #43391.  The devices in those reports claimed to be
> > > ANSI level 4, but they failed anyway.
> > 
> > Seems those devices return capacity 0x7F0001 or
> > 0xFF0001 Maybe there is some error pattern?
> 
> As far as I can tell, they both reported 0xFF0001.  That's a
> pattern -- unless somebody really does have a storage device that
> large (18 exabytes).  For the time being, perhaps we can ignore this
> possibility.
> 
> > > If you guys want to try the quirk flag, you can apply the patch
> > > below. Then set the usb-storage module parameter
> > > quirks=::k where  and  are the Vendor and
> > > Product ID codes for your device (as 4 hex digits).
> > > 
> > > In the long run, however, this is not a viable approach.  We'd be
> > > better off with an explicit blacklist.
> > 
> > Ok, so what are next steps? I think that explicit blacklist would
> > be needed if "bad" devices is less.
> > 
> > How many bug reports were there?
> 
> I don't know.
> 
> Anyway, please try out the patch below.  I don't know if it will be
> acceptable to the SCSI maintainers, but we should at least make sure
> it fixes your problem before submitting it.

I'm not original reporter of this problem.

Dainius, can you test it?

> Alan Stern
> 
> 
> 
> 
> Index: usb-4.x/drivers/scsi/sd.c
> ===
> --- usb-4.x.orig/drivers/scsi/sd.c
> +++ usb-4.x/drivers/scsi/sd.c
> @@ -2157,6 +2157,13 @@ static int read_capacity_16(struct scsi_
>   return -ENODEV;
>   }
> 
> + /* Some buggy devices report an impossibly large size */
> + if (lba >= (1ULL << 54)) {
> + sd_printk(KERN_WARNING, sdkp, "Read Capacity(16) returned
> excessively large value: %llu", lba); +   sdkp->capacity = 0;
> + return -EINVAL;
> + }
> +
>   if ((sizeof(sdkp->capacity) == 4) && (lba >= 0xULL)) {
>   sd_printk(KERN_ERR, sdkp, "Too big for this kernel. Use a "
>   "kernel compiled with support for large block "
> Index: usb-4.x/drivers/usb/storage/scsiglue.c
> ===
> --- usb-4.x.orig/drivers/usb/storage/scsiglue.c
> +++ usb-4.x/drivers/usb/storage/scsiglue.c
> @@ -247,8 +247,11 @@ static int slave_configure(struct scsi_d
>* Tell the SCSI layer to try READ_CAPACITY_10 first.
>* However some USB 3.0 drive enclosures return capacity
>* modulo 2TB. Those must use READ_CAPACITY_16
> +  *
> +  * Assume SPC3 or later devices can handle READ_CAPACITY_16.
>*/
> - if (!(us->fflags & US_FL_NEEDS_CAP16))
> + if (sdev->scsi_level <= SCSI_SPC_2 &&
> + !(us->fflags & US_FL_NEEDS_CAP16))
>   sdev->try_rc_10_first = 1;
> 
>   /* assume SPC3 or latter devices support sense size > 18 */

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v16 3/3] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY

[kbuild test robot]

Hi Heikki,

[auto build test WARNING on usb/usb-testing]
[also build test WARNING on v4.10-rc6 next-20170130]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Heikki-Krogerus/lib-string-add-sysfs_match_string-helper/20170130-214825
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing


coccinelle warnings: (new ones prefixed by >>)

>> drivers/usb/typec/typec.c:1249:1-3: WARNING: PTR_ERR_OR_ZERO can be used

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
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: typec: fix ptr_ret.cocci warnings

[kbuild test robot]

drivers/usb/typec/typec.c:1249:1-3: WARNING: PTR_ERR_OR_ZERO can be used


 Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR

Generated by: scripts/coccinelle/api/ptr_ret.cocci

CC: Heikki Krogerus 
Signed-off-by: Fengguang Wu 
---

 typec.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -1246,9 +1246,7 @@ EXPORT_SYMBOL_GPL(typec_unregister_port)
 static int __init typec_init(void)
 {
typec_class = class_create(THIS_MODULE, "typec");
-   if (IS_ERR(typec_class))
-   return PTR_ERR(typec_class);
-   return 0;
+   return PTR_ERR_OR_ZERO(typec_class);
 }
 subsys_initcall(typec_init);
 
--
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: Advanced Format SAT devices show incorrect physical block size

[Alan Stern]

On Sun, 29 Jan 2017, Pali Rohár wrote:

> On Wednesday 11 January 2017 16:23:29 Alan Stern wrote:
> > On Tue, 10 Jan 2017, James Bottomley wrote:
> > > On Tue, 2017-01-10 at 16:00 -0500, Alan Stern wrote:
> > > > In theory, I suppose we could change the kernel so that it would
> > > > default to READ CAPACITY(16) for devices that report a SCSI level
> > > > >= 3, or something along those lines.  In general we hesitate to
> > > > make changes of this sort, because they almost always end up
> > > > breaking _some_ devices -- and if that happens then the change
> > > > is reverted, with no exceptions.  Linus has a very strict rule
> > > > about not breaking working systems.
> > > 
> > > You shouldn't have to change anything: it already does (otherwise
> > > how else would we detect physical exponent for proper SCSI
> > > devices) see sd.c:sd_try_rc16_first().  It always returns false
> > > for USB because you set sdev->try_rc_10_first
> > 
> > In fact, this approach probably won't work.  See Bugzilla entries
> > #43265 and #43391.  The devices in those reports claimed to be ANSI
> > level 4, but they failed anyway.
> 
> Seems those devices return capacity 0x7F0001 or 0xFF0001
> Maybe there is some error pattern?

As far as I can tell, they both reported 0xFF0001.  That's a 
pattern -- unless somebody really does have a storage device that 
large (18 exabytes).  For the time being, perhaps we can ignore this 
possibility.

> > If you guys want to try the quirk flag, you can apply the patch
> > below. Then set the usb-storage module parameter quirks=::k
> > where  and  are the Vendor and Product ID codes for your
> > device (as 4 hex digits).
> > 
> > In the long run, however, this is not a viable approach.  We'd be
> > better off with an explicit blacklist.
> 
> Ok, so what are next steps? I think that explicit blacklist would be 
> needed if "bad" devices is less.
> 
> How many bug reports were there?

I don't know.

Anyway, please try out the patch below.  I don't know if it will be 
acceptable to the SCSI maintainers, but we should at least make sure it 
fixes your problem before submitting it.

Alan Stern




Index: usb-4.x/drivers/scsi/sd.c
===
--- usb-4.x.orig/drivers/scsi/sd.c
+++ usb-4.x/drivers/scsi/sd.c
@@ -2157,6 +2157,13 @@ static int read_capacity_16(struct scsi_
return -ENODEV;
}
 
+   /* Some buggy devices report an impossibly large size */
+   if (lba >= (1ULL << 54)) {
+   sd_printk(KERN_WARNING, sdkp, "Read Capacity(16) returned 
excessively large value: %llu", lba);
+   sdkp->capacity = 0;
+   return -EINVAL;
+   }
+
if ((sizeof(sdkp->capacity) == 4) && (lba >= 0xULL)) {
sd_printk(KERN_ERR, sdkp, "Too big for this kernel. Use a "
"kernel compiled with support for large block "
Index: usb-4.x/drivers/usb/storage/scsiglue.c
===
--- usb-4.x.orig/drivers/usb/storage/scsiglue.c
+++ usb-4.x/drivers/usb/storage/scsiglue.c
@@ -247,8 +247,11 @@ static int slave_configure(struct scsi_d
 * Tell the SCSI layer to try READ_CAPACITY_10 first.
 * However some USB 3.0 drive enclosures return capacity
 * modulo 2TB. Those must use READ_CAPACITY_16
+*
+* Assume SPC3 or later devices can handle READ_CAPACITY_16.
 */
-   if (!(us->fflags & US_FL_NEEDS_CAP16))
+   if (sdev->scsi_level <= SCSI_SPC_2 &&
+   !(us->fflags & US_FL_NEEDS_CAP16))
sdev->try_rc_10_first = 1;
 
/* assume SPC3 or latter devices support sense size > 18 */

--
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: dwc3 gadget breaks on system suspend/resume

[Felipe Balbi]

Hi,

Felipe Balbi  writes:
> Roger Quadros  writes:
>>> Roger Quadros  writes:
> (hmm, I didn't receive your reply in my intel inbox, only
> gmail. Odd. Replying to myself here, but it should be on your reply,
> rater).
>
> Felipe Balbi  writes:
>>> The previous commit c499ff71ff2a281366c6ec7a904c547d806cbcd1 is fine.
>>
>> okay. Then let's try to figure out what's going on. A diff of regdump
>> before and after suspend/resume might start to give some clue about
>> what's going on. DWC3 tracepoints should help too. Care to get those?
>> BTW, is this dwc3 as host or peripheral?
>
> You don't have any endpoints enabled:
>
> -DALEPENA = 0x000f
> +DALEPENA = 0x

 Thanks for the hints.

 This problem is because reason dwc3_gadget_run_stop() is timing out
 during the suspend sequence and so dwc3_disconnect_gadget() and
 __dwc3_gadget_stop() are not being called.
>>> 
>>> I see
>>> 
 dwc3_suspend() does not consider dwc3_gadget_suspend()'s return value
 and happily continues suspending the machine.

 If I force dwc3_gadget_run_stop() to return 0 then everything works fine.

 Any ideas why DWC3_DSTS_DEVCTRLHLT is not getting set?
>>> 
>>> no idea. It should always get set when run_stop is cleared. Can you
>>> check if suspending with cable detached has any difference?
>>
>> After cable detach, it still timed out the next suspend. But on
>> subsequent suspends there were no timeouts. (I didn't plug the cable
>> back at all)
>>
>> This behaviour is on dra7. I will test the behaviour on am43x as well.
>
> wonder if there's something odd with 2.02a. AM437x is 2.40a IIRC,
> testing that is, indeed, a good idea.

What if your platform just takes longer to halt?

Can you try below?

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 4db97ecae885..d2e405793b1f 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1586,7 +1586,7 @@ static int dwc3_gadget_set_selfpowered(struct usb_gadget 
*g,
 static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on, int suspend)
 {
u32 reg;
-   u32 timeout = 500;
+   u32 timeout = 50;
 
if (pm_runtime_suspended(dwc->dev))
return 0;


-- 
balbi


signature.asc
Description: PGP signature

Re: dwc3 gadget breaks on system suspend/resume

[Felipe Balbi]

Hi,

Roger Quadros  writes:
>> Roger Quadros  writes:
 (hmm, I didn't receive your reply in my intel inbox, only
 gmail. Odd. Replying to myself here, but it should be on your reply,
 rater).

 Felipe Balbi  writes:
>> The previous commit c499ff71ff2a281366c6ec7a904c547d806cbcd1 is fine.
>
> okay. Then let's try to figure out what's going on. A diff of regdump
> before and after suspend/resume might start to give some clue about
> what's going on. DWC3 tracepoints should help too. Care to get those?
> BTW, is this dwc3 as host or peripheral?

 You don't have any endpoints enabled:

 -DALEPENA = 0x000f
 +DALEPENA = 0x
>>>
>>> Thanks for the hints.
>>>
>>> This problem is because reason dwc3_gadget_run_stop() is timing out
>>> during the suspend sequence and so dwc3_disconnect_gadget() and
>>> __dwc3_gadget_stop() are not being called.
>> 
>> I see
>> 
>>> dwc3_suspend() does not consider dwc3_gadget_suspend()'s return value
>>> and happily continues suspending the machine.
>>>
>>> If I force dwc3_gadget_run_stop() to return 0 then everything works fine.
>>>
>>> Any ideas why DWC3_DSTS_DEVCTRLHLT is not getting set?
>> 
>> no idea. It should always get set when run_stop is cleared. Can you
>> check if suspending with cable detached has any difference?
>
> After cable detach, it still timed out the next suspend. But on
> subsequent suspends there were no timeouts. (I didn't plug the cable
> back at all)
>
> This behaviour is on dra7. I will test the behaviour on am43x as well.

wonder if there's something odd with 2.02a. AM437x is 2.40a IIRC,
testing that is, indeed, a good idea.

-- 
balbi


signature.asc
Description: PGP signature

PulseAudio daemon hangs after connect Fiio external DAC

[Den Lemniscatta]

Hello.
This bug was redirected from pulseaudio bugtracker
(https://bugs.freedesktop.org/show_bug.cgi?id=99260) and from kernel
bugtracker (https://bugzilla.kernel.org/show_bug.cgi?id=191941).

When I connect my Fiio X5 II as external DAC to my PC PulseAudio hangs
(unkillable). Google knows about this bug
(https://bbs.archlinux.org/viewtopic.php?id=202648http://forum.ubuntu.ru/index.php?topic=263700.0
https://ubuntuforums.org/showthread.php?t=2274844). The same problem
with Fiio X3 II. People says that problem assigned with xhci. I can't
check this because my motherboard doesn't support xhci disabling.
Fiio works fine without PulseAudio, through ALSA.

Dmesg log from my system in attach (dmesg.txt).

lsusb:
Bus 001 Device 005: ID 2972:0006

cat /proc/asound/cards attached (cards.txt).
pulseaudio log from forum (if you ask I can take log from my system)
attached (pulseaudio.txt).

My system:
Asus Z170-A, Intel i7-6700K, Fiio X5 II with last firmware, Arch linux
x64 (kernel 4.9.6), PulseAudio 10.0.
 0 [DAC]: USB-Audio - FiiO USB Audio Class 2.0 DAC  
   
  SmartAction FiiO USB Audio Class 2.0 DAC at 
usb-:00:14.0-11, high speed 
[ 7925.549335] input: SmartAction FiiO USB Audio Class 2.0 DAC as 
/devices/pci:00/:00:14.0/usb1/1-10/1-10:1.0/0003:2972:0006.0005/input/input22
[ 7925.604564] hid-generic 0003:2972:0006.0005: input,hidraw3: USB HID v2.01 
Device [SmartAction FiiO USB Audio Class 2.0 DAC] on usb-:00:14.0-10/input0
[ 7925.606232] usb 1-10: 1:3 : does not exist
[ 8109.747815] INFO: task pulseaudio:748 blocked for more than 120 seconds.
[ 8109.747817]   Tainted: G   O4.9.6-1-ARCH #1
[ 8109.747818] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 8109.747818] pulseaudio  D0   748635 0x0004
[ 8109.747821]  88045a3b6800  8804537a 
88046ed980c0
[ 8109.747822]  88045c238ec0 c900022c7ae8 81605cdf 
880278805800
[ 8109.747823]  00ffc900022c7ab8 88046ed980c0 c900022c7ac8 
8804537a
[ 8109.747824] Call Trace:
[ 8109.747827]  [] ? __schedule+0x22f/0x6e0
[ 8109.747829]  [] schedule+0x3d/0x90
[ 8109.747831]  [] usb_kill_urb.part.4+0x6c/0xa0 [usbcore]
[ 8109.747833]  [] ? wake_atomic_t_function+0x60/0x60
[ 8109.747835]  [] usb_kill_urb+0x21/0x30 [usbcore]
[ 8109.747837]  [] usb_hcd_flush_endpoint+0xad/0x170 [usbcore]
[ 8109.747838]  [] ? kernfs_find_ns+0x72/0xd0
[ 8109.747840]  [] usb_disable_endpoint+0x58/0xb0 [usbcore]
[ 8109.747841]  [] usb_disable_interface+0x45/0x60 [usbcore]
[ 8109.747843]  [] usb_set_interface+0x1a2/0x380 [usbcore]
[ 8109.747845]  [] snd_usb_init_sample_rate+0x1a4/0x3a0 
[snd_usb_audio]
[ 8109.747847]  [] snd_usb_pcm_prepare+0xb4/0x4e0 
[snd_usb_audio]
[ 8109.747849]  [] ? snd_pcm_stream_unlock+0x2d/0x50 [snd_pcm]
[ 8109.747850]  [] snd_pcm_do_prepare+0x17/0x30 [snd_pcm]
[ 8109.747851]  [] snd_pcm_action_single+0x2f/0x70 [snd_pcm]
[ 8109.747852]  [] snd_pcm_action_nonatomic+0x68/0x70 
[snd_pcm]
[ 8109.747854]  [] snd_pcm_common_ioctl1+0x470/0xbb0 [snd_pcm]
[ 8109.747855]  [] ? file_update_time+0xc8/0x110
[ 8109.747856]  [] snd_pcm_playback_ioctl1+0x139/0x260 
[snd_pcm]
[ 8109.747857]  [] ? do_mmap+0x3eb/0x4a0
[ 8109.747858]  [] snd_pcm_playback_ioctl+0x27/0x40 [snd_pcm]
[ 8109.747859]  [] do_vfs_ioctl+0xa3/0x5f0
[ 8109.747860]  [] ? __fget+0x77/0xb0
[ 8109.747861]  [] SyS_ioctl+0x79/0x90
[ 8109.747862]  [] entry_SYSCALL_64_fastpath+0x1a/0xa9
[bart@BartPCArch ~]$ pulseaudio -
I: [pulseaudio] main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not 
permitted
I: [pulseaudio] main.c: setrlimit(RLIMIT_RTPRIO, (9, 9)) failed: Operation not 
permitted
D: [pulseaudio] core-rtclock.c: Timer slack is set to 50 us.
D: [pulseaudio] core-util.c: RealtimeKit worked.
I: [pulseaudio] core-util.c: Successfully gained nice level -11.
I: [pulseaudio] main.c: This is PulseAudio 6.0
D: [pulseaudio] main.c: Compilation host: x86_64-unknown-linux-gnu
D: [pulseaudio] main.c: Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 
-pipe -fstack-protector-strong --param=ssp-buffer-size=4 -Wall -W -Wextra 
-Wno-long-long -Wno-overlength-strings -Wunsafe-loop-optimizations -Wundef 
-Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security -Wmissing-include-dirs 
-Wformat-nonliteral -Wpointer-arith -Winit-self -Wdeclaration-after-statement 
-Wfloat-equal -Wmissing-prototypes -Wredundant-decls -Wmissing-declarations 
-Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align -Wstrict-aliasing 
-Wwrite-strings -Wno-unused-parameter -ffast-math -fno-common 
-fdiagnostics-show-option -fdiagnostics-color=auto
D: [pulseaudio] main.c: Running on host: Linux x86_64 4.1.6-1-ARCH #1 SMP 
PREEMPT Mon Aug 17 08:52:28 CEST 2015
D: [pulseaudio] main.c: Found 8 CPUs.
I: [pulseaudio] main.c: Page size is 4096 bytes
D: [pulseaudio] main.c: Compiled with Valgrind support: no
D: [pulseaudio] main.c: Running in 

Re: dwc3 gadget breaks on system suspend/resume

[Roger Quadros]

On 30/01/17 14:59, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
>>> (hmm, I didn't receive your reply in my intel inbox, only
>>> gmail. Odd. Replying to myself here, but it should be on your reply,
>>> rater).
>>>
>>> Felipe Balbi  writes:
> The previous commit c499ff71ff2a281366c6ec7a904c547d806cbcd1 is fine.

 okay. Then let's try to figure out what's going on. A diff of regdump
 before and after suspend/resume might start to give some clue about
 what's going on. DWC3 tracepoints should help too. Care to get those?
 BTW, is this dwc3 as host or peripheral?
>>>
>>> You don't have any endpoints enabled:
>>>
>>> -DALEPENA = 0x000f
>>> +DALEPENA = 0x
>>
>> Thanks for the hints.
>>
>> This problem is because reason dwc3_gadget_run_stop() is timing out
>> during the suspend sequence and so dwc3_disconnect_gadget() and
>> __dwc3_gadget_stop() are not being called.
> 
> I see
> 
>> dwc3_suspend() does not consider dwc3_gadget_suspend()'s return value
>> and happily continues suspending the machine.
>>
>> If I force dwc3_gadget_run_stop() to return 0 then everything works fine.
>>
>> Any ideas why DWC3_DSTS_DEVCTRLHLT is not getting set?
> 
> no idea. It should always get set when run_stop is cleared. Can you
> check if suspending with cable detached has any difference?
> 

After cable detach, it still timed out the next suspend. But on
subsequent suspends there were no timeouts. (I didn't plug the cable back at 
all)

This behaviour is on dra7. I will test the behaviour on am43x as well.

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: dwc3 gadget breaks on system suspend/resume

[Felipe Balbi]

Hi,

Roger Quadros  writes:
>> (hmm, I didn't receive your reply in my intel inbox, only
>> gmail. Odd. Replying to myself here, but it should be on your reply,
>> rater).
>> 
>> Felipe Balbi  writes:
 The previous commit c499ff71ff2a281366c6ec7a904c547d806cbcd1 is fine.
>>>
>>> okay. Then let's try to figure out what's going on. A diff of regdump
>>> before and after suspend/resume might start to give some clue about
>>> what's going on. DWC3 tracepoints should help too. Care to get those?
>>> BTW, is this dwc3 as host or peripheral?
>> 
>> You don't have any endpoints enabled:
>> 
>> -DALEPENA = 0x000f
>> +DALEPENA = 0x
>
> Thanks for the hints.
>
> This problem is because reason dwc3_gadget_run_stop() is timing out
> during the suspend sequence and so dwc3_disconnect_gadget() and
> __dwc3_gadget_stop() are not being called.

I see

> dwc3_suspend() does not consider dwc3_gadget_suspend()'s return value
> and happily continues suspending the machine.
>
> If I force dwc3_gadget_run_stop() to return 0 then everything works fine.
>
> Any ideas why DWC3_DSTS_DEVCTRLHLT is not getting set?

no idea. It should always get set when run_stop is cleared. Can you
check if suspending with cable detached has any difference?

-- 
balbi


signature.asc
Description: PGP signature

[PATCH v16 1/3] lib/string: add sysfs_match_string helper

[Heikki Krogerus]

Make a simple helper for matching strings with sysfs
attribute files. In most parts the same as match_string(),
except sysfs_match_string() uses sysfs_streq() instead of
strcmp() for matching. This is more convenient when used
with sysfs attributes.

Signed-off-by: Heikki Krogerus 
Reviewed-by: Mika Westerberg 
Reviewed-by: Felipe Balbi 
---
 include/linux/string.h | 10 ++
 lib/string.c   | 26 ++
 2 files changed, 36 insertions(+)

diff --git a/include/linux/string.h b/include/linux/string.h
index 26b6f6a66f83..c4011b28f3d8 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -135,6 +135,16 @@ static inline int strtobool(const char *s, bool *res)
 }
 
 int match_string(const char * const *array, size_t n, const char *string);
+int __sysfs_match_string(const char * const *array, size_t n, const char *s);
+
+/**
+ * sysfs_match_string - matches given string in an array
+ * @_a: array of strings
+ * @_s: string to match with
+ *
+ * Helper for __sysfs_match_string(). Calculates the size of @a automatically.
+ */
+#define sysfs_match_string(_a, _s) __sysfs_match_string(_a, ARRAY_SIZE(_a), _s)
 
 #ifdef CONFIG_BINARY_PRINTF
 int vbin_printf(u32 *bin_buf, size_t size, const char *fmt, va_list args);
diff --git a/lib/string.c b/lib/string.c
index ed83562a53ae..1a7d3fd52541 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -656,6 +656,32 @@ int match_string(const char * const *array, size_t n, 
const char *string)
 }
 EXPORT_SYMBOL(match_string);
 
+/**
+ * __sysfs_match_string - matches given string in an array
+ * @array: array of strings
+ * @n: number of strings in the array or -1 for NULL terminated arrays
+ * @str: string to match with
+ *
+ * Returns index of @str in the @array or -EINVAL, just like match_string().
+ * Uses sysfs_streq instead of strcmp for matching.
+ */
+int __sysfs_match_string(const char * const *array, size_t n, const char *str)
+{
+   const char *item;
+   int index;
+
+   for (index = 0; index < n; index++) {
+   item = array[index];
+   if (!item)
+   break;
+   if (sysfs_streq(item, str))
+   return index;
+   }
+
+   return -EINVAL;
+}
+EXPORT_SYMBOL(__sysfs_match_string);
+
 #ifndef __HAVE_ARCH_MEMSET
 /**
  * memset - Fill a region of memory with the given value
-- 
2.11.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

[PATCH v16 2/3] usb: USB Type-C connector class

[Heikki Krogerus]

The purpose of USB Type-C connector class is to provide
unified interface for the user space to get the status and
basic information about USB Type-C connectors on a system,
control over data role swapping, and when the port supports
USB Power Delivery, also control over power role swapping
and Alternate Modes.

Signed-off-by: Heikki Krogerus 
Reviewed-by: Mika Westerberg 
Reviewed-by: Felipe Balbi 
---
 Documentation/ABI/testing/sysfs-class-typec |  276 ++
 Documentation/usb/typec.rst |  185 
 MAINTAINERS |9 +
 drivers/usb/Kconfig |2 +
 drivers/usb/Makefile|2 +
 drivers/usb/typec/Kconfig   |7 +
 drivers/usb/typec/Makefile  |1 +
 drivers/usb/typec/typec.c   | 1264 +++
 include/linux/usb/typec.h   |  243 +
 9 files changed, 1989 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-typec
 create mode 100644 Documentation/usb/typec.rst
 create mode 100644 drivers/usb/typec/Kconfig
 create mode 100644 drivers/usb/typec/Makefile
 create mode 100644 drivers/usb/typec/typec.c
 create mode 100644 include/linux/usb/typec.h

diff --git a/Documentation/ABI/testing/sysfs-class-typec 
b/Documentation/ABI/testing/sysfs-class-typec
new file mode 100644
index ..a7ac417d2ed3
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -0,0 +1,276 @@
+USB Type-C port devices (eg. /sys/class/typec/port0/)
+
+What:  /sys/class/typec//data_role
+Date:  February 2017
+Contact:   Heikki Krogerus 
+Description:
+   The supported USB data roles. This attribute can be used for
+   requesting data role swapping on the port. Swapping is supported
+   as synchronous operation, so write(2) to the attribute will not
+   return until the operation has finished. The attribute is
+   notified about role changes so that poll(2) on the attribute
+   wakes up. Change on the role will also generate uevent
+   KOBJ_CHANGE on the port. The current role is show in brackets,
+   for example "[host] device" when DRP port is in host mode.
+
+   Valid values: host, device
+
+What:  /sys/class/typec//power_role
+Date:  February 2017
+Contact:   Heikki Krogerus 
+Description:
+   The supported power roles. This attribute can be used to request
+   power role swap on the port when the port supports USB Power
+   Delivery. Swapping is supported as synchronous operation, so
+   write(2) to the attribute will not return until the operation
+   has finished. The attribute is notified about role changes so
+   that poll(2) on the attribute wakes up. Change on the role will
+   also generate uevent KOBJ_CHANGE. The current role is show in
+   brackets, for example "[source] sink" when in source mode.
+
+   Valid values: source, sink
+
+What:  /sys/class/typec//vconn_source
+Date:  February 2017
+Contact:   Heikki Krogerus 
+Description:
+   Shows is the port VCONN Source. This attribute can be used to
+   request VCONN swap to change the VCONN Source during connection
+   when both the port and the partner support USB Power Delivery.
+   Swapping is supported as synchronous operation, so write(2) to
+   the attribute will not return until the operation has finished.
+   The attribute is notified about VCONN source changes so that
+   poll(2) on the attribute wakes up. Change on VCONN source also
+   generates uevent KOBJ_CHANGE.
+
+   Valid values:
+   - "no" when the port is not the VCONN Source
+   - "yes" when the port is the VCONN Source
+
+What:  /sys/class/typec//power_operation_mode
+Date:  February 2017
+Contact:   Heikki Krogerus 
+Description:
+   Shows the current power operational mode the port is in. The
+   power operation mode means current level for VBUS. In case USB
+   Power Delivery communication is used for negotiating the levels,
+   power operation mode should show "usb_power_delivery".
+
+   Valid values:
+   - default
+   - 1.5A
+   - 3.0A
+   - usb_power_delivery
+
+What:  /sys/class/typec//preferred_role
+Date:  February 2017
+Contact:   Heikki Krogerus 
+Description:
+   

[PATCH v16 0/3] USB Type-C Connector class

[Heikki Krogerus]

The USB Type-C class is meant to provide unified interface to the
userspace to present the USB Type-C ports in a system.

Changes since v15:
- "stingification" as proposed by Felipe
- Checking ARRAY_SIZE in supported_accessory_modes() as proposed by Guenter

Changes since v14:
- Fixes proposed by Mika
- "identity" directory for all discover identity VDOs instead of "vdo" attribute
- alternate mode device names to just "svid-"

Changes since v13:
- New API. Everything is registered separately.

Changes since v12:
- Added prefer_role member to typec_capability structure as requested by Guenter

Changes since v11:
- The port drivers are responsible of removing the alternate
  modes (just like the documentation already said).

Changes since v10:
- Using ATTRIBUTE_GROUPS and DEVICE_ATTR marcos everywhere
- Moved sysfs_match_string to lib/string.c
- Rationalized uevents
- Calling ida_destroy

Changes since v9:
- Minor typec_wcove.c cleanup as proposed by Guenter Roeck. No
  function affect.

Changes since v8:
- checking sysfs_streq() result correctly in sysfs_strmatch
- fixed accessory check in supported_accessory_mode
- using "none" as the only string that can clear the preferred role

Changes since v7:
- Removed "type" attribute from partners
- Added supports_usb_power_delivery attribute for partner and cable

Changes since v6:
- current_vconn_role attr renamed to vconn_source (no API changes)
- Small documentation improvements proposed by Vincent Palatin

Changes since v5:
- Only updating the roles based on driver notifications
- Added MODULE_ALIAS for the WhiskeyCove module
- Including the patch that creates the actual platform device for the
  WhiskeyCove Type-C PHY in this series.

Changes since v4:
- Remove the port lock completely

Changes since v3:
- Documentation cleanup as proposed by Roger Quadros
- Setting partner altmodes member to NULL on removal and fixing a
  warning, as proposed by Guenter Roeck
- Added the following attributes for partners and cables:
  * supports_usb_power_delivery
  * id_header_vdo
- "id_header_vdo" is visible only when the partner or cable supports
  USB Power Delivery communication.
- Partner attribute "accessory" is hidden when the partner type is not
  "Accessory".

Changes since v2:
- Notification on role and alternate mode changes
- cleanups

Changes since v1:
- Completely rewrote alternate mode support
- Patners, cables and cable plugs presented as devices.


Heikki Krogerus (3):
  lib/string: add sysfs_match_string helper
  usb: USB Type-C connector class
  usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY

 Documentation/ABI/testing/sysfs-class-typec |  276 ++
 Documentation/usb/typec.rst |  185 
 MAINTAINERS |9 +
 drivers/usb/Kconfig |2 +
 drivers/usb/Makefile|2 +
 drivers/usb/typec/Kconfig   |   21 +
 drivers/usb/typec/Makefile  |2 +
 drivers/usb/typec/typec.c   | 1264 +++
 drivers/usb/typec/typec_wcove.c |  377 
 include/linux/string.h  |   10 +
 include/linux/usb/typec.h   |  243 +
 lib/string.c|   26 +
 12 files changed, 2417 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-typec
 create mode 100644 Documentation/usb/typec.rst
 create mode 100644 drivers/usb/typec/Kconfig
 create mode 100644 drivers/usb/typec/Makefile
 create mode 100644 drivers/usb/typec/typec.c
 create mode 100644 drivers/usb/typec/typec_wcove.c
 create mode 100644 include/linux/usb/typec.h

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

[PATCH v16 3/3] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY

[Heikki Krogerus]

This adds driver for the USB Type-C PHY on Intel WhiskeyCove
PMIC which is available on some of the Intel Broxton SoC
based platforms.

Signed-off-by: Heikki Krogerus 
Reviewed-by: Mika Westerberg 
Reviewed-by: Felipe Balbi 
---
 drivers/usb/typec/Kconfig   |  14 ++
 drivers/usb/typec/Makefile  |   1 +
 drivers/usb/typec/typec_wcove.c | 377 
 3 files changed, 392 insertions(+)
 create mode 100644 drivers/usb/typec/typec_wcove.c

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index 17792f9114c6..2abbcb021d1b 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -4,4 +4,18 @@ menu "USB Power Delivery and Type-C drivers"
 config TYPEC
tristate
 
+config TYPEC_WCOVE
+   tristate "Intel WhiskeyCove PMIC USB Type-C PHY driver"
+   depends on ACPI
+   depends on INTEL_SOC_PMIC
+   depends on INTEL_PMC_IPC
+   select TYPEC
+   help
+ This driver adds support for USB Type-C detection on Intel Broxton
+ platforms that have Intel Whiskey Cove PMIC. The driver can detect the
+ role and cable orientation.
+
+ To compile this driver as module, choose M here: the module will be
+ called typec_wcove
+
 endmenu
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index 1012a8bed6d5..b9cb862221af 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_TYPEC)+= typec.o
+obj-$(CONFIG_TYPEC_WCOVE)  += typec_wcove.o
diff --git a/drivers/usb/typec/typec_wcove.c b/drivers/usb/typec/typec_wcove.c
new file mode 100644
index ..d5a7b21fa3f1
--- /dev/null
+++ b/drivers/usb/typec/typec_wcove.c
@@ -0,0 +1,377 @@
+/**
+ * typec_wcove.c - WhiskeyCove PMIC USB Type-C PHY driver
+ *
+ * Copyright (C) 2017 Intel Corporation
+ * Author: Heikki Krogerus 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register offsets */
+#define WCOVE_CHGRIRQ0 0x4e09
+#define WCOVE_PHYCTRL  0x5e07
+
+#define USBC_CONTROL1  0x7001
+#define USBC_CONTROL2  0x7002
+#define USBC_CONTROL3  0x7003
+#define USBC_CC1_CTRL  0x7004
+#define USBC_CC2_CTRL  0x7005
+#define USBC_STATUS1   0x7007
+#define USBC_STATUS2   0x7008
+#define USBC_STATUS3   0x7009
+#define USBC_IRQ1  0x7015
+#define USBC_IRQ2  0x7016
+#define USBC_IRQMASK1  0x7017
+#define USBC_IRQMASK2  0x7018
+
+/* Register bits */
+
+#define USBC_CONTROL1_MODE_DRP(r)  (((r) & ~0x7) | 4)
+
+#define USBC_CONTROL2_UNATT_SNKBIT(0)
+#define USBC_CONTROL2_UNATT_SRCBIT(1)
+#define USBC_CONTROL2_DIS_ST   BIT(2)
+
+#define USBC_CONTROL3_PD_DIS   BIT(1)
+
+#define USBC_CC_CTRL_VCONN_EN  BIT(1)
+
+#define USBC_STATUS1_DET_ONGOING   BIT(6)
+#define USBC_STATUS1_RSLT(r)   ((r) & 0xf)
+#define USBC_RSLT_NOTHING  0
+#define USBC_RSLT_SRC_DEFAULT  1
+#define USBC_RSLT_SRC_1_5A 2
+#define USBC_RSLT_SRC_3_0A 3
+#define USBC_RSLT_SNK  4
+#define USBC_RSLT_DEBUG_ACC5
+#define USBC_RSLT_AUDIO_ACC6
+#define USBC_RSLT_UNDEF15
+#define USBC_STATUS1_ORIENT(r) (((r) >> 4) & 0x3)
+#define USBC_ORIENT_NORMAL 1
+#define USBC_ORIENT_REVERSE2
+
+#define USBC_STATUS2_VBUS_REQ  BIT(5)
+
+#define USBC_IRQ1_ADCDONE1 BIT(2)
+#define USBC_IRQ1_OVERTEMP BIT(1)
+#define USBC_IRQ1_SHORTBIT(0)
+
+#define USBC_IRQ2_CC_CHANGEBIT(7)
+#define USBC_IRQ2_RX_PDBIT(6)
+#define USBC_IRQ2_RX_HRBIT(5)
+#define USBC_IRQ2_RX_CRBIT(4)
+#define USBC_IRQ2_TX_SUCCESS   BIT(3)
+#define USBC_IRQ2_TX_FAIL  BIT(2)
+
+#define USBC_IRQMASK1_ALL  (USBC_IRQ1_ADCDONE1 | USBC_IRQ1_OVERTEMP | \
+USBC_IRQ1_SHORT)
+
+#define USBC_IRQMASK2_ALL  (USBC_IRQ2_CC_CHANGE | USBC_IRQ2_RX_PD | \
+USBC_IRQ2_RX_HR | USBC_IRQ2_RX_CR | \
+USBC_IRQ2_TX_SUCCESS | USBC_IRQ2_TX_FAIL)
+
+struct wcove_typec {
+   struct mutex lock; /* device lock */
+   struct device *dev;
+   struct regmap *regmap;
+   struct typec_port *port;
+   struct typec_capability cap;
+   struct typec_partner *partner;
+};
+
+enum wcove_typec_func {
+   WCOVE_FUNC_DRIVE_VBUS = 1,
+   WCOVE_FUNC_ORIENTATION,
+   

Re: dwc3 gadget breaks on system suspend/resume

[Roger Quadros]

Hi,

On 27/01/17 17:47, Felipe Balbi wrote:
> 
> Hi,
> 
> (hmm, I didn't receive your reply in my intel inbox, only
> gmail. Odd. Replying to myself here, but it should be on your reply,
> rater).
> 
> Felipe Balbi  writes:
>>> The previous commit c499ff71ff2a281366c6ec7a904c547d806cbcd1 is fine.
>>
>> okay. Then let's try to figure out what's going on. A diff of regdump
>> before and after suspend/resume might start to give some clue about
>> what's going on. DWC3 tracepoints should help too. Care to get those?
>> BTW, is this dwc3 as host or peripheral?
> 
> You don't have any endpoints enabled:
> 
> -DALEPENA = 0x000f
> +DALEPENA = 0x

Thanks for the hints.

This problem is because reason dwc3_gadget_run_stop() is timing out
during the suspend sequence and so dwc3_disconnect_gadget() and
__dwc3_gadget_stop() are not being called.

dwc3_suspend() does not consider dwc3_gadget_suspend()'s return value
and happily continues suspending the machine.

If I force dwc3_gadget_run_stop() to return 0 then everything works fine.

Any ideas why DWC3_DSTS_DEVCTRLHLT is not getting set?
I checked that DWC3_GEVNTCOUNT(0) is zero.

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: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[gre...@linuxfoundation.org]

On Mon, Jan 30, 2017 at 08:25:25AM +, Ajay Kaher wrote:
>  

First off, you are sending html email, which the mailing list keeps
rejecting, why are you ignoring that?



> 
> There is race condition when two USB class drivers try to call
> 
> init_usb_class at the same time and leads to crash.
> 
>  
> 
> The main reason for this is one of the Class drivers allocates memory
> for usb_class structure and initializes its member. In the meantime NULL
> check for usb_class structure fails and assumes that usb_class structure
> is properly initialized and crashed while trying to access its members.
> 
>  
> 
> To avoid this race condition locking required before calling
> init_usb_class from function usb_register_dev.
> 
>  
> 
>  
> 
> Signed-off-by: Ajay Kaher

Does this look correct?  Please work with some of the samsung kernel
developers for how to properly submit a patch.

And finally, how are two drivers calling init_usb_class() at the same
time?  What code path causes that?  Have you seen this happen, and if
so, what drivers caused it?

thanks,

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

[PATCH 1/6] UDC: Split the driver into amd (pci) and Synopsys core IP driver

[Raviteja Garimella]

This patch splits the amd5536udc driver into two -- one that does
pci device registration and the other file that does the rest of
the driver tasks like the gadget/ep ops etc for Synopsys UDC.

This way of splitting helps in exporting core driver symbols which
can be used by any other platform/pci driver that is written for
the same Synopsys USB device controller.

The current patch also includes a change in the Kconfig and Makefile.
A new config option USB_SNP_CORE will be selected automatically when
any one of the platform or pci driver for the same UDC is selected.

Main changes:
- amd5536udc_pci.c: PCI device registration is moved to this file.

- amd5536udc.c:
  This file does rest of the core UDC fucntionality.
  9 symbols are exported so as to be used by amd5536udc_pci.c.
  Module parameter definitions are moved to header file.

- amd5536udc.h:
  Function declarations, module parameters definitions and few common
  header file includes are added to this file

- Kconfig:
  New USB_SNP_CORE option is added which will be auto selected when
  any pci or platform driver config option for the UDC is chosen.

- Makefile:
  Compiles the core and pci files separately.

Signed-off-by: Raviteja Garimella 
---
 drivers/usb/gadget/udc/Kconfig  |  18 +++
 drivers/usb/gadget/udc/Makefile |   3 +-
 drivers/usb/gadget/udc/amd5536udc.c | 238 
 drivers/usb/gadget/udc/amd5536udc.h |  36 +
 drivers/usb/gadget/udc/amd5536udc_pci.c | 217 +
 5 files changed, 297 insertions(+), 215 deletions(-)
 create mode 100644 drivers/usb/gadget/udc/amd5536udc_pci.c

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 658b8da..9178dd2 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -239,6 +239,20 @@ config USB_MV_U3D
  MARVELL PXA2128 Processor series include a super speed USB3.0 device
  controller, which support super speed USB peripheral.
 
+config USB_SNP_CORE
+   depends on PCI
+   tristate
+   help
+ This enables core driver support for Synopsys USB 2.0 Device
+ controller.
+
+ This will be enabled when PCI or Platform driver for this UDC is
+ selected. Currently, this will be enabled by USB_SNP_UDC_PLAT or
+ USB_AMD5536UDC options.
+
+ This IP is different to the High Speed OTG IP that can be enabled
+ by selecting USB_DWC2 or USB_DWC3 options.
+
 #
 # Controllers available in both integrated and discrete versions
 #
@@ -263,6 +277,7 @@ source "drivers/usb/gadget/udc/bdc/Kconfig"
 
 config USB_AMD5536UDC
tristate "AMD5536 UDC"
+   select USB_SNP_CORE
depends on PCI
help
   The AMD5536 UDC is part of the AMD Geode CS5536, an x86 southbridge.
@@ -271,6 +286,9 @@ config USB_AMD5536UDC
   The UDC port supports OTG operation, and may be used as a host port
   if it's not being used to implement peripheral or OTG roles.
 
+  This UDC is based on Synopsys USB device controller IP and selects
+  CONFIG_USB_SNP_CORE option to build the core driver.
+
   Say "y" to link the driver statically, or "m" to build a
   dynamically linked module called "amd5536udc" and force all
   gadget drivers to also be dynamically linked.
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index 98e74ed..626e1f1 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -10,7 +10,8 @@ obj-$(CONFIG_USB_GADGET)  += udc-core.o
 obj-$(CONFIG_USB_DUMMY_HCD)+= dummy_hcd.o
 obj-$(CONFIG_USB_NET2272)  += net2272.o
 obj-$(CONFIG_USB_NET2280)  += net2280.o
-obj-$(CONFIG_USB_AMD5536UDC)   += amd5536udc.o
+obj-$(CONFIG_USB_SNP_CORE) += amd5536udc.o
+obj-$(CONFIG_USB_AMD5536UDC)   += amd5536udc_pci.o
 obj-$(CONFIG_USB_PXA25X)   += pxa25x_udc.o
 obj-$(CONFIG_USB_PXA27X)   += pxa27x_udc.o
 obj-$(CONFIG_USB_GOKU) += goku_udc.o
diff --git a/drivers/usb/gadget/udc/amd5536udc.c 
b/drivers/usb/gadget/udc/amd5536udc.c
index ea03ca7..72f3c8f 100644
--- a/drivers/usb/gadget/udc/amd5536udc.c
+++ b/drivers/usb/gadget/udc/amd5536udc.c
@@ -11,27 +11,15 @@
  */
 
 /*
- * The AMD5536 UDC is part of the x86 southbridge AMD Geode CS5536.
- * It is a USB Highspeed DMA capable USB device controller. Beside ep0 it
- * provides 4 IN and 4 OUT endpoints (bulk or interrupt type).
- *
- * Make sure that UDC is assigned to port 4 by BIOS settings (port can also
- * be used as host port) and UOC bits PAD_EN and APU are set (should be done
- * by BIOS init).
- *
- * UDC DMA requires 32-bit aligned buffers so DMA with gadget ether does not
- * work without updating NET_IP_ALIGN. Or PIO mode (module param "use_dma=0")
- * can be used with gadget ether.
+ * This file does the core driver implementation for the UDC that is based
+ * on Synopsys device 

[PATCH 3/6] UDC: make debug prints compatible with both pci and platform devices

[Raviteja Garimella]

This patch adds a struct device member to UDC data structure and
makes changes to the arguments of dev_err and dev_dbg calls so that
the debug prints work for both pci and platform devices.

Signed-off-by: Raviteja Garimella 
---
 drivers/usb/gadget/udc/amd5536udc.h |  4 +++-
 drivers/usb/gadget/udc/amd5536udc_pci.c |  1 +
 drivers/usb/gadget/udc/snps_udc_core.c  | 28 ++--
 3 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/udc/amd5536udc.h 
b/drivers/usb/gadget/udc/amd5536udc.h
index bd2a18e..c252457 100644
--- a/drivers/usb/gadget/udc/amd5536udc.h
+++ b/drivers/usb/gadget/udc/amd5536udc.h
@@ -563,6 +563,8 @@ struct udc {
u16 cur_config;
u16 cur_intf;
u16 cur_alt;
+
+   struct device   *dev;
 };
 
 #define to_amd5536_udc(g)  (container_of((g), struct udc, gadget))
@@ -639,7 +641,7 @@ MODULE_PARM_DESC(use_fullspeed, "true for fullspeed only");
 
 /* debug macros */
 
-#define DBG(udc , args...) dev_dbg(&(udc)->pdev->dev, args)
+#define DBG(udc , args...) dev_dbg(udc->dev, args)
 
 #ifdef UDC_VERBOSE
 #define VDBG   DBG
diff --git a/drivers/usb/gadget/udc/amd5536udc_pci.c 
b/drivers/usb/gadget/udc/amd5536udc_pci.c
index 2a2d0a9..57a13f0 100644
--- a/drivers/usb/gadget/udc/amd5536udc_pci.c
+++ b/drivers/usb/gadget/udc/amd5536udc_pci.c
@@ -168,6 +168,7 @@ static int udc_pci_probe(
dev->phys_addr = resource;
dev->irq = pdev->irq;
dev->pdev = pdev;
+   dev->dev = >dev;
 
/* general probing */
if (udc_probe(dev)) {
diff --git a/drivers/usb/gadget/udc/snps_udc_core.c 
b/drivers/usb/gadget/udc/snps_udc_core.c
index 72f3c8f..c778d51 100644
--- a/drivers/usb/gadget/udc/snps_udc_core.c
+++ b/drivers/usb/gadget/udc/snps_udc_core.c
@@ -209,18 +209,18 @@ static void print_regs(struct udc *dev)
if (use_dma && use_dma_ppb && !use_dma_ppb_du) {
DBG(dev, "DMA mode   = PPBNDU (packet per buffer "
"WITHOUT desc. update)\n");
-   dev_info(>pdev->dev, "DMA mode (%s)\n", "PPBNDU");
+   dev_info(dev->dev, "DMA mode (%s)\n", "PPBNDU");
} else if (use_dma && use_dma_ppb && use_dma_ppb_du) {
DBG(dev, "DMA mode   = PPBDU (packet per buffer "
"WITH desc. update)\n");
-   dev_info(>pdev->dev, "DMA mode (%s)\n", "PPBDU");
+   dev_info(dev->dev, "DMA mode (%s)\n", "PPBDU");
}
if (use_dma && use_dma_bufferfill_mode) {
DBG(dev, "DMA mode   = BF (buffer fill mode)\n");
-   dev_info(>pdev->dev, "DMA mode (%s)\n", "BF");
+   dev_info(dev->dev, "DMA mode (%s)\n", "BF");
}
if (!use_dma)
-   dev_info(>pdev->dev, "FIFO mode\n");
+   dev_info(dev->dev, "FIFO mode\n");
DBG(dev, "---\n");
 }
 
@@ -1628,7 +1628,7 @@ static void udc_setup_endpoints(struct udc *dev)
 static void usb_connect(struct udc *dev)
 {
 
-   dev_info(>pdev->dev, "USB Connect\n");
+   dev_info(dev->dev, "USB Connect\n");
 
dev->connected = 1;
 
@@ -1646,7 +1646,7 @@ static void usb_connect(struct udc *dev)
 static void usb_disconnect(struct udc *dev)
 {
 
-   dev_info(>pdev->dev, "USB Disconnect\n");
+   dev_info(dev->dev, "USB Disconnect\n");
 
dev->connected = 0;
 
@@ -2110,7 +2110,7 @@ static irqreturn_t udc_data_out_isr(struct udc *dev, int 
ep_ix)
}
/* HE event ? */
if (tmp & AMD_BIT(UDC_EPSTS_HE)) {
-   dev_err(>pdev->dev, "HE ep%dout occurred\n", ep->num);
+   dev_err(dev->dev, "HE ep%dout occurred\n", ep->num);
 
/* clear HE */
writel(tmp | AMD_BIT(UDC_EPSTS_HE), >regs->sts);
@@ -2309,7 +2309,7 @@ static irqreturn_t udc_data_in_isr(struct udc *dev, int 
ep_ix)
if (use_dma) {
/* BNA ? */
if (epsts & AMD_BIT(UDC_EPSTS_BNA)) {
-   dev_err(>pdev->dev,
+   dev_err(dev->dev,
"BNA ep%din occurred - DESPTR = %08lx\n",
ep->num,
(unsigned long) readl(>regs->desptr));
@@ -2322,7 +2322,7 @@ static irqreturn_t udc_data_in_isr(struct udc *dev, int 
ep_ix)
}
/* HE event ? */
if (epsts & AMD_BIT(UDC_EPSTS_HE)) {
-   dev_err(>pdev->dev,
+   dev_err(dev->dev,
"HE ep%dn occurred - DESPTR = %08lx\n",
ep->num, (unsigned long) readl(>regs->desptr));
 
@@ -2960,7 +2960,7 @@ __acquires(dev->lock)
 
/* link up all endpoints */

[PATCH 0/6] Platform driver support for 'amd5536udc' driver

[Raviteja Garimella]

The changes are being submitted as PATCH this time. Below are the
details of main changes with respect to previous RFC versions.

Changes from RFC v2:
===
Patch 1/6 now splits the driver into amd5536udc_pci_.c (which
contains only the PCI device registration part), and amd5536udc.c
will still be driver that does the rest of UDC driver functionality.

Patch 2/6 renames amd5536udc.c to snps_udc_core.c.

The DT compatibilty string is changed to "brcm,iproc-snps-udc"
as per review comments for RFCv2. The driver and bindings
documentation is modified to reflect this.



This is RFC for the changes made as per the review comments made for
the previous version. I would like to know  if this approach (the way
the driver is split and the naming and all)looks good to be submitted.


Changes from RFC v1:
===
1. Split the driver into platform/pci specific drivers with a core driver
   file that handles the common driver routines that are exported.

2. Split the driver into number of patches as suggested in previous
   review comments.

3. Added the devicetree bindings documentation for Synopsys platform
   driver.

Introduction from previous version:
===
This patch adds platform device support to the existing 'amd5536udc'
driver.

The UDC is based on Synopsys Designware core USB (2.0) Device controller
IP.

The driver so far supports UDCs that are a part of AMD southbridge
and is connected through PCI bus.

The same driver can be used with UDCs that are integrated into SoCs
like Broadcom's Northstar2/Cygnus platforms by adding platform device
suooprt.

This patch contains all the changes that were required to get the driver
functional on Broadcom's Northstar2 platform. 

This is a request for comments from maintainers/others regarding approach
on whether to have 2 different drivers (one each for AMD and Broadcom)
with a common library (3 files in total), or have a single driver like
it's done in this patch and have the driver filename changed to some
common name based on ther underlying IP, like snps_udc.c.

Below are the main changes done:

1. Added OF based platform device registration -- so that the driver gets
   probed based on the device tree entry. Like wise, remove routine and
   platform PM ops are supported.

2. Modified debug prints to be compatible with both pci and platform
   devices.

3. Added members to 'struct udc' in header file for extcon and phy support.
   This is required if the UDC is connected to a Dual Role Device Phy
   where the Phy can be configured to be in Device mode or Host mode based
   on the type of external cable that is connected to the port.
 
4. Added checks in udc connect/disconnect routines so as to return if the
   routine is already called.

5. Modified the arguments passed to dma_pool_create routine -- which
   expects struct device, whereas NULL is passed in the existing version.
 
6. Kconfig changes are done so that the driver now depends on either of
   CONFIG_OF or CONFIG_PCI. More description about the Synopsys IP is
   provided.

Repo: https://github.com/Broadcom/arm64-linux.git
Branch: snps_udc

Raviteja Garimella (6):
  UDC: Split the driver into amd (pci) and Synopsys core IP driver
  UDC: Rename amd5536udc driver file based on IP
  UDC: make debug prints compatible with both pci and platform devices
  UDC: Provide correct arguments for 'dma_pool_create'
  DT bindings documentation for Broadcom IPROC USB Device controller.
  UDC: Add Synopsys UDC Platform driver

 .../bindings/usb/brcm,iproc-snps-udc.txt   |   24 +
 drivers/usb/gadget/udc/Kconfig |   32 +
 drivers/usb/gadget/udc/Makefile|4 +-
 drivers/usb/gadget/udc/amd5536udc.c| 3413 
 drivers/usb/gadget/udc/amd5536udc.h|   54 +-
 drivers/usb/gadget/udc/amd5536udc_pci.c|  218 ++
 drivers/usb/gadget/udc/snps_udc_core.c | 3239 +++
 drivers/usb/gadget/udc/snps_udc_plat.c |  342 ++
 8 files changed, 3911 insertions(+), 3415 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/usb/brcm,iproc-snps-udc.txt
 delete mode 100644 drivers/usb/gadget/udc/amd5536udc.c
 create mode 100644 drivers/usb/gadget/udc/amd5536udc_pci.c
 create mode 100644 drivers/usb/gadget/udc/snps_udc_core.c
 create mode 100644 drivers/usb/gadget/udc/snps_udc_plat.c

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

[PATCH 4/6] UDC: Provide correct arguments for 'dma_pool_create'

[Raviteja Garimella]

Change the argument from NULL to a struct device for the
dma_pool_create call during dma init.

Signed-off-by: Raviteja Garimella 
---
 drivers/usb/gadget/udc/snps_udc_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/snps_udc_core.c 
b/drivers/usb/gadget/udc/snps_udc_core.c
index c778d51..5f95a65 100644
--- a/drivers/usb/gadget/udc/snps_udc_core.c
+++ b/drivers/usb/gadget/udc/snps_udc_core.c
@@ -3101,7 +3101,7 @@ int init_dma_pools(struct udc *dev)
}
 
/* DMA setup */
-   dev->data_requests = dma_pool_create("data_requests", NULL,
+   dev->data_requests = dma_pool_create("data_requests", dev->dev,
sizeof(struct udc_data_dma), 0, 0);
if (!dev->data_requests) {
DBG(dev, "can't get request data pool\n");
@@ -3112,7 +3112,7 @@ int init_dma_pools(struct udc *dev)
dev->ep[UDC_EP0IN_IX].dma = >regs->ctl;
 
/* dma desc for setup data */
-   dev->stp_requests = dma_pool_create("setup requests", NULL,
+   dev->stp_requests = dma_pool_create("setup requests", dev->dev,
sizeof(struct udc_stp_dma), 0, 0);
if (!dev->stp_requests) {
DBG(dev, "can't get stp request pool\n");
-- 
2.1.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