Re: [PATCH v2 01/10] usb: dwc2/gadget: report disconnect event from 'end session' irq

[Marek Szyprowski]

Hello,

On 2014-10-25 03:23, Paul Zimmerman wrote:

From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Monday, October 20, 2014 3:46 AM

This patch adds a call to s3c_hsotg_disconnect() from 'end session'
interrupt (GOTGINT_SES_END_DET) to correctly notify gadget subsystem
about unplugged usb cable. 'disconnected' interrupt (DISCONNINT) might
look a bit more suitable for this event, but it is asserted only in
host mode, so in device mode we need to use something else.

Signed-off-by: Marek Szyprowski 
---
  drivers/usb/dwc2/gadget.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 7b5856fadd93..119c8a3effc2 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2279,6 +2279,12 @@ irq_retry:
dev_info(hsotg->dev, "OTGInt: %08x\n", otgint);

writel(otgint, hsotg->regs + GOTGINT);
+
+   if (otgint & GOTGINT_SES_END_DET) {
+   if (hsotg->gadget.speed != USB_SPEED_UNKNOWN)
+   s3c_hsotg_disconnect(hsotg);
+   hsotg->gadget.speed = USB_SPEED_UNKNOWN;
+   }
}

if (gintsts & GINTSTS_SESSREQINT) {

Does this mean we can get rid of the call to s3c_hsotg_disconnect in
s3c_hsotg_process_control after a SET_ADDRESS is received? If not,
then s3c_hsotg_disconnect will be called twice, once here after the
disconnect, and once again after the reconnect and SET_ADDRESS.


Nope, we cannot get rid of that call, because it is needed got get gadget
operational when device has been re-enumerated. The simplest way to 
reproduce

such case is to connect dwc2 to externally powered hub and then unplug cable
between hub and usb host. In such case the 'end session' interrupt is not
asserted, so the additional s3c_hsotg_disconnect() call before setting new
address is needed. I will rework this patch and add a code to ensures that
the gadget->disconnect() will be called only once.

Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

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

Re: usb media detection issue on USB_MUSB_HDRC on kernel 3.17

[Enric Balletbo Serra]

Hi Rusian,

2014-10-29 14:31 GMT+01:00 Ruslan Bilovol :
> Hi Enric
>
> On Wed, Oct 29, 2014 at 1:44 PM, Enric Balletbo Serra
>  wrote:
>>
>> Hi all,
>>
>> 2014-10-26 10:10 GMT+01:00 Angelo Dureghello :
>> > Had some progresses:
>> >
>> > on kernel 3.17, musb controller driver is set to start as OTG mode as
>> > default. So as first thing, since my board has ID pin shorted to ground, i
>> > changed the default mode to MUSB_HOST., as it was on kernel 3.5.1
>> >
>> > So with same settings of 3.5.1 now key is detected correctly at first
>> > insertion, but after a removal, the stick is not detected anymore.
>> >
>> > Issue seems visible in drivers/usb/musb/da8xx.c, inside irqreturn_t
>> > da8xx_musb_interrupt() routine.
>> >
>> > looking the /sys fs, i see that the mode moves in time order as:
>> >
>> > |boot:   vbus off  b_idle||
>> > boot:   vbus off  a_wait_vrise||
>> > insertion:  vbus off  a_host|
>> > removal:vbus off  b_idle
>> >
>> > After last b_host, the state never moves back to a_wait_vrise.
>> >
>> > After the removal, the interrupt call irqreturn_t da8xx_musb_interrupt()
>> > seems broken and seems never called anymore.
>> >
>> > Regards.
>> >
>>
>> I'll add more information to this thread.
>>
>> Seems MUSB is also broken on OMAP3 boards, booting in OTG mode I'm not
>> able to make it work when a pendrive is connected to the port. Forcing
>> HOST mode I get following messages:
>>
>> [   13.244567] usb 2-1: new high-speed USB device number 2 using musb-hdrc
>> [   13.503234] usb 2-1: device v058f p6387 is not supported
>> [   13.592346] usb usb2-port1: unable to enumerate USB device
>>
> You need to disable CONFIG_USB_OTG_WHITELIST option to avoid this.
> Or add your device to white list of supported devices.
>

Thanks, right, with this option disabled I can enumerate the device.
OTOH the big problem is OTG doesn't switch between peripheric mode and
host mode. The use case is as follows:

1. Start the board with OTG mode, nothing connected to the port.
2. Plug a pendrive with an adaptor that sets the ID pin to low.

In that case the no device is detected.

Best regards,
   Enric

> Best regards,
> Ruslan
>
>> OTOH the OTG port as gadget works.
>>
>> Regards,
>>Enric
>> --
>> 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
>
>
>
>
> --
> Best regards,
> Ruslan Bilvol
--
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: dwc2/gadget: report disconnect event from 'end session' irq

[Marek Szyprowski]

This patch adds a call to s3c_hsotg_disconnect() from 'end session'
interrupt (GOTGINT_SES_END_DET) to correctly notify gadget subsystem
about unplugged usb cable. 'disconnected' interrupt (DISCONNINT) might
look a bit more suitable for this event, but it is asserted only in
host mode, so in device mode we need to use something else.

Additional check has been added in s3c_hsotg_disconnect() function
to ensure that the event is reported only once after successful device
enumeration.

Signed-off-by: Marek Szyprowski 
---
 drivers/usb/dwc2/core.h   |  1 +
 drivers/usb/dwc2/gadget.c | 10 ++
 2 files changed, 11 insertions(+)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 55c90c53f2d6..b42df32e7737 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -212,6 +212,7 @@ struct s3c_hsotg {
struct usb_gadget   gadget;
unsigned intsetup;
unsigned long   last_rst;
+   unsigned intaddress;
struct s3c_hsotg_ep *eps;
 };
 
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index fcd2bb55ccca..6304efba11aa 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1114,6 +1114,7 @@ static void s3c_hsotg_process_control(struct s3c_hsotg 
*hsotg,
 DCFG_DEVADDR_SHIFT) & DCFG_DEVADDR_MASK;
writel(dcfg, hsotg->regs + DCFG);
 
+   hsotg->address = ctrl->wValue;
dev_info(hsotg->dev, "new address %d\n", ctrl->wValue);
 
ret = s3c_hsotg_send_reply(hsotg, ep0, NULL, 0);
@@ -2031,6 +2032,10 @@ static void s3c_hsotg_disconnect(struct s3c_hsotg *hsotg)
 {
unsigned ep;
 
+   if (!hsotg->address)
+   return;
+
+   hsotg->address = 0;
for (ep = 0; ep < hsotg->num_of_eps; ep++)
kill_all_requests(hsotg, &hsotg->eps[ep], -ESHUTDOWN, true);
 
@@ -2290,6 +2295,11 @@ irq_retry:
dev_info(hsotg->dev, "OTGInt: %08x\n", otgint);
 
writel(otgint, hsotg->regs + GOTGINT);
+
+   if (otgint & GOTGINT_SES_END_DET) {
+   s3c_hsotg_disconnect(hsotg);
+   hsotg->gadget.speed = USB_SPEED_UNKNOWN;
+   }
}
 
if (gintsts & GINTSTS_SESSREQINT) {
-- 
1.9.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: [PATCH RESEND V4 3/9] of: Update Tegra XUSB pad controller binding for USB

[Linus Walleij]

On Tue, Oct 28, 2014 at 11:27 PM, Andrew Bresticker
 wrote:

> Add new bindings used for USB support by the Tegra XUSB pad controller.
> This includes additional PHY types, USB-specific pinconfig properties, etc.
>
> Signed-off-by: Andrew Bresticker 
> Reviewed-by: Stephen Warren 
> ---
> Changes from v2:
>  - Added nvidia,otg-hs-curr-level-offset property.
>  - Dropped "-otg" from VBUS supplies.
>  - Added mbox-names property.
>  - Removed extra whitespace.
> Changes from v1:
>  - Updated to use common mailbox bindings.
>  - Made USB3 port-to-lane mappins a top-level binding rather than a pinconfig
>binding.
>  - Add #defines for the padctl lanes.

Acked-by: Linus Walleij 

I guess you will take this patch along with the rest through ARM SoC
or so?

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

[PATCH net-next v2 2/3] r8152: clear the flag of SCHEDULE_TASKLET in tasklet

[Hayes Wang]

Clear the flag of SCHEDULE_TASKLET in bottom_half() to avoid
re-schedule the tasklet again by workqueue.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ff54098..670279a 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1798,6 +1798,9 @@ static void bottom_half(unsigned long data)
if (!netif_carrier_ok(tp->netdev))
return;
 
+   if (test_bit(SCHEDULE_TASKLET, &tp->flags))
+   clear_bit(SCHEDULE_TASKLET, &tp->flags);
+
rx_bottom(tp);
tx_bottom(tp);
 }
-- 
1.9.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 net-next v2 0/3] Code adjustment

[Hayes Wang]

v2:
 Correct the spelling error for the comment of patch #3.

v1:
Adjust some codes to make them more reasonable.

Hayes Wang (3):
  r8152: remove the duplicate init for the list of rx_done
  r8152: clear the flag of SCHEDULE_TASKLET in tasklet
  r8152: check RTL8152_UNPLUG and netif_running before autoresume

 drivers/net/usb/r8152.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

-- 
1.9.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 net-next v2 3/3] r8152: check RTL8152_UNPLUG and netif_running before autoresume

[Hayes Wang]

If the device is unplugged or !netif_running(), the workqueue
doesn't need to wake the device, and could return directly.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 670279a..90cc89c 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2859,15 +2859,18 @@ static void rtl_work_func_t(struct work_struct *work)
 {
struct r8152 *tp = container_of(work, struct r8152, schedule.work);
 
+   /* If the device is unplugged or !netif_running(), the workqueue
+* doesn't need to wake the device, and could return directly.
+*/
+   if (test_bit(RTL8152_UNPLUG, &tp->flags) || !netif_running(tp->netdev))
+   return;
+
if (usb_autopm_get_interface(tp->intf) < 0)
return;
 
if (!test_bit(WORK_ENABLE, &tp->flags))
goto out1;
 
-   if (test_bit(RTL8152_UNPLUG, &tp->flags))
-   goto out1;
-
if (!mutex_trylock(&tp->control)) {
schedule_delayed_work(&tp->schedule, 0);
goto out1;
-- 
1.9.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 net-next v2 1/3] r8152: remove the duplicate init for the list of rx_done

[Hayes Wang]

The INIT_LIST_HEAD(&tp->rx_done) would be done in rtl_start_rx(),
so remove the unnecessary one in alloc_all_mem().

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f116335..ff54098 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1256,7 +1256,6 @@ static int alloc_all_mem(struct r8152 *tp)
 
spin_lock_init(&tp->rx_lock);
spin_lock_init(&tp->tx_lock);
-   INIT_LIST_HEAD(&tp->rx_done);
INIT_LIST_HEAD(&tp->tx_free);
skb_queue_head_init(&tp->tx_queue);
 
-- 
1.9.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 10/10] usb: dwc2/gadget: rework suspend/resume code to correctly restore gadget state

[Marek Szyprowski]

Hello,

On 2014-10-27 08:18, Marek Szyprowski wrote:


On 2014-10-25 03:16, Paul Zimmerman wrote:

From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Monday, October 20, 2014 3:46 AM

Suspend/resume code assumed that the gadget was always enabled and
connected to usb bus. This means that the actual state of the gadget
(soft-enabled/disabled or connected/disconnected) was not correctly
preserved on suspend/resume cycle. This patch fixes this issue.

Signed-off-by: Marek Szyprowski 
---
  drivers/usb/dwc2/core.h   |  4 +++-
  drivers/usb/dwc2/gadget.c | 43 
+++

  2 files changed, 30 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index bf015ab3b44c..3648b76a18b4 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -210,7 +210,9 @@ struct s3c_hsotg {
  u8  ctrl_buff[8];

  struct usb_gadget   gadget;
-unsigned intsetup;
+unsigned intsetup:1;
+unsigned intconnected:1;
+unsigned intenabled:1;
  unsigned long   last_rst;
  struct s3c_hsotg_ep *eps;
  };
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 0d34cfc71bfb..c6c6cf982c90 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2925,6 +2925,8 @@ static int s3c_hsotg_udc_start(struct 
usb_gadget *gadget,

  spin_lock_irqsave(&hsotg->lock, flags);
  s3c_hsotg_init(hsotg);
  s3c_hsotg_core_init_disconnected(hsotg);
+hsotg->enabled = 1;
+hsotg->connected = 0;
  spin_unlock_irqrestore(&hsotg->lock, flags);

  dev_info(hsotg->dev, "bound driver %s\n", driver->driver.name);
@@ -2961,6 +2963,8 @@ static int s3c_hsotg_udc_stop(struct 
usb_gadget *gadget,


  hsotg->driver = NULL;
  hsotg->gadget.speed = USB_SPEED_UNKNOWN;
+hsotg->enabled = 0;
+hsotg->connected = 0;

  spin_unlock_irqrestore(&hsotg->lock, flags);

@@ -2999,11 +3003,14 @@ static int s3c_hsotg_pullup(struct 
usb_gadget *gadget, int is_on)

  dev_dbg(hsotg->dev, "%s: is_on: %d\n", __func__, is_on);

  spin_lock_irqsave(&hsotg->lock, flags);
+
  if (is_on) {
  clk_enable(hsotg->clk);
+hsotg->connected = 1;
  s3c_hsotg_core_connect(hsotg);
  } else {
  s3c_hsotg_core_disconnect(hsotg);
+hsotg->connected = 0;
  clk_disable(hsotg->clk);
  }

@@ -3652,16 +3659,18 @@ static int s3c_hsotg_suspend(struct 
platform_device *pdev, pm_message_t state)

  dev_info(hsotg->dev, "suspending usb gadget %s\n",
   hsotg->driver->driver.name);

-spin_lock_irqsave(&hsotg->lock, flags);
-s3c_hsotg_core_disconnect(hsotg);
-s3c_hsotg_disconnect(hsotg);
-hsotg->gadget.speed = USB_SPEED_UNKNOWN;
-spin_unlock_irqrestore(&hsotg->lock, flags);
+if (hsotg->enabled) {

Hmm. Are you sure it's safe to check ->enabled outside of the spinlock?
What happens if s3c_hsotg_udc_stop() runs right after this, before the
spinlock is taken, and disables stuff? Sure, it's a tiny window, but
still...


This code is called only in system suspend path, when userspace has 
been already frozen.
udc_stop() can be called only as a result of userspace action, so it 
is imho safe to

assume that the above code doesn't need additional locking.


However if you prefer the version with explicit locking, I will send v3 
in a few minutes.


Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

--
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 2/2] usb: dwc2/gadget: rework suspend/resume code to correctly restore gadget state

[Marek Szyprowski]

Suspend/resume code assumed that the gadget was always enabled and
connected to usb bus. This means that the actual state of the gadget
(soft-enabled/disabled or connected/disconnected) was not correctly
preserved on suspend/resume cycle. This patch fixes this issue.

Signed-off-by: Marek Szyprowski 
---
 drivers/usb/dwc2/core.h   |  4 +++-
 drivers/usb/dwc2/gadget.c | 41 +
 2 files changed, 28 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 58732a9a0019..a1aa9ecf052e 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -211,7 +211,9 @@ struct s3c_hsotg {
u8  ctrl_buff[8];
 
struct usb_gadget   gadget;
-   unsigned intsetup;
+   unsigned intsetup:1;
+   unsigned intconnected:1;
+   unsigned intenabled:1;
unsigned long   last_rst;
unsigned intaddress;
struct s3c_hsotg_ep *eps;
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index a2e4272a904e..e61bb1c4275d 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2931,6 +2931,8 @@ static int s3c_hsotg_udc_start(struct usb_gadget *gadget,
spin_lock_irqsave(&hsotg->lock, flags);
s3c_hsotg_init(hsotg);
s3c_hsotg_core_init_disconnected(hsotg);
+   hsotg->enabled = 1;
+   hsotg->connected = 0;
spin_unlock_irqrestore(&hsotg->lock, flags);
 
dev_info(hsotg->dev, "bound driver %s\n", driver->driver.name);
@@ -2972,6 +2974,8 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget,
 
hsotg->driver = NULL;
hsotg->gadget.speed = USB_SPEED_UNKNOWN;
+   hsotg->enabled = 0;
+   hsotg->connected = 0;
 
spin_unlock_irqrestore(&hsotg->lock, flags);
 
@@ -3015,9 +3019,11 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget, 
int is_on)
spin_lock_irqsave(&hsotg->lock, flags);
if (is_on) {
clk_enable(hsotg->clk);
+   hsotg->connected = 1;
s3c_hsotg_core_connect(hsotg);
} else {
s3c_hsotg_core_disconnect(hsotg);
+   hsotg->connected = 0;
clk_disable(hsotg->clk);
}
 
@@ -3670,16 +3676,18 @@ static int s3c_hsotg_suspend(struct platform_device 
*pdev, pm_message_t state)
dev_info(hsotg->dev, "suspending usb gadget %s\n",
 hsotg->driver->driver.name);
 
-   spin_lock_irqsave(&hsotg->lock, flags);
-   s3c_hsotg_core_disconnect(hsotg);
-   s3c_hsotg_disconnect(hsotg);
-   hsotg->gadget.speed = USB_SPEED_UNKNOWN;
-   spin_unlock_irqrestore(&hsotg->lock, flags);
+   if (hsotg->enabled) {
+   int ep;
 
-   s3c_hsotg_phy_disable(hsotg);
+   spin_lock_irqsave(&hsotg->lock, flags);
+   if (hsotg->connected)
+   s3c_hsotg_core_disconnect(hsotg);
+   s3c_hsotg_disconnect(hsotg);
+   hsotg->gadget.speed = USB_SPEED_UNKNOWN;
+   spin_unlock_irqrestore(&hsotg->lock, flags);
+
+   s3c_hsotg_phy_disable(hsotg);
 
-   if (hsotg->driver) {
-   int ep;
for (ep = 0; ep < hsotg->num_of_eps; ep++)
s3c_hsotg_ep_disable(&hsotg->eps[ep].ep);
 
@@ -3705,18 +3713,19 @@ static int s3c_hsotg_resume(struct platform_device 
*pdev)
dev_info(hsotg->dev, "resuming usb gadget %s\n",
 hsotg->driver->driver.name);
 
+   if (hsotg->enabled) {
clk_enable(hsotg->clk);
ret = regulator_bulk_enable(ARRAY_SIZE(hsotg->supplies),
- hsotg->supplies);
-   }
-
-   s3c_hsotg_phy_enable(hsotg);
+   hsotg->supplies);
 
-   spin_lock_irqsave(&hsotg->lock, flags);
-   s3c_hsotg_core_init_disconnected(hsotg);
-   s3c_hsotg_core_connect(hsotg);
-   spin_unlock_irqrestore(&hsotg->lock, flags);
+   s3c_hsotg_phy_enable(hsotg);
 
+   spin_lock_irqsave(&hsotg->lock, flags);
+   s3c_hsotg_core_init_disconnected(hsotg);
+   if (hsotg->connected)
+   s3c_hsotg_core_connect(hsotg);
+   spin_unlock_irqrestore(&hsotg->lock, flags);
+   }
mutex_unlock(&hsotg->init_mutex);
 
return ret;
-- 
1.9.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 v3 1/2] usb: dwc2/gadget: add mutex to serialize init/deinit calls

[Marek Szyprowski]

This patch adds mutex, which protects initialization and
deinitialization procedures against suspend/resume methods.

Signed-off-by: Marek Szyprowski 
---
 drivers/usb/dwc2/core.h   |  1 +
 drivers/usb/dwc2/gadget.c | 20 
 2 files changed, 21 insertions(+)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 9f77b4d1c5ff..58732a9a0019 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -187,6 +187,7 @@ struct s3c_hsotg {
struct s3c_hsotg_plat*plat;
 
spinlock_t  lock;
+   struct mutexinit_mutex;
 
void __iomem*regs;
int irq;
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index d8dda39c9e16..a2e4272a904e 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2908,6 +2909,7 @@ static int s3c_hsotg_udc_start(struct usb_gadget *gadget,
return -EINVAL;
}
 
+   mutex_lock(&hsotg->init_mutex);
WARN_ON(hsotg->driver);
 
driver->driver.bus = NULL;
@@ -2933,9 +2935,12 @@ static int s3c_hsotg_udc_start(struct usb_gadget *gadget,
 
dev_info(hsotg->dev, "bound driver %s\n", driver->driver.name);
 
+   mutex_unlock(&hsotg->init_mutex);
+
return 0;
 
 err:
+   mutex_unlock(&hsotg->init_mutex);
hsotg->driver = NULL;
return ret;
 }
@@ -2957,6 +2962,8 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget,
if (!hsotg)
return -ENODEV;
 
+   mutex_lock(&hsotg->init_mutex);
+
/* all endpoints should be shutdown */
for (ep = 1; ep < hsotg->num_of_eps; ep++)
s3c_hsotg_ep_disable(&hsotg->eps[ep].ep);
@@ -2974,6 +2981,8 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget,
 
clk_disable(hsotg->clk);
 
+   mutex_unlock(&hsotg->init_mutex);
+
return 0;
 }
 
@@ -3002,6 +3011,7 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget, 
int is_on)
 
dev_dbg(hsotg->dev, "%s: is_on: %d\n", __func__, is_on);
 
+   mutex_lock(&hsotg->init_mutex);
spin_lock_irqsave(&hsotg->lock, flags);
if (is_on) {
clk_enable(hsotg->clk);
@@ -3013,6 +3023,7 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget, 
int is_on)
 
hsotg->gadget.speed = USB_SPEED_UNKNOWN;
spin_unlock_irqrestore(&hsotg->lock, flags);
+   mutex_unlock(&hsotg->init_mutex);
 
return 0;
 }
@@ -3507,6 +3518,7 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
}
 
spin_lock_init(&hsotg->lock);
+   mutex_init(&hsotg->init_mutex);
 
hsotg->irq = ret;
 
@@ -3652,6 +3664,8 @@ static int s3c_hsotg_suspend(struct platform_device 
*pdev, pm_message_t state)
unsigned long flags;
int ret = 0;
 
+   mutex_lock(&hsotg->init_mutex);
+
if (hsotg->driver)
dev_info(hsotg->dev, "suspending usb gadget %s\n",
 hsotg->driver->driver.name);
@@ -3674,6 +3688,8 @@ static int s3c_hsotg_suspend(struct platform_device 
*pdev, pm_message_t state)
clk_disable(hsotg->clk);
}
 
+   mutex_unlock(&hsotg->init_mutex);
+
return ret;
 }
 
@@ -3683,7 +3699,9 @@ static int s3c_hsotg_resume(struct platform_device *pdev)
unsigned long flags;
int ret = 0;
 
+   mutex_lock(&hsotg->init_mutex);
if (hsotg->driver) {
+
dev_info(hsotg->dev, "resuming usb gadget %s\n",
 hsotg->driver->driver.name);
 
@@ -3699,6 +3717,8 @@ static int s3c_hsotg_resume(struct platform_device *pdev)
s3c_hsotg_core_connect(hsotg);
spin_unlock_irqrestore(&hsotg->lock, flags);
 
+   mutex_unlock(&hsotg->init_mutex);
+
return ret;
 }
 
-- 
1.9.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: [PATCH RESEND V4 4/9] pinctrl: tegra-xusb: Add USB PHY support

[Thierry Reding]

On Thu, Oct 30, 2014 at 10:10:06AM -0700, Andrew Bresticker wrote:
> On Thu, Oct 30, 2014 at 6:45 AM, Thierry Reding
>  wrote:
> > On Wed, Oct 29, 2014 at 12:43:36PM -0700, Andrew Bresticker wrote:
> >> >> diff --git a/drivers/pinctrl/pinctrl-tegra-xusb.c 
> >> >> b/drivers/pinctrl/pinctrl-tegra-xusb.c
[...]
> >> >> diff --git a/include/soc/tegra/xusb.h b/include/soc/tegra/xusb.h
> >> >> index cfe211d..149434f 100644
> >> >> --- a/include/soc/tegra/xusb.h
> >> >> +++ b/include/soc/tegra/xusb.h
> >> >> @@ -10,6 +10,13 @@
> >> >>  #ifndef __SOC_TEGRA_XUSB_H__
> >> >>  #define __SOC_TEGRA_XUSB_H__
> >> >>
> >> >> +#define TEGRA_XUSB_USB3_PHYS 2
> >> >> +#define TEGRA_XUSB_UTMI_PHYS 3
> >> >> +#define TEGRA_XUSB_HSIC_PHYS 2
> >> >> +#define TEGRA_XUSB_NUM_USB_PHYS (TEGRA_XUSB_USB3_PHYS + 
> >> >> TEGRA_XUSB_UTMI_PHYS + \
> >> >> +  TEGRA_XUSB_HSIC_PHYS)
> >> >> +#define TEGRA_XUSB_NUM_PHYS (TEGRA_XUSB_NUM_USB_PHYS + 2) /* + SATA & 
> >> >> PCIe */
> >> >
> >> > These are really XUSB pad controller specific defines, why does anyone
> >> > else need to know this?
> >>
> >> They're not pad controller specific.  They're also used in the xHCI host 
> >> driver.
> >
> > I keep thinking that there should be a way around this. Of course if
> > both the XHCI and mailbox drivers were merged, then there'd be no need
> > to expose this publicly at all.
> 
> I'm not sure what you mean.  They're SoC-specific constants that need
> to be shared amongst multiple drivers.  It would make sense to place
> them in a shared header, does it not?

The problem with this is that if those numbers ever change on a future
generation of Tegra then we're going to have to suffix them in some way
to support more than one generation. And the code to handle that is
going to be ugly because we'd need to differentiate on the compatible
string to match which suffixed version to use.

So I'd rather see this parameterized some way. Of course that's a lot
more difficult to do because these things are shared across XHCI and pad
controller drivers.

That said, I think it'd be fine to merge this as-is for now and rewrite
this in a better way if it ever becomes a problem.

Thierry


pgpFVO4XciD5D.pgp
Description: PGP signature

Re: btusb_intr_complete returns -EPIPE

[Naveen Kumar Parna]

Hi ,

I tried on plenty of test servers(Fedora distribution) with USB-EHCI
and all these are having spurious STALL packets issue.

Today I got a test laptop(Ubuntu distribution) with USB-EHCI and
interestingly it does not report STALL packets. The only difference I
observed from lsusb is, Fedora test servers shows “Driver=ehci-pci/2p”
but Ubuntu Laptop shows “Driver=ehci-pci/3p”, but both has same EHCI
controller.


00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset
USB2 Enhanced Host Controller (rev 05)
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset
USB2 Enhanced Host Controller (rev 05)


Fedora test server:
[lowerlayers@banunxcas29 epipe_debug]$ lsusb -t
1-1.5.1:1.2: No such file or directory
1-1.5.2:1.2: No such file or directory
1-1.5.3:1.2: No such file or directory
1-1.5.4:1.2: No such file or directory

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M

|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/8p, 480M

|__ Port 1: Dev 3, If 0, Class=HID, Driver=usbhid, 12M

|__ Port 1: Dev 3, If 1, Class=HID, Driver=usbhid, 12M

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M

|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M

|__ Port 5: Dev 112, If 0, Class=hub, Driver=hub/4p, 480M

|__ Port 1: Dev 113, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 1: Dev 113, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 1: Dev 113, If 2, Class=app., Driver=, 12M

|__ Port 2: Dev 114, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 2: Dev 114, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 2: Dev 114, If 2, Class=app., Driver=, 12M

|__ Port 3: Dev 115, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 3: Dev 115, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 3: Dev 115, If 2, Class=app., Driver=, 12M

|__ Port 4: Dev 116, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 4: Dev 116, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 4: Dev 116, If 2, Class=app., Driver=, 12M



Ubuntu Laptop:
root@sandeep-E6410:/home/sandeep# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M

|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M

|__ Port 3: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M

|__ Port 1: Dev 5, If 0, Class=Wireless, Driver=btusb, 12M

|__ Port 1: Dev 5, If 1, Class=Wireless, Driver=btusb, 12M

|__ Port 1: Dev 5, If 2, Class=Application Specific
Interface, Driver=, 12M

|__ Port 2: Dev 6, If 0, Class=Wireless, Driver=btusb, 12M

|__ Port 2: Dev 6, If 1, Class=Wireless, Driver=btusb, 12M

|__ Port 2: Dev 6, If 2, Class=Application Specific
Interface, Driver=, 12M

|__ Port 3: Dev 7, If 0, Class=Wireless, Driver=btusb, 12M

|__ Port 3: Dev 7, If 1, Class=Wireless, Driver=btusb, 12M

|__ Port 3: Dev 7, If 2, Class=Application Specific
Interface, Driver=, 12M

|__ Port 4: Dev 8, If 0, Class=Wireless, Driver=btusb, 12M

|__ Port 4: Dev 8, If 1, Class=Wireless, Driver=btusb, 12M

|__ Port 4: Dev 8, If 2, Class=Application Specific
Interface, Driver=, 12M

|__ Port 8: Dev 3, If 0, Class=Application Specific Interface,
Driver=, 12M

|__ Port 8: Dev 3, If 1, Class=Chip/SmartCard, Driver=, 12M

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M

|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M

|__ Port 4: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M

|__ Port 4: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M


And in Fedora test servers Bluetooth devices are getting connected to
root_hub on the Bus-1, where as in Ubuntu Laptop these are getting
connected to root_hub on the Bus-2.


Does it gives any clue for the stall packet issue?

Thanks,
Naveen


lspci_nv_ubuntu
Description: Binary data


lspci_nv_fedora
Description: Binary data

Re: [PATCH RESEND V4 5/9] of: Add NVIDIA Tegra xHCI controller binding

[Thierry Reding]

On Thu, Oct 30, 2014 at 10:26:47AM -0700, Andrew Bresticker wrote:
> On Thu, Oct 30, 2014 at 10:24 AM, Thierry Reding
>  wrote:
> > On Thu, Oct 30, 2014 at 10:19:21AM -0700, Andrew Bresticker wrote:
> >> On Thu, Oct 30, 2014 at 6:55 AM, Thierry Reding
> >>  wrote:
> >> > On Wed, Oct 29, 2014 at 09:37:14AM -0700, Andrew Bresticker wrote:
> >> >> On Wed, Oct 29, 2014 at 2:43 AM, Thierry Reding
> >> >>  wrote:
> >> >> > On Tue, Oct 28, 2014 at 03:27:50PM -0700, Andrew Bresticker wrote:
> >> >> > [...]
> >> >> >> diff --git 
> >> >> >> a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
> >> >> >>  
> >> >> >> b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
> >> >> > [...]
> >> >> >> +Optional properties:
> >> >> >> +---
> >> >> >> +- vbus-{0,1,2}-supply: VBUS regulator for the corresponding UTMI 
> >> >> >> pad.
> >> >> >> +- vddio-hsic-supply: VDDIO regulator for the HSIC pads.
> >> >> >> +- nvidia,usb3-port-{0,1}-lane: PCIe/SATA lane to which the 
> >> >> >> corresponding USB3
> >> >> >> +  port is mapped.  See  
> >> >> >> for the list
> >> >> >> +  of valid values.
> >> >> >
> >> >> > I dislike how we now need to provide a list of all pins in the header
> >> >> > file, where previously we used strings for this. This could become 
> >> >> > very
> >> >> > ugly if the set of pins changes in future generations of this IP 
> >> >> > block.
> >> >> >
> >> >> > Could we instead derive this from the pinmux nodes? For example you 
> >> >> > have
> >> >> > this in the example below:
> >> >> >
> >> >> > usb3p0 {
> >> >> > nvidia,lanes = "pcie-0";
> >> >> > ...
> >> >> > };
> >> >> >
> >> >> > Perhaps what we need is to either key off the node name or add another
> >> >> > property, such as:
> >> >> >
> >> >> > nvidia,usb3-port = <0>;
> >> >> >
> >> >> > This would match the nvidia,usb2-port property that you've added 
> >> >> > below.
> >> >>
> >> >> That is actually how I described the USB3 port to SS lane mapping
> >> >> originally, but in review of an earlier version of this series,
> >> >> Stephen suggested that I make it a separate, not pinconfig property
> >> >> since it wasn't a value written directly to the hardware.  I'm fine
> >> >> with changing it back as the pinconfig property makes more sense to me
> >> >> as well.
> >> >
> >> > Hmm... I had considered it a mux option of the specific lane. If the
> >> > function is usb3, it'd still need to be muxed to one of the ports. So
> >> > it's additional information associated with the usb3 function.
> >> >
> >> > I did look through the driver changes and can't really make out which
> >> > part of the code actually performs this assignment. Can you point me to
> >> > it?
> >>
> >> There's not really an assignment.  The property is used to map between
> >> a lane (e.g. PCIe-0 or SATA) and the USB3.0 port it's mapped to.  For
> >> an example of where it's used, take a look at usb3_phy_power_on().
> >> There are certain per-lane registers which need to be programmed in
> >> addition to the per-USB3.0 port pad registers.  This mapping is used
> >> to determine which lane needs to be programmed.
> >
> > Are you saying the mapping of lane to USB port is fixed? That is, PCIe-0
> > lane is always used for USB port X and SATA always for USB port Y?
> 
> No, sorry if that was unclear, it's not fixed - it's a board specific
> property.

Okay, but there's no register that contains the mapping of the port to a
lane, similar to what's done for the functions, right? I mean the driver
only uses the lane to find out which register to write. Doesn't that
imply that two lanes (or more) could be mapped to the same USB 3.0 port?

I'm not sure I'm being clear here, so let me try another way. In order
to establish a mapping between USB port and lane, I would've expected
one of the following to happen:

- A value derived from the lane number is written to a register
  belonging to a given port.

- A value derived from the port number is written to a register
  belonging to a given lane.

I can't see the code do either of the above, which to me implies that
there's a fixed mapping between lanes and ports. What am I missing?

Thierry


pgpR4gP9t4sqG.pgp
Description: PGP signature

Re: [PATCH v4-real] cdc-acm: ensure that termios get set when the port is activated

[Johan Hovold]

On Thu, Oct 30, 2014 at 11:04:47AM -0400, Jim Paris wrote:
> The driver wasn't properly configuring the hardware for the current
> termios settings under all conditions.  Ensure that termios are
> written to the device when the port is activated.
> 
> Signed-off-by: Jim Paris 

Reviewed-by: Johan Hovold 

> ---
> 
> Johan Hovold wrote:
> > On Thu, Oct 30, 2014 at 10:45:38AM -0400, Jim Paris wrote:
> > > Moved prototype.
> > 
> > You seem to have posted the old version again.
> 
> Doh.  Fixed.

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: [PATCHv4 2/6] phy: improved lookup method

[Vivek Gautam]

Hi Heikki,


On Fri, Oct 17, 2014 at 8:09 PM, Heikki Krogerus
 wrote:
> Removes the need for the phys to be aware of their users
> even when not using DT. The method is copied from clkdev.c.
>
> Signed-off-by: Heikki Krogerus 
> Tested-by: Vivek Gautam 
> ---
>  Documentation/phy.txt   |  66 ---
>  drivers/phy/phy-core.c  | 135 
> +++-
>  include/linux/phy/phy.h |  27 ++
>  3 files changed, 183 insertions(+), 45 deletions(-)
>
> diff --git a/Documentation/phy.txt b/Documentation/phy.txt
> index c6594af..8add515 100644
> --- a/Documentation/phy.txt
> +++ b/Documentation/phy.txt
> @@ -54,18 +54,14 @@ The PHY driver should create the PHY in order for other 
> peripheral controllers
>  to make use of it. The PHY framework provides 2 APIs to create the PHY.
>
>  struct phy *phy_create(struct device *dev, struct device_node *node,
> -  const struct phy_ops *ops,
> -  struct phy_init_data *init_data);
> +  const struct phy_ops *ops);
>  struct phy *devm_phy_create(struct device *dev, struct device_node *node,
> -   const struct phy_ops *ops,
> -   struct phy_init_data *init_data);
> +   const struct phy_ops *ops);
>
>  The PHY drivers can use one of the above 2 APIs to create the PHY by passing
> -the device pointer, phy ops and init_data.
> +the device pointer and phy ops.
>  phy_ops is a set of function pointers for performing PHY operations such as
> -init, exit, power_on and power_off. *init_data* is mandatory to get a 
> reference
> -to the PHY in the case of non-dt boot. See section *Board File 
> Initialization*
> -on how init_data should be used.
> +init, exit, power_on and power_off.
>
>  Inorder to dereference the private data (in phy_ops), the phy provider driver
>  can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in
> @@ -137,42 +133,24 @@ There are exported APIs like phy_pm_runtime_get, 
> phy_pm_runtime_get_sync,
>  phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and
>  phy_pm_runtime_forbid for performing PM operations.
>
> -8. Board File Initialization
> -
> -Certain board file initialization is necessary in order to get a reference
> -to the PHY in the case of non-dt boot.
> -Say we have a single device that implements 3 PHYs that of USB, SATA and 
> PCIe,
> -then in the board file the following initialization should be done.
> -
> -struct phy_consumer consumers[] = {
> -   PHY_CONSUMER("dwc3.0", "usb"),
> -   PHY_CONSUMER("pcie.0", "pcie"),
> -   PHY_CONSUMER("sata.0", "sata"),
> -};
> -PHY_CONSUMER takes 2 parameters, first is the device name of the controller
> -(PHY consumer) and second is the port name.
> -
> -struct phy_init_data init_data = {
> -   .consumers = consumers,
> -   .num_consumers = ARRAY_SIZE(consumers),
> -};
> -
> -static const struct platform_device pipe3_phy_dev = {
> -   .name = "pipe3-phy",
> -   .id = -1,
> -   .dev = {
> -   .platform_data = {
> -   .init_data = &init_data,
> -   },
> -   },
> -};
> -
> -then, while doing phy_create, the PHY driver should pass this init_data
> -   phy_create(dev, ops, pdata->init_data);
> -
> -and the controller driver (phy consumer) should pass the port name along with
> -the device to get a reference to the PHY
> -   phy_get(dev, "pcie");
> +8. PHY Mappings
> +
> +In order to get reference to a PHY without help from DeviceTree, the 
> framework
> +offers lookups which can be compared to clkdev that allow clk structures to 
> be
> +bound to devices. A lookup can be made statically by directly registering
> +phy_lookup structure which contains the name of the PHY device, the name of 
> the
> +device which the PHY will be bind to and Connection ID string. Alternatively 
> a
> +lookup can be made during runtime when a handle to the struct phy already
> +exists.
> +
> +The framework offers the following APIs for registering and unregistering the
> +lookups.
> +
> +void phy_register_lookup(struct phy_lookup *pl);
> +int phy_create_lookup(struct phy *phy, const char *con_id, const char 
> *dev_id);
> +
> +void phy_unregister_lookup(struct phy_lookup *pl);
> +void phy_remove_lookup(struct phy *phy, const char *con_id, const char 
> *dev_id);
>
>  9. DeviceTree Binding
>
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index ff5eec5..c8d0f66 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -26,6 +26,7 @@
>  static struct class *phy_class;
>  static DEFINE_MUTEX(phy_provider_mutex);
>  static LIST_HEAD(phy_provider_list);
> +static LIST_HEAD(phys);
>  static DEFINE_IDA(phy_ida);
>
>  static void devm_phy_release(struct device *dev, void *res)
> @@ -84,6 +85,138 @@ static struct phy *phy_lookup(struct device *device, 
> const char *port)
> return ERR_PTR(-ENODEV);
> 

re: usb: gadget: f_uac1: convert to new function interface with backward compatibility

[Dan Carpenter]

Hello Andrzej Pietrasiewicz,

This is a semi-automatic email about new static checker warnings.

The patch f3a3406b3f56: "usb: gadget: f_uac1: convert to new function
interface with backward compatibility" from Jul 22, 2014, leads to
the following Smatch complaint:

drivers/usb/gadget/function/u_uac1.c:216 gaudio_open_snd_dev()
 warn: variable dereferenced before check 'card' (see line 211)

drivers/usb/gadget/function/u_uac1.c
   210  
   211  opts = container_of(card->func.fi, struct f_uac1_opts, 
func_inst);
^
New dereference.

   212  fn_play = opts->fn_play;
  ^
Technically, I think the container_of() just does pointer math and the
actual dereference is here.  I'm not sure, either way it's dereferenced.

   213  fn_cap = opts->fn_cap;
   214  fn_cntl = opts->fn_cntl;
   215  
   216  if (!card)
^
Existing code assumes card can be NULL.

   217  return -ENODEV;
   218  

regards,
dan carpenter
--
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/2] ARM: shmobile: lager: enable USB3.0

[yoshihiro shimoda]

Hi Simon-san,

> On Fri, Oct 31, 2014 at 02:06:14AM +, yoshihiro shimoda wrote:
> > Hi Simon-san,
> >
> > > On Wed, Oct 29, 2014 at 08:19:30PM +0900, Yoshihiro Shimoda wrote:
> > > > Hi Magnus-san,
> > > >
> > > > (2014/10/29 15:53), Magnus Damm wrote:
> > < snip >
> > > > >
> > > > > Hi Shimoda-san,
> > > > >
> > > > > Thanks for your patch. I'm fine with this patch as a first step,
> > > > > but I'm wondering what the reason is to prioritize USB 2.0 over USB 
> > > > > 3.0?
> > > >
> > > > I investigated this reason today, and I found the reason is
> > > > request_firmware().  I checked the following environments:
> > > >
> > > > Case 1: xHCI and EHCI and OHCI are enabled "=y"
> > > > Case 2: xHCI and EHCI and OHCI are loadable modules "=m"
> > > > Case 3: xHCI and EHCI and OHCI are enabled "=y",
> > > > and CONFIG_EXTRA_FIRMWARE is enabled
> > > >
> > > > The results are:
> > > > - In "Case 1", EHCI and OHCI are probed first because xHCI didn't find 
> > > > the firmware.
> > > > - In "Case 2" and "Case 3", xHCI is probed first.
> > > >
> > > > > Is the current order just based on device init order? In my mind
> > > > > the expected behavior would be to always use USB 3.0 if it
> > > > > happens to be available in the hardware, specified in the DTS,
> > > > > enabled by the kernel configuration and firmware is loadable. Or
> > > > > does some case exist where it is better to use USB 2.0? I suspect no.
> > > >
> > > > I agree with you.
> > > >
> > > > > So I wonder if you have any plans how to make USB 3.0 enabled by
> > > > > default on Lager?
> > > >
> > > > It depends on a kernel config. I'm not sure of the
> > > > shmobile_defconfig strategy.  But, in my opinion, one of a
> > > > solution is kernel modules (this means the "Case 2".)
> > >
> > > It sounds like we should enable CONFIG_EXTRA_FIRMWARE in
> > > shmobile_defconfig. I wonder what if any fallout we can foresee occurring 
> > > if we do that.
> >
> > According to the firmware/README.AddingFirmware, we are unable to add a new 
> > firmware image to the firmware directory
> now.
> > So, if we enable CONFIG_EXTRA_FIRMWARE with the xHCI firmware, we will not 
> > build kernel because the xHCI firmware doesn't
> exist in the linux.git.
> >
> > === from  firmware/README.AddingFirmware
> > =
> > This directory is _NOT_ for adding arbitrary new firmware images. The
> > place to add those is the separate linux-firmware repository:
> >
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.
> > git
> > ==
> > 
> 
> Thanks. It seems that EXTRA_FIRMWARE is not an option from a mainline point 
> of view after all.
> 
> Is the problem in case 1 that the firmware can't be found because userspace 
> does exist yet and thus can't be loaded from
> there?

That's correct.
If EXTRA_FIRMWARE is not set, the following error happens:

xhci-hcd ee00.usb: Direct firmware load for r8a779x_usb3_v1.dlmem failed 
with error -2
xhci-hcd ee00.usb: can't setup: -2
xhci-hcd ee00.usb: USB bus 1 deregistered
xhci-hcd: probe of ee00.usb failed with error -2

Best regards,
Yoshihiro Shimoda

--
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 v7 2/2] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Vivek Gautam]

Adding phy calibration sequence for USB 3.0 DRD PHY present on
Exynos5420/5800 systems.
This calibration facilitates setting certain PHY parameters viz.
the Loss-of-Signal (LOS) Detector Threshold Level, as well as
Tx-Vboost-Level for Super-Speed operations.
Additionally we also set proper time to wait for RxDetect measurement,
for desired PHY reference clock, so as to solve issue with enumeration
of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive
on the controller.

We are using CR_port for this purpose to send required data
to override the LOS values.

On testing with USB 3.0 devices on USB 3.0 port present on
SMDK5420, and peach-pit boards should see following message:
usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd

and without this patch, should see below shown message:
usb 1-1: new high-speed USB device number 2 using xhci-hcd

[Also removed unnecessary extra lines in the register macro definitions]

Signed-off-by: Vivek Gautam 
---
 drivers/phy/phy-exynos5-usbdrd.c |  219 +++---
 1 file changed, 203 insertions(+), 16 deletions(-)

diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index b3ca3bc..1a63634 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -37,13 +37,11 @@
 
 /* EXYNOS5: USB 3.0 DRD PHY registers */
 #define EXYNOS5_DRD_LINKSYSTEM 0x04
-
 #define LINKSYSTEM_FLADJ_MASK  (0x3f << 1)
 #define LINKSYSTEM_FLADJ(_x)   ((_x) << 1)
 #define LINKSYSTEM_XHCI_VERSION_CONTROLBIT(27)
 
 #define EXYNOS5_DRD_PHYUTMI0x08
-
 #define PHYUTMI_OTGDISABLE BIT(6)
 #define PHYUTMI_FORCESUSPEND   BIT(1)
 #define PHYUTMI_FORCESLEEP BIT(0)
@@ -51,26 +49,20 @@
 #define EXYNOS5_DRD_PHYPIPE0x0c
 
 #define EXYNOS5_DRD_PHYCLKRST  0x10
-
 #define PHYCLKRST_EN_UTMISUSPEND   BIT(31)
-
 #define PHYCLKRST_SSC_REFCLKSEL_MASK   (0xff << 23)
 #define PHYCLKRST_SSC_REFCLKSEL(_x)((_x) << 23)
-
 #define PHYCLKRST_SSC_RANGE_MASK   (0x03 << 21)
 #define PHYCLKRST_SSC_RANGE(_x)((_x) << 21)
-
 #define PHYCLKRST_SSC_EN   BIT(20)
 #define PHYCLKRST_REF_SSP_EN   BIT(19)
 #define PHYCLKRST_REF_CLKDIV2  BIT(18)
-
 #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11)
 #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF   (0x19 << 11)
 #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF  (0x32 << 11)
 #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF(0x68 << 11)
 #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF(0x7d << 11)
 #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11)
-
 #define PHYCLKRST_FSEL_UTMI_MASK   (0x7 << 5)
 #define PHYCLKRST_FSEL_PIPE_MASK   (0x7 << 8)
 #define PHYCLKRST_FSEL(_x) ((_x) << 5)
@@ -78,46 +70,68 @@
 #define PHYCLKRST_FSEL_PAD_24MHZ   (0x2a << 5)
 #define PHYCLKRST_FSEL_PAD_20MHZ   (0x31 << 5)
 #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5)
-
 #define PHYCLKRST_RETENABLEN   BIT(4)
-
 #define PHYCLKRST_REFCLKSEL_MASK   (0x03 << 2)
 #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2)
 #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2)
-
 #define PHYCLKRST_PORTRESETBIT(1)
 #define PHYCLKRST_COMMONONNBIT(0)
 
 #define EXYNOS5_DRD_PHYREG00x14
+#define PHYREG0_SSC_REF_CLK_SELBIT(21)
+#define PHYREG0_SSC_RANGE  BIT(20)
+#define PHYREG0_CR_WRITE   BIT(19)
+#define PHYREG0_CR_READBIT(18)
+#define PHYREG0_CR_DATA_IN(_x) ((_x) << 2)
+#define PHYREG0_CR_CAP_DATABIT(1)
+#define PHYREG0_CR_CAP_ADDRBIT(0)
+
 #define EXYNOS5_DRD_PHYREG10x18
+#define PHYREG1_CR_DATA_OUT(_x)((_x) << 1)
+#define PHYREG1_CR_ACK BIT(0)
 
 #define EXYNOS5_DRD_PHYPARAM0  0x1c
-
 #define PHYPARAM0_REF_USE_PAD  BIT(31)
 #define PHYPARAM0_REF_LOSLEVEL_MASK(0x1f << 26)
 #define PHYPARAM0_REF_LOSLEVEL (0x9 << 26)
 
 #define EXYNOS5_DRD_PHYPARAM1  0x20
-
 #define PHYPARAM1_PCS_TXDEEMPH_MASK(0x1f << 0)
 #define PHYPARAM1_PCS_TXDEEMPH (0x1c)
 
 #define EXYNOS5_DRD_PHYTERM0x24
 
 #define EXYNOS5_DRD_PHYTEST0x28
-
 #define PHYTEST_POWERDOWN_SSP  BIT(3)
 #define PHYTEST_POWERDOWN_HSP  BIT(2)
 
 #define EXYNOS5_DRD_PHYADP 0x2c
 
 #define EXYNOS5_DRD_PHYUTMICLKSEL  0x30
-
 #define PHYUTMICLKSEL_UTMI_CLKSEL  BIT(2)
 
 #define EXYNOS5_DRD_PHYRESU

[PATCH v7 1/2] usb: host: xhci-plat: Get PHYs for xhci's hcds

[Vivek Gautam]

The host controller by itself may sometimes need to handle PHY
and re-initialize it to re-configure some of the PHY parameters
to get full support out of the PHY controller.
Therefore, facilitate getting the two possible PHYs, viz.
USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3), and initialize them.

Signed-off-by: Vivek Gautam 
---
 drivers/usb/host/xhci-plat.c |   74 ++
 1 file changed, 74 insertions(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 3d78b0c..5207d5b 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -129,10 +130,41 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_hcd;
}
 
+   /* Get possile USB 2.0 type PHY (UTMI+) available with xhci */
+   hcd->phy = devm_phy_get(&pdev->dev, "usb2-phy");
+   if (IS_ERR(hcd->phy)) {
+   ret = PTR_ERR(hcd->phy);
+   if (ret == -EPROBE_DEFER) {
+   goto disable_clk;
+   } else if (ret != -ENOSYS && ret != -ENODEV) {
+   hcd->phy = NULL;
+   dev_warn(&pdev->dev,
+"Error retrieving usb2 phy: %d\n", ret);
+   }
+   }
+
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto disable_clk;
 
+   /*
+* Initialize and power-on USB 2.0 PHY
+* FIXME: Isn't this a hacky way of initializing the PHY again ?
+* xhci's parent would have already initialized the PHY, but we
+* wanna do it again.
+*/
+   hcd->phy->init_count = 0;
+   ret = phy_init(hcd->phy);
+   if (ret)
+   goto dealloc_usb2_hcd;
+
+   hcd->phy->power_count = 0;
+   ret = phy_power_on(hcd->phy);
+   if (ret) {
+   phy_exit(hcd->phy);
+   goto dealloc_usb2_hcd;
+   }
+
device_wakeup_enable(hcd->self.controller);
 
/* USB 2.0 roothub is stored in the platform_device now. */
@@ -158,12 +190,41 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
xhci->shared_hcd->can_do_streams = 1;
 
+   /* Get possile USB 3.0 type PHY (PIPE3) available with xhci */
+   xhci->shared_hcd->phy = devm_phy_get(&pdev->dev, "usb3-phy");
+   if (IS_ERR(xhci->shared_hcd->phy)) {
+   ret = PTR_ERR(xhci->shared_hcd->phy);
+   if (ret == -EPROBE_DEFER) {
+   goto put_usb3_hcd;
+   } else if (ret != -ENOSYS && ret != -ENODEV) {
+   xhci->shared_hcd->phy = NULL;
+   dev_warn(&pdev->dev,
+"Error retrieving usb3 phy: %d\n", ret);
+   }
+   }
+
ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
if (ret)
goto put_usb3_hcd;
 
+   /* Initialize and power-on USB 3.0 PHY */
+   xhci->shared_hcd->phy->init_count = 0;
+   ret = phy_init(xhci->shared_hcd->phy);
+   if (ret)
+   goto dealloc_usb3_hcd;
+
+   xhci->shared_hcd->phy->power_count = 0;
+   ret = phy_power_on(xhci->shared_hcd->phy);
+   if (ret) {
+   phy_exit(xhci->shared_hcd->phy);
+   goto dealloc_usb3_hcd;
+   }
+
return 0;
 
+dealloc_usb3_hcd:
+   usb_remove_hcd(xhci->shared_hcd);
+
 put_usb3_hcd:
usb_put_hcd(xhci->shared_hcd);
 
@@ -186,9 +247,15 @@ static int xhci_plat_remove(struct platform_device *dev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct clk *clk = xhci->clk;
 
+   phy_power_off(xhci->shared_hcd->phy);
+   phy_exit(xhci->shared_hcd->phy);
+
usb_remove_hcd(xhci->shared_hcd);
usb_put_hcd(xhci->shared_hcd);
 
+   phy_power_off(hcd->phy);
+   phy_exit(hcd->phy);
+
usb_remove_hcd(hcd);
if (!IS_ERR(clk))
clk_disable_unprepare(clk);
@@ -204,6 +271,8 @@ static int xhci_plat_suspend(struct device *dev)
struct usb_hcd  *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
 
+   phy_exit(hcd->phy);
+
return xhci_suspend(xhci);
 }
 
@@ -211,6 +280,11 @@ static int xhci_plat_resume(struct device *dev)
 {
struct usb_hcd  *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+   int ret;
+
+   ret = phy_init(hcd->phy);
+   if (ret)
+   return ret;
 
return xhci_resume(xhci, 0);
 }
-- 
1.7.10.4

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

[PATCH v7 0/2] Fine tune USB 3.0 PHY on exynos5420

[Vivek Gautam]

This series is tested with V3 of Heikki's patches for simpliefied phy lookup 
table:
[PATCHv3 0/6] phy: simplified phy lookup [1] on 'usb-next' branch.
V4 of this series is giving some issue, which i have already pointed out in the
patch: [PATCHv4 2/6] phy: improved lookup method

Changes since v6:
 - Dropped the changes for adding additional phy_calibrate() callback.
 - Added phy_init() and phy_power_on() sequence in xhci-plat driver;
   NOTE: both phy_init() and phy_power_on() will now require PHY's
 'init_count' and 'power_count' to be reset to '0' so that
 we can actually re-initialize the phy. Though this has already been
 pointed out in discussion for the previous patch-series. [2]
 - Refactored return codes and error handling in cr_port functions as pointed
   out by Felipe.

Changes since v5:
 - Assigned NULL to hcd->gen_phy in error path in xhci-plat.c, so that
   we don't need to check for IS_ERR() while calibrating the PHYs in
   core/hcd.c
 - Removed extra empty lines in register definitions in exynos5-usbdrd
   phy driver.
 - Added write access for EXYNOS5_DRD_PHYREG0 register before any
   crport_handshake() call as suggested by Jingoo Han.
 - Renamed member 'calibrate' to 'phy_exynos_calibrate' of
   struct exynos5_usbdrd_phy_drvdata.

Changes since v4:
 - Rebased on latest patches by Heikki.
 - Took care of handling -EPROBE_DEFER error number while getting PHY in
   xhci plat.

Changes from v3:
 - Modified error message as per review comments from Julius.

Changes since v2:
 - Removed any check for DWC3 in xhci-plat for getting usb2-phy and usb3-phy,
   in order to make it more generic.
 - Moved the phy_calibration calls to core/hcd.c to enable a more generic
   solution for issues of calibrating the PHYs.

Changes since v1:
 - Using 'gen_phy' member of 'hcd' instead of declaring more variables
   to hold phys.
 - Added a check for compatible match for 'Synopsys-dwc3' controller,
   since the 'gen_phy' member of 'hcd' already gets the 'usb' PHY
   in core/hcd.c; but XHCI on Synopsys-dwc3 doesn't need that,
   instead two separate PHYs for UTMI+ and PIPE3 for the two HCDs
   (main hcd and shared hcd).
 - Restructured the code in 'xhci_plat_setup()' and 'xhci_plat_resume()'
   to use hcd->gen_phy directly. Also added the check for Synopsys's DWC3
   controller while trying to calibrate the PHY.

Explanation for the need of this patch-series:
"The DWC3-exynos eXtensible host controller present on Exynos5420/5800
SoCs is quirky. The PHY serving this controller operates at High-Speed
by default, so it detects even Super-speed devices as high-speed ones.
Certain PHY parameters like Tx LOS levels and Boost levels need to be
calibrated further post initialization of xHCI controller, to get
SuperSpeed operations working."

[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg710094.html
[2] https://lkml.org/lkml/2014/9/2/170;   (to be specific 
https://lkml.org/lkml/2014/9/10/132)

Vivek Gautam (2):
  usb: host: xhci-plat: Get PHYs for xhci's hcds
  phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

 drivers/phy/phy-exynos5-usbdrd.c |  219 +++---
 drivers/usb/host/xhci-plat.c |   74 +
 2 files changed, 277 insertions(+), 16 deletions(-)

-- 
1.7.10.4

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

Re: [PATCH v7 1/7] usb: move the OTG state from the USB PHY to the OTG structure

[Felipe Balbi]

Hi,

On Thu, Oct 30, 2014 at 07:47:10PM -0500, Felipe Balbi wrote:
> Hi,
> 
> On Fri, Oct 31, 2014 at 08:38:14AM +0800, Peter Chen wrote:
> > On Thu, Oct 30, 2014 at 12:47:34PM -0500, Felipe Balbi wrote:
> > > On Thu, Oct 30, 2014 at 06:42:54PM +0100, Antoine Tenart wrote:
> > > > Hi Felipe,
> > > > 
> > > > On Thu, Oct 30, 2014 at 11:35:13AM -0500, Felipe Balbi wrote:
> > > > > On Thu, Oct 30, 2014 at 11:31:48AM -0500, Felipe Balbi wrote:
> > > > > > On Tue, Oct 28, 2014 at 05:35:35PM +0100, Antoine Tenart wrote:
> > > > > > > Before using the PHY framework instead of the USB PHY one, we 
> > > > > > > need to
> > > > > > > move the OTG state into another place, since it won't be 
> > > > > > > available when
> > > > > > > USB PHY isn't used. This patch moves the OTG state into the OTG
> > > > > > > structure, and makes all the needed modifications in the drivers
> > > > > > > using the OTG state.
> > > > > > > 
> > > > > > > Signed-off-by: Antoine Tenart 
> > > > > > > Acked-by: Peter Chen 
> > > > > > 
> > > > > > Acked-by: Felipe Balbi 
> > > > > 
> > > > > Please rebase on my testing/next and I'll take the series. When
> > > > > rebasing, then add Peter's Tested-by/Acked-by where they're missing.
> > > > 
> > > > I just re-sent the series, rebased on your testing/next branch.
> > > 
> > > Thanks, I put them on my testing/next and I'm running build tests.
> > > 
> > 
> > I see them, I will rebase your testing/next tree for coming chipidea dev, 
> > thanks.
> 
> I fixed a build breakage caused by $subject which I fixed, updated patch
> below: (Aaro, can I get a tested-by by any chance ?)

two more build regressions found (did you build test your patches ??)

8<--

commit 63e3b7dd13426d4452f5b26ceae2af4a4e5de5b3
Author: Antoine Tenart 
Date:   Thu Oct 30 18:41:13 2014 +0100

usb: move the OTG state from the USB PHY to the OTG structure

Before using the PHY framework instead of the USB PHY one, we need to
move the OTG state into another place, since it won't be available when
USB PHY isn't used. This patch moves the OTG state into the OTG
structure, and makes all the needed modifications in the drivers
using the OTG state.

[ ba...@ti.com : fix build regressions with phy-tahvo.c, musb_dsps.c
and chipidea's debug.c ]

Signed-off-by: Antoine Tenart 
Acked-by: Peter Chen 
Signed-off-by: Felipe Balbi 

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 8c84298..9f409359 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -80,11 +80,9 @@ static int omap_usb_start_srp(struct usb_otg *otg)
 
 static int omap_usb_set_host(struct usb_otg *otg, struct usb_bus *host)
 {
-   struct usb_phy  *phy = otg->phy;
-
otg->host = host;
if (!host)
-   phy->state = OTG_STATE_UNDEFINED;
+   otg->state = OTG_STATE_UNDEFINED;
 
return 0;
 }
@@ -92,11 +90,9 @@ static int omap_usb_set_host(struct usb_otg *otg, struct 
usb_bus *host)
 static int omap_usb_set_peripheral(struct usb_otg *otg,
struct usb_gadget *gadget)
 {
-   struct usb_phy  *phy = otg->phy;
-
otg->gadget = gadget;
if (!gadget)
-   phy->state = OTG_STATE_UNDEFINED;
+   otg->state = OTG_STATE_UNDEFINED;
 
return 0;
 }
diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
index 795d653..f038804 100644
--- a/drivers/usb/chipidea/debug.c
+++ b/drivers/usb/chipidea/debug.c
@@ -220,7 +220,7 @@ static int ci_otg_show(struct seq_file *s, void *unused)
 
/* -- State - */
seq_printf(s, "OTG state: %s\n\n",
-   usb_otg_state_string(ci->transceiver->state));
+   usb_otg_state_string(ci->transceiver->otg->state));
 
/* -- State Machine Variables - */
seq_printf(s, "a_bus_drop: %d\n", fsm->a_bus_drop);
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index caaabc5..8cb2508 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -328,7 +328,7 @@ static void b_ssend_srp_tmout_func(void *ptr, unsigned long 
indicator)
set_tmout(ci, indicator);
 
/* only vbus fall below B_sess_vld in b_idle state */
-   if (ci->transceiver->state == OTG_STATE_B_IDLE)
+   if (ci->fsm.otg->state == OTG_STATE_B_IDLE)
ci_otg_queue_work(ci);
 }
 
@@ -582,11 +582,11 @@ int ci_otg_fsm_work(struct ci_hdrc *ci)
 * when there is no gadget class driver
 */
if (ci->fsm.id && !(ci->driver) &&
-   ci->transceiver->state < OTG_STATE_A_IDLE)
+   ci->fsm.otg->state < OTG_STATE_A_IDLE)
return 0;
 
if (otg_statemachine(&ci->fsm)) {
-   if (ci->transceiver->state == OTG_STATE_A_IDLE) {
+   if (ci->fsm.otg->state == OTG_STATE_A_IDLE) {

[PATCH] uas: Add US_FL_NO_ATA_1X quirk for 1 more Seagate model

[Hans de Goede]

These drives hang when receiving ATA12 commands, so set the US_FL_NO_ATA_1X
quirk to filter these out.

Cc: sta...@vger.kernel.org # 3.16
Signed-off-by: Hans de Goede 
---
 drivers/usb/storage/unusual_uas.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/storage/unusual_uas.h 
b/drivers/usb/storage/unusual_uas.h
index 44ab3289..2fefaf9 100644
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -75,6 +75,13 @@ UNUSUAL_DEV(0x0bc2, 0xab20, 0x, 0x,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_NO_ATA_1X),
 
+/* https://bbs.archlinux.org/viewtopic.php?id=183190 */
+UNUSUAL_DEV(0x0bc2, 0xab21, 0x, 0x,
+   "Seagate",
+   "Backup+ BK",
+   USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+   US_FL_NO_ATA_1X),
+
 /* Reported-by: Claudio Bizzarri  */
 UNUSUAL_DEV(0x152d, 0x0567, 0x, 0x,
"JMicron",
-- 
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

Re: [PATCH v5 1/4] usb: renesas_usbhs: gadget: fix NULL pointer dereference in ep_disable()

[Felipe Balbi]

On Fri, Oct 31, 2014 at 01:20:08PM +0900, Yoshihiro Shimoda wrote:
> From: Kazuya Mizuguchi 
> 
> This patch fixes an issue that the NULL pointer dereference happens
> when we uses g_audio driver. Since the g_audio driver will call
> usb_ep_disable() in afunc_set_alt() before it calls usb_ep_enable(),
> the uep->pipe of renesas usbhs driver will be NULL. So, this patch
> adds a condition to avoid the oops.
> 
> Signed-off-by: Kazuya Mizuguchi 
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Yoshihiro Shimoda 
> Fixes: 132fcb4608 (usb: gadget: Add Audio Class 2.0 Driver)

since this change is not patching the audio class driver, you can be
fixing that commit. Looking at the history of that file, it seems like
this was always broken since day one of this driver (commit 2f98382dc)
and if that's the case, this should become:

Fixes: 2f98382dc (usb: renesas_usbhs: Add Renesas USBHS Gadget)
Cc:  # v3.0+

> Cc:  # v3.3+
> ---
>  drivers/usb/renesas_usbhs/mod_gadget.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c 
> b/drivers/usb/renesas_usbhs/mod_gadget.c
> index 2d17c10..294d43c 100644
> --- a/drivers/usb/renesas_usbhs/mod_gadget.c
> +++ b/drivers/usb/renesas_usbhs/mod_gadget.c
> @@ -602,6 +602,9 @@ static int usbhsg_ep_disable(struct usb_ep *ep)
>   struct usbhsg_uep *uep = usbhsg_ep_to_uep(ep);
>   struct usbhs_pipe *pipe = usbhsg_uep_to_pipe(uep);
>  
> + if (!pipe)
> + return -EINVAL;
> +
>   usbhsg_pipe_disable(uep);
>   usbhs_pipe_free(pipe);
>  
> -- 
> 1.7.9.5
> 

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v7 1/7] usb: move the OTG state from the USB PHY to the OTG structure

[Felipe Balbi]

Hi,

On Fri, Oct 31, 2014 at 08:33:19AM -0500, Felipe Balbi wrote:
> > > > > > > > Before using the PHY framework instead of the USB PHY one, we 
> > > > > > > > need to
> > > > > > > > move the OTG state into another place, since it won't be 
> > > > > > > > available when
> > > > > > > > USB PHY isn't used. This patch moves the OTG state into the OTG
> > > > > > > > structure, and makes all the needed modifications in the drivers
> > > > > > > > using the OTG state.
> > > > > > > > 
> > > > > > > > Signed-off-by: Antoine Tenart 
> > > > > > > > 
> > > > > > > > Acked-by: Peter Chen 
> > > > > > > 
> > > > > > > Acked-by: Felipe Balbi 
> > > > > > 
> > > > > > Please rebase on my testing/next and I'll take the series. When
> > > > > > rebasing, then add Peter's Tested-by/Acked-by where they're missing.
> > > > > 
> > > > > I just re-sent the series, rebased on your testing/next branch.
> > > > 
> > > > Thanks, I put them on my testing/next and I'm running build tests.
> > > > 
> > > 
> > > I see them, I will rebase your testing/next tree for coming chipidea dev, 
> > > thanks.
> > 
> > I fixed a build breakage caused by $subject which I fixed, updated patch
> > below: (Aaro, can I get a tested-by by any chance ?)
> 
> two more build regressions found (did you build test your patches ??)

and yet another one on phy-isp1301-omap.c. Seriously, if I find another
build regression I'll drop your series from my queue and defer it to
3.20. This is ridiculous already.

8<

commit 5fd2f70ddea9102019cc9686d2b1eb88405ce235
Author: Antoine Tenart 
Date:   Thu Oct 30 18:41:13 2014 +0100

usb: move the OTG state from the USB PHY to the OTG structure

Before using the PHY framework instead of the USB PHY one, we need to
move the OTG state into another place, since it won't be available when
USB PHY isn't used. This patch moves the OTG state into the OTG
structure, and makes all the needed modifications in the drivers
using the OTG state.

[ ba...@ti.com : fix build regressions with phy-tahvo.c, musb_dsps.c,
phy-isp1301-omap, and chipidea's debug.c ]

Acked-by: Kishon Vijay Abraham I 
Acked-by: Peter Chen 
Signed-off-by: Antoine Tenart 
Signed-off-by: Felipe Balbi 

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 8c84298..9f409359 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -80,11 +80,9 @@ static int omap_usb_start_srp(struct usb_otg *otg)
 
 static int omap_usb_set_host(struct usb_otg *otg, struct usb_bus *host)
 {
-   struct usb_phy  *phy = otg->phy;
-
otg->host = host;
if (!host)
-   phy->state = OTG_STATE_UNDEFINED;
+   otg->state = OTG_STATE_UNDEFINED;
 
return 0;
 }
@@ -92,11 +90,9 @@ static int omap_usb_set_host(struct usb_otg *otg, struct 
usb_bus *host)
 static int omap_usb_set_peripheral(struct usb_otg *otg,
struct usb_gadget *gadget)
 {
-   struct usb_phy  *phy = otg->phy;
-
otg->gadget = gadget;
if (!gadget)
-   phy->state = OTG_STATE_UNDEFINED;
+   otg->state = OTG_STATE_UNDEFINED;
 
return 0;
 }
diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
index 795d653..f038804 100644
--- a/drivers/usb/chipidea/debug.c
+++ b/drivers/usb/chipidea/debug.c
@@ -220,7 +220,7 @@ static int ci_otg_show(struct seq_file *s, void *unused)
 
/* -- State - */
seq_printf(s, "OTG state: %s\n\n",
-   usb_otg_state_string(ci->transceiver->state));
+   usb_otg_state_string(ci->transceiver->otg->state));
 
/* -- State Machine Variables - */
seq_printf(s, "a_bus_drop: %d\n", fsm->a_bus_drop);
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index caaabc5..8cb2508 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -328,7 +328,7 @@ static void b_ssend_srp_tmout_func(void *ptr, unsigned long 
indicator)
set_tmout(ci, indicator);
 
/* only vbus fall below B_sess_vld in b_idle state */
-   if (ci->transceiver->state == OTG_STATE_B_IDLE)
+   if (ci->fsm.otg->state == OTG_STATE_B_IDLE)
ci_otg_queue_work(ci);
 }
 
@@ -582,11 +582,11 @@ int ci_otg_fsm_work(struct ci_hdrc *ci)
 * when there is no gadget class driver
 */
if (ci->fsm.id && !(ci->driver) &&
-   ci->transceiver->state < OTG_STATE_A_IDLE)
+   ci->fsm.otg->state < OTG_STATE_A_IDLE)
return 0;
 
if (otg_statemachine(&ci->fsm)) {
-   if (ci->transceiver->state == OTG_STATE_A_IDLE) {
+   if (ci->fsm.otg->state == OTG_STATE_A_IDLE) {
/*
 * Further state change for cases:
 * a_idle to b_idle; or
@@ -600,7 +600,7 @@

Re: [PATCH v7 1/2] usb: host: xhci-plat: Get PHYs for xhci's hcds

[Sergei Shtylyov]

Hello.

On 10/31/2014 4:26 PM, Vivek Gautam wrote:


The host controller by itself may sometimes need to handle PHY
and re-initialize it to re-configure some of the PHY parameters
to get full support out of the PHY controller.
Therefore, facilitate getting the two possible PHYs, viz.
USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3), and initialize them.



Signed-off-by: Vivek Gautam 
---
  drivers/usb/host/xhci-plat.c |   74 ++
  1 file changed, 74 insertions(+)



diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 3d78b0c..5207d5b 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c

[...]

@@ -129,10 +130,41 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_hcd;
}

+   /* Get possile USB 2.0 type PHY (UTMI+) available with xhci */
+   hcd->phy = devm_phy_get(&pdev->dev, "usb2-phy");
+   if (IS_ERR(hcd->phy)) {
+   ret = PTR_ERR(hcd->phy);
+   if (ret == -EPROBE_DEFER) {
+   goto disable_clk;
+   } else if (ret != -ENOSYS && ret != -ENODEV) {


   Asking to be a *switch* statement instead...


+   hcd->phy = NULL;
+   dev_warn(&pdev->dev,
+"Error retrieving usb2 phy: %d\n", ret);
+   }
+   }
+

[...]

@@ -158,12 +190,41 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
xhci->shared_hcd->can_do_streams = 1;

+   /* Get possile USB 3.0 type PHY (PIPE3) available with xhci */
+   xhci->shared_hcd->phy = devm_phy_get(&pdev->dev, "usb3-phy");
+   if (IS_ERR(xhci->shared_hcd->phy)) {
+   ret = PTR_ERR(xhci->shared_hcd->phy);
+   if (ret == -EPROBE_DEFER) {
+   goto put_usb3_hcd;
+   } else if (ret != -ENOSYS && ret != -ENODEV) {


   Likewise...


+   xhci->shared_hcd->phy = NULL;
+   dev_warn(&pdev->dev,
+"Error retrieving usb3 phy: %d\n", ret);
+   }
+   }
+

[...]

@@ -204,6 +271,8 @@ static int xhci_plat_suspend(struct device *dev)
struct usb_hcd  *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);

+   phy_exit(hcd->phy);


   Hm, in the suspend() method?


+
return xhci_suspend(xhci);
  }


[...]

WBR, Sergei

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

Re: [PATCHv6 1/8] usb: dwc2: Update the gadget driver to use common dwc2_hsotg structure

[Felipe Balbi]

On Fri, Oct 31, 2014 at 10:47:16AM +0800, Kever Yang wrote:
> Hi Dinh
> On 10/29/2014 07:25 AM, dingu...@opensource.altera.com wrote:
> >From: Dinh Nguyen 
> >
> >Adds the gadget data structure and appropriate data structure pointers
> >to the common dwc2_hsotg data structure. To keep the driver data
> >dereference code looking clean, the gadget variable declares are only 
> >available
> >for peripheral and dual-role mode. This is needed so that the dwc2_hsotg data
> >structure can be used by the hcd and gadget drivers.
> >
> >Updates gadget.c to use the dwc2_hsotg data structure and gadget pointers
> >that have been moved into the common dwc2_hsotg structure.
> Are we still need so much s3c prefix? Can we replace all the s3c into dwc2?

separate patch, one which you can send if it bothers you so much.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCHv6 6/8] usb: dwc2: gadget: Do not fail probe if there isn't a clock node

[Felipe Balbi]

On Fri, Oct 31, 2014 at 10:38:28AM +0800, Kever Yang wrote:
> Hi Dinh,
> 
> On 10/29/2014 07:25 AM, dingu...@opensource.altera.com wrote:
> >From: Dinh Nguyen 
> >
> >Since the dwc2 hcd driver is currently not looking for a clock node during
> >init, we should not completely fail if there isn't a clock provided.
> >For dual-role mode, we will only fail init for a non-clock node error. We
> >then update the HCD to only call gadget funtions if there is a proper clock
> >node.
> We have to add clock management for hcd, and I think it is better to
> do it before more Socs use this driver, isn't it?
> I have do something in my RFC patches, but I think I still do it in a wrong
> way.
> Can we just handle all the clock thing in platform?
> 
> Balbi suggested in my patch that we can "hide" clk_enable()/disable() under
> ->runtime_resume()/->runtime_suspend() and linux driver model.
> Can this be in platform driver?

it can and it probably should. Implement
->runtime_resume()/->runtime_suspend()/runtime_idle() in platform.c and
call pm_runtime_enable()/get()/put()/mark_last_busy()/autosuspend()
properly.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v7 1/7] usb: move the OTG state from the USB PHY to the OTG structure

[Antoine Tenart]

Hi Felipe,

On Fri, Oct 31, 2014 at 08:47:51AM -0500, Felipe Balbi wrote:
> On Fri, Oct 31, 2014 at 08:33:19AM -0500, Felipe Balbi wrote:
> > > > > > > > > Before using the PHY framework instead of the USB PHY one, we 
> > > > > > > > > need to
> > > > > > > > > move the OTG state into another place, since it won't be 
> > > > > > > > > available when
> > > > > > > > > USB PHY isn't used. This patch moves the OTG state into the 
> > > > > > > > > OTG
> > > > > > > > > structure, and makes all the needed modifications in the 
> > > > > > > > > drivers
> > > > > > > > > using the OTG state.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Antoine Tenart 
> > > > > > > > > 
> > > > > > > > > Acked-by: Peter Chen 
> > > > > > > > 
> > > > > > > > Acked-by: Felipe Balbi 
> > > > > > > 
> > > > > > > Please rebase on my testing/next and I'll take the series. When
> > > > > > > rebasing, then add Peter's Tested-by/Acked-by where they're 
> > > > > > > missing.
> > > > > > 
> > > > > > I just re-sent the series, rebased on your testing/next branch.
> > > > > 
> > > > > Thanks, I put them on my testing/next and I'm running build tests.
> > > > > 
> > > > 
> > > > I see them, I will rebase your testing/next tree for coming chipidea 
> > > > dev, thanks.
> > > 
> > > I fixed a build breakage caused by $subject which I fixed, updated patch
> > > below: (Aaro, can I get a tested-by by any chance ?)
> > 
> > two more build regressions found (did you build test your patches ??)
> 
> and yet another one on phy-isp1301-omap.c. Seriously, if I find another
> build regression I'll drop your series from my queue and defer it to
> 3.20. This is ridiculous already.

Sorry for the inconvenience, the series modify quite a lot of files and
testing all of them is quite difficult. If you'd like I can fully test
it and send a new version early next week.

Deferring it to 3.20 will not solve the issue and will raise the same
errors as these build failures. The series has been sent for quite a
long time now, without having any comments on the latests revisions and
was therefore delayed. Each time it is delayed, it makes it more
difficult to ensure everything is working fine because of all the
modifications done in this subsystem... I tried to keep it up with all
the other patches introduced between my revisions, but this is not as
easy as it sounds.

Again, sorry for these failures, I can send to you a new version early
next week so that no other patches comes in between, breaking the
build...


Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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: dwc2: add bus suspend/resume for dwc2

[Kever Yang]

This patch adds suspend/resume for dwc2 hcd controller.

Signed-off-by: Kever Yang 
---

 drivers/usb/dwc2/hcd.c | 74 ++
 1 file changed, 63 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index fa49c72..df68449 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1473,6 +1473,29 @@ static void dwc2_port_suspend(struct dwc2_hsotg *hsotg, 
u16 windex)
}
 }
 
+static void dwc2_port_resume(struct dwc2_hsotg *hsotg)
+{
+   u32 hprt0;
+
+   /* After clear the Stop PHY clock bit, we should wait for a moment
+* for PLL work stable with clock output.
+*/
+   writel(0, hsotg->regs + PCGCTL);
+   usleep_range(2000, 4000);
+
+   hprt0 = dwc2_read_hprt0(hsotg);
+   hprt0 |= HPRT0_RES;
+   writel(hprt0, hsotg->regs + HPRT0);
+   hprt0 &= ~HPRT0_SUSP;
+   /* according to USB2.0 Spec 7.1.7.7, the host most send the resume
+* signal for at least 20ms
+*/
+   usleep_range(2, 25000);
+
+   hprt0 &= ~HPRT0_RES;
+   writel(hprt0, hsotg->regs + HPRT0);
+}
+
 /* Handles hub class-specific requests */
 static int dwc2_hcd_hub_control(struct dwc2_hsotg *hsotg, u16 typereq,
u16 wvalue, u16 windex, char *buf, u16 wlength)
@@ -1518,17 +1541,7 @@ static int dwc2_hcd_hub_control(struct dwc2_hsotg 
*hsotg, u16 typereq,
case USB_PORT_FEAT_SUSPEND:
dev_dbg(hsotg->dev,
"ClearPortFeature USB_PORT_FEAT_SUSPEND\n");
-   writel(0, hsotg->regs + PCGCTL);
-   usleep_range(2, 4);
-
-   hprt0 = dwc2_read_hprt0(hsotg);
-   hprt0 |= HPRT0_RES;
-   writel(hprt0, hsotg->regs + HPRT0);
-   hprt0 &= ~HPRT0_SUSP;
-   usleep_range(10, 15);
-
-   hprt0 &= ~HPRT0_RES;
-   writel(hprt0, hsotg->regs + HPRT0);
+   dwc2_port_resume(hsotg);
break;
 
case USB_PORT_FEAT_POWER:
@@ -2301,6 +2314,42 @@ static void _dwc2_hcd_stop(struct usb_hcd *hcd)
usleep_range(1000, 3000);
 }
 
+static int _dwc2_hcd_suspend(struct usb_hcd *hcd)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+   u32 hprt0;
+
+   if (hsotg->op_state != OTG_STATE_B_HOST)
+   return 0;
+
+   if (hsotg->lx_state != DWC2_L0)
+   return 0;
+
+   hprt0 = dwc2_read_hprt0(hsotg);
+   if (hprt0 & HPRT0_CONNSTS)
+   dwc2_port_suspend(hsotg, 1);
+
+   return 0;
+}
+
+static int _dwc2_hcd_resume(struct usb_hcd *hcd)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+   u32 hprt0;
+
+   if (hsotg->op_state != OTG_STATE_B_HOST)
+   return 0;
+
+   if (hsotg->lx_state != DWC2_L2)
+   return 0;
+
+   hprt0 = dwc2_read_hprt0(hsotg);
+   if ((hprt0 | HPRT0_CONNSTS) && (hprt0 | HPRT0_SUSP))
+   dwc2_port_resume(hsotg);
+
+   return 0;
+}
+
 /* Returns the current frame number */
 static int _dwc2_hcd_get_frame_number(struct usb_hcd *hcd)
 {
@@ -2671,6 +2720,9 @@ static struct hc_driver dwc2_hc_driver = {
.hub_status_data = _dwc2_hcd_hub_status_data,
.hub_control = _dwc2_hcd_hub_control,
.clear_tt_buffer_complete = _dwc2_hcd_clear_tt_buffer_complete,
+
+   .bus_suspend = _dwc2_hcd_suspend,
+   .bus_resume = _dwc2_hcd_resume,
 };
 
 /*
-- 
1.9.1

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

Re: [PATCH v7 1/7] usb: move the OTG state from the USB PHY to the OTG structure

[Felipe Balbi]

Hi,

On Fri, Oct 31, 2014 at 02:55:35PM +0100, Antoine Tenart wrote:
> > > > > > > > > > Before using the PHY framework instead of the USB
> > > > > > > > > > PHY one, we need to move the OTG state into another
> > > > > > > > > > place, since it won't be available when USB PHY
> > > > > > > > > > isn't used. This patch moves the OTG state into the
> > > > > > > > > > OTG structure, and makes all the needed
> > > > > > > > > > modifications in the drivers using the OTG state.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Antoine Tenart 
> > > > > > > > > > 
> > > > > > > > > > Acked-by: Peter Chen 
> > > > > > > > > 
> > > > > > > > > Acked-by: Felipe Balbi 
> > > > > > > > 
> > > > > > > > Please rebase on my testing/next and I'll take the
> > > > > > > > series. When rebasing, then add Peter's
> > > > > > > > Tested-by/Acked-by where they're missing.
> > > > > > > 
> > > > > > > I just re-sent the series, rebased on your testing/next
> > > > > > > branch.
> > > > > > 
> > > > > > Thanks, I put them on my testing/next and I'm running build
> > > > > > tests.
> > > > > > 
> > > > > 
> > > > > I see them, I will rebase your testing/next tree for coming
> > > > > chipidea dev, thanks.
> > > > 
> > > > I fixed a build breakage caused by $subject which I fixed,
> > > > updated patch below: (Aaro, can I get a tested-by by any chance
> > > > ?)
> > > 
> > > two more build regressions found (did you build test your patches
> > > ??)
> > 
> > and yet another one on phy-isp1301-omap.c. Seriously, if I find
> > another build regression I'll drop your series from my queue and
> > defer it to 3.20. This is ridiculous already.
> 
> Sorry for the inconvenience, the series modify quite a lot of files
> and testing all of them is quite difficult. If you'd like I can fully
> test

how come ? build testing is difficult ? if you have x86 and ARM
compilers you can build all of these modules with make allmodconfig.

You know, I have a very a simple 20-line script running randconfigs and
saving the output, after that I just grep for "error" on the logs and
look at what's broken.

> it and send a new version early next week.
> 
> Deferring it to 3.20 will not solve the issue and will raise the same
> errors as these build failures. The series has been sent for quite a
> long time now, without having any comments on the latests revisions
> and was therefore delayed. Each time it is delayed, it makes it more
> difficult to ensure everything is working fine because of all the
> modifications done in this subsystem... I tried to keep it up with all
> the other patches introduced between my revisions, but this is not as
> easy as it sounds.

all the places I fixed haven't been touched for months, in some cases
years. This is a broken argument.

> Again, sorry for these failures, I can send to you a new version early
> next week so that no other patches comes in between, breaking the
> build...

nevermind, I already fixed so many of these mistakes anyway, it's
probably all clean now.

-- 
balbi


signature.asc
Description: Digital signature

Re: Question r/e zero byte bulk transfer on musb gadget (causes kernel panic)

[Alan Stern]

On Fri, 31 Oct 2014, Peter Stuge wrote:

> Breton M. Saunders wrote:
> > Are zero length transfers from a device to the PC on a bulk endpoint 
> > sensible?
> 
> I don't see how they could be.
> 
> If the device has no data to send it responds with a NAK handshake.
> 
> If the device has data to send it responds with the data.

But what if the host expects to receive data and the device has no data 
to send?  In that case the device must send a zero-length packet.  
Otherwise the host will hang, waiting for data that the device will 
never send.

This is required behavior, for example, during the data phase of a 
bulk-only mass-storage transfer.  The specification states that under 
certain circumstances, the device _must_ send a zero-length packet on 
its bulk-IN endpoint.

Alan Stern

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

Re: [PATCH 1/2] [usb] make xhci platform driver use 64 bit or 32 bit DMA

[Mark Langsdorf]

On 10/30/2014 04:05 PM, Arnd Bergmann wrote:

On Thursday 30 October 2014 15:09:33 Mark Langsdorf wrote:

On 10/30/2014 02:05 PM, Arnd Bergmann wrote:

On Thursday 30 October 2014 13:16:28 Mark Langsdorf wrote:

-   /* Initialize dma_mask and coherent_dma_mask to 32-bits */
-   ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
-   if (ret)
-   return ret;
+   /* Try setting the coherent_dma_mask to 64 bits, then try 32 bits */
+   if (sizeof(dma_addr_t) < 8 ||
+   dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
+   ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+   if (ret)
+   return ret;
+   }
  if (!pdev->dev.dma_mask)
  pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
  else
-   dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+   dma_set_mask(&pdev->dev, pdev->dev.coherent_dma_mask);

  hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
  if (!hcd)



The logic here seems wrong: if dma_set_mask is successful, you
can rely on on dma_set_coherent_mask suceeding as well, but
not the other way round.


That's the order in the existing driver. Would you prefer I
switch it to:
if (sizeof(dma_addr_t) < 8 ||
dma_set_mask(&pdev->dev, DMA_BIT_MASK(64))) {
ret = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
if (ret)
return ret;
}
dma_set_coherent_mask(&pdev->dev, pdev->dev.dma_mask);

or based on the comment below:
ret = dma_set_mask(&pdev->dev, pdev->dev.dma_mask);
if (ret)
return ret;
dma_set_coherent_mask(&pdev->dev, pdev->dev.dma_mask);

I prefer this version but I don't know if it would work.


You should not access pdev->dev.dma_mask here, that gets set
by the platform code. You should be able to just use
dma_set_mask_and_coherent to set both.


So:

if (sizeof(dma_addr_t) < 8 ||
dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64))) {
ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (ret)
return ret;
}

This doesn't actually work for me. I experimented a bit on the
hardware and I always fail if I don't set the coherent mask
first.


Also, we should no longer need to worry about the case where
pdev->dev.dma_mask is NULL, as this now gets initialized from
the DT setup.


I'm running this on a system with ACPI enabled and no DT. Does
that make a difference?


I don't know how the DMA mask gets initialized on ACPI, I assume it
doesn't at the moment, but that is something that should be fixed
in the ACPI code, not worked around in the driver.

You should definitely make sure that this also works with DT, as
I don't think it's possible to support X-Gene with ACPI. I know
that Al Stone has experimented with it in the past, but he never
came back with any results, so I assume the experiment failed.


I'm running my test code on an X-Gene with ACPI. Al Stone, Mark
Salter, and I got it working.

--Mark Langsdorf
--
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] usb: xhci: This reworks ff8cbf250b448aac35589f6075082c3fcad8a8fe

[Alan Stern]

On Fri, 31 Oct 2014, Lu Baolu wrote:

> xhci: clear root port wake on bits if controller isn't wake-up capable
> 
> When xHCI PCI host is suspended, if do_wakeup is false in xhci_pci_suspend,
> xhci_pci_suspend needs to clear all root port wake on bits. Otherwise some 
> Intel
> platforms may get a spurious wakeup, even if PCI PME# is disabled.
> 
> Signed-off-by: Lu Baolu 
> ---
>  drivers/usb/host/xhci-pci.c | 42 ++
>  drivers/usb/host/xhci.h |  6 ++
>  2 files changed, 48 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index 280dde9..3e7441a 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -27,6 +27,8 @@
>  #include "xhci.h"
>  #include "xhci-trace.h"
>  
> +#define  PORT_WAKE_BITS  (PORT_WKOC_E | PORT_WKDISC_E | PORT_WKCONN_E)
> +
>  /* Device for a quirk */
>  #define PCI_VENDOR_ID_FRESCO_LOGIC   0x1b73
>  #define PCI_DEVICE_ID_FRESCO_LOGIC_PDK   0x1000
> @@ -126,6 +128,7 @@ static void xhci_pci_quirks(struct device *dev, struct 
> xhci_hcd *xhci)
>*/
>   xhci->quirks |= XHCI_SPURIOUS_REBOOT;
>   xhci->quirks |= XHCI_AVOID_BEI;
> + xhci->quirks |= XHCI_DISABLE_PORT_WOB;
>   }
>   if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
>   (pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI ||
> @@ -279,6 +282,42 @@ static void xhci_pci_remove(struct pci_dev *dev)
>  }
>  
>  #ifdef CONFIG_PM
> +static void xhci_disable_port_wake_bits(struct xhci_hcd *xhci)
> +{
> + int port_index;
> + __le32 __iomem **port_array;
> + unsigned long flags;
> + u32 t1, t2;
> +
> + spin_lock_irqsave(&xhci->lock, flags);
> +
> + /* disble usb3 ports Wake bits*/
> + port_index = xhci->num_usb3_ports;
> + port_array = xhci->usb3_ports;
> + while (port_index--) {
> + t1 = readl(port_array[port_index]);
> + t2 = xhci_port_state_to_neutral(t1);
> + t2 &= ~PORT_WAKE_BITS;
> + t1 = xhci_port_state_to_neutral(t1);
> + if (t1 != t2)
> + writel(t2, port_array[port_index]);
> + }
> +
> + /* disble usb2 ports Wake bits*/
> + port_index = xhci->num_usb2_ports;
> + port_array = xhci->usb2_ports;
> + while (port_index--) {
> + t1 = readl(port_array[port_index]);
> + t2 = xhci_port_state_to_neutral(t1);
> + t2 &= ~PORT_WAKE_BITS;
> + t1 = xhci_port_state_to_neutral(t1);
> + if (t1 != t2)
> + writel(t2, port_array[port_index]);
> + }
> +
> + spin_unlock_irqrestore(&xhci->lock, flags);
> +}
> +
>  static int xhci_pci_suspend(struct usb_hcd *hcd, bool do_wakeup)
>  {
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> @@ -291,6 +330,9 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool 
> do_wakeup)
>   if (xhci->quirks & XHCI_COMP_MODE_QUIRK)
>   pdev->no_d3cold = true;
>  
> + if (xhci->quirks & XHCI_DISABLE_PORT_WOB && !do_wakeup)
> + xhci_disable_port_wake_bits(xhci);
> +
>   return xhci_suspend(xhci);
>  }

There are two things wrong here.  First, this should not be a quirk.  
The Wake-On bits should be disabled whenever they aren't needed, on 
every controller.

Second, this code (or something like it) belongs in xhci.c or 
xhci-hub.c, not xhci-pci.c.  This is because it should apply to all 
xHCI controllers, not just the PCI-based ones.

(In fact, instead of disabling the Wake-On bits when the controller is 
suspended and do_wakeup is 0, it probably would be better to leave them 
disabled normally and then _enable_ them if do_wakeup is 1.)

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: USB3: unable to enumerate, device not accepting address

[Alan Stern]

On Thu, 30 Oct 2014, parafin wrote:

> Hi,
> 
> I have 2 very similar USB3 devices that stopped working sometime after
> kernel version 3.3 - they fail to enumerate unless I reload xhci_hcd
> driver.

> I managed to bisect this down to this commit:
> beabe20445c60322719d8f58e9eb9dd4660c1b3e
> (it's from 3.4 branch, included in 3.4.36 release, upstream commit id
> from commit message seems to be invalid, at least it's missing one
> character).

Speaking as an onlooker -- I don't know what's going wrong here --
don't you think your email should have been sent to the author of that
commit as well as posted on the mailing list?  After all, the author is
the person most familiar with what it does and how it's supposed to
work.

Alan Stern

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

Re: [PATCH usb v3 00/29] cleanup and fixes on resource check

[Sergei Shtylyov]

Hello.

On 10/31/2014 4:14 AM, Varka Bhadram wrote:


This series removes the duplication of sanity check for
platform_get_resource() return resource. It will be checked
with devm_ioremap_resource()



This entire series rebased on testing/fixes of [1].



[1]: http://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git




changes since v1:
- removed broken patches
- added Ack of Alan Stern for all the ehci, ohci, and uhci changes.
changes since v2:
- addressed Sergei Shtylyov comments



Varka Bhadram (29):
   host: ehci-atmel: remove duplicate check on resource
   host: ohci-da8xx: remove duplicate check on resource
   host: ehci-tegra: remove duplicate check on resource
   host: ehci-w90x900: remove duplicate check on resource
   host: ohci-at91: remove duplicate check on resource
   host: ohci-exynos: remove duplicate check on resource
   host: ohci-jz4740: remove duplicate check on resource
   host: ohci-octeon: remove duplicate check on resource
   host: ohci-platform: remove duplicate check on resource
   host: ohci-pxa27x: remove duplicate check on resource
   host: ehci-sh: remove duplicate check on resource
   host: ohci-spear: remove duplicate check on resource
   host: ehci-msm: remove duplicate check on resource
   host: ehci-mv: remove duplicate check on resource
   host: ehci-mxc: remove duplicate check on resource
   host: ehci-octeon: remove duplicate check on resource
   host: ehci-orion: remove duplicate check on resource
   host: ehci-platform: remove duplicate check on resource
   host: ehci-sead3: fix NULL pointer dereference on resource



   Mixing fixes and cleanups in one series is not a good idea, generally 
speaking.



   host: ehci-spear: remove duplicate check on resource
   host: uhci-platform: fix NULL pointer dereference on resource
   host: xhci-plat: remove duplicate check on resource
   musb: musb_core: remove duplicate check on resource
   musb: musb_dsps: remove duplicate check on resource
   phy: phy-rcar-usb: remove duplicate check on resource
   renesas_usbhs: common: remove duplicate check on resource
   dwc3: dwc3-keystone: remove duplicate check on resource
   host: ehci-fsl: remove duplicate check on resource
   host: ehci-exynos: remove duplicate check on resource


[...]

WBR, Sergei

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

Re: usb: gadget: f_uac1: convert to new function interface with backward compatibility

[Andrzej Pietrasiewicz]

Hello Dan,

Thanks for this check.

W dniu 31.10.2014 o 14:06, Dan Carpenter pisze:

Hello Andrzej Pietrasiewicz,

This is a semi-automatic email about new static checker warnings.







drivers/usb/gadget/function/u_uac1.c
210 
211 opts = container_of(card->func.fi, struct f_uac1_opts, 
func_inst);
 ^
New dereference.

212 fn_play = opts->fn_play;
   ^
Technically, I think the container_of() just does pointer math and the
actual dereference is here.  I'm not sure, either way it's dereferenced.

213 fn_cap = opts->fn_cap;
214 fn_cntl = opts->fn_cntl;
215 
216 if (!card)
 ^
Existing code assumes card can be NULL.



gaudio_open_snd_dev() is called from gaudio_setup(), which is called
when this function instance is first bound and the card parameter
is propagated from f_audio_bind().

In f_audio_bind() the audio local variable is dereferenced to get
the "card". audio itself is a container_of struct usb_function
and also contains struct gaudio (as a regular member, not a pointer).
So if the said usb_function is non-NULL, its container's "card" member
is non-NULL either.

The struct usb_function is passed from composite.c:usb_add_function()
where it is assumed to be non-NULL. This means that the check in line 216
is not needed.

Actually in the circulation there has been your patch:

5d5515f389a0db9da5ee85481a5939508aa31dec
usb: gadget: f_uac1: remove an unneeded NULL check

which implements exactly what I described above.

AP

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

Re: USB3: unable to enumerate, device not accepting address

[parafin]

I assumed Sarah reads this mailing list (she replied here sometime ago
when I posted about another issue), but OK, I will forward my email to
her directly as well.
P.S.
I also cross-posted this to this bug which seems to be at least related:
https://bugzilla.kernel.org/show_bug.cgi?id=41752

On Fri, 31 Oct 2014 10:30:52 -0400 (EDT)
Alan Stern  wrote:

> On Thu, 30 Oct 2014, parafin wrote:
> 
> > Hi,
> > 
> > I have 2 very similar USB3 devices that stopped working sometime after
> > kernel version 3.3 - they fail to enumerate unless I reload xhci_hcd
> > driver.
> 
> > I managed to bisect this down to this commit:
> > beabe20445c60322719d8f58e9eb9dd4660c1b3e
> > (it's from 3.4 branch, included in 3.4.36 release, upstream commit id
> > from commit message seems to be invalid, at least it's missing one
> > character).
> 
> Speaking as an onlooker -- I don't know what's going wrong here --
> don't you think your email should have been sent to the author of that
> commit as well as posted on the mailing list?  After all, the author is
> the person most familiar with what it does and how it's supposed to
> work.
> 
> 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: [PATCHv6 2/8] usb: dwc2: Move gadget probe function into platform code

[Dinh Nguyen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/30/2014 08:57 AM, Felipe Balbi wrote:
> On Tue, Oct 28, 2014 at 06:25:43PM -0500,
> dingu...@opensource.altera.com wrote:
>> From: Dinh Nguyen 
>> 
>> This patch will aggregate the probing of gadget/hcd driver into
>> platform.c. The gadget probe funtion is converted into
>> gadget_init that is now only responsible for gadget only
>> initialization. All the gadget resources is now
> 
> s/resources is/resources are
> 
>> handled by platform.c
>> 
>> Since the host workqueue will not get initialized if the driver
>> is configured for peripheral mode only. Thus we need to check for
>> wq_otg before calling queue_work().
> 
> this period character in the middle of the sentence doesn't make
> sense, perhaps a comma is what you want ? The sentence can be
> improved too:
> 
> "Since the host workqueue will not get initialized if the drier is 
> configured for peripheral mode only, we add a check for wq_otg
> before calling queue_work()."
> 
>> Also, we move spin_lock_init to common location for both host and
>> gadget that is either in platform.c or pci.c.
>> 
>> We also ove suspend/resume code to common platform code, and
>> update it to use the new PM API (struct dev_pm_ops).
> 
> updating to dev_pm_ops should really be a separate patch.
> 

All fixed...

Thanks,
Dinh
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUU6PAAAoJEBmUBAuBoyj0KJUP/RWpP9YkctpmZQgrb2xq0JaG
eLCpOnKVYaTBCAhydJOKBBx0odYyxORlxTWbJCbZPvPhrZ7NDTINqEVWJOqYmtqe
Xl8aEPYm+ckcfTliONK3yIP/MA49he/qbGOmqXFwFMbcAvKFN/kpq05cjzZ6T8bO
hILDO2Yy2HVQHonq3uKppmTB9DSnCNfCR0Cuum2fpOzmVLY/X46EM5UD2e+XmVgo
dsINAGe40FwFIoLZzAradn12MrmCjOM6MPpkkGZ3SMGjKXY7yQX38c9WbcCvsm6g
y1/5fDqdRlsq+Weoo9N3H03LUX8MlGCpZ7dgLrABXMEjdySj3eVTj4bHgPxRjRY/
+SfI2YR8RyEcHj2UTqgMUp4JmRl2CNiB9fsvZHMQQm2MTeFkcUpZnSUXWHB9Vtwv
s1I5nMOSoT2NDBg6QS9a1T1s1gdSywOnDBd+/SK7mf4QkQumvf2Nvu6avQB1Rxxm
sqpGWztuhuycg332CXc9W0EBXcg5t8SRyk9SFgksH3MezS85gAQxZtXyv44NuCUM
ciTru8tKh3ncszws2NmX9yyQgC4fM3kHDytOwDXFt23f3xHyjg+2m3O1TLErAwig
yqj2MfYTfqfYVrs/hOvOpEbUgUSy5MQY/EOMIsI6aGfB2Nba72wrYQP79ugb84u9
Ftd1XH47lvXX/R8VOV2x
=ZAkf
-END PGP SIGNATURE-
--
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: [PATCHv6 4/8] usb: dwc2: Update common interrupt handler to call gadget interrupt handler

[Dinh Nguyen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/30/2014 09:00 AM, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Oct 28, 2014 at 06:25:45PM -0500,
> dingu...@opensource.altera.com wrote:
>> From: Dinh Nguyen 
>> 
>> Make dwc2_handle_common_intr call the gadget interrupt function
>> when operating in peripheral mode. Remove the spinlock functions
>> in s3c_hsotg_irq as dwc2_handle_common_intr() already has the
>> spinlocks.
>> 
>> Move the registeration of the IRQ to common code for platform and
>> PCI.
>> 
>> Remove duplicate interrupt conditions that was in gadget, as
>> those are handled by dwc2 common interrupt handler.
>> 
>> Signed-off-by: Dinh Nguyen  
>> Acked-by: Paul Zimmerman  --- v5: remove
>> individual devm_request_irq from gadget and hcd, and place a 
>> single devm_request_irq in platform and pci. v2: Keep interrupt
>> handler for host and peripheral modes separate --- 
>> drivers/usb/dwc2/core.c  | 10  
>> drivers/usb/dwc2/core.h  |  3 +++ 
>> drivers/usb/dwc2/core_intr.c |  3 +++ drivers/usb/dwc2/gadget.c
>> | 57 ++-- 
>> drivers/usb/dwc2/pci.c   |  6 + 
>> drivers/usb/dwc2/platform.c  |  9 +++ 6 files changed, 23
>> insertions(+), 65 deletions(-)
>> 
>> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c 
>> index d926945..7605850b 100644 --- a/drivers/usb/dwc2/core.c +++
>> b/drivers/usb/dwc2/core.c @@ -458,16 +458,6 @@ int
>> dwc2_core_init(struct dwc2_hsotg *hsotg, bool select_phy, int
>> irq) /* Clear the SRP success bit for FS-I2c */ 
>> hsotg->srp_success = 0;
>> 
>> -if (irq >= 0) { -   dev_dbg(hsotg->dev, "registering common
>> handler for irq%d\n", -  irq); - retval =
>> devm_request_irq(hsotg->dev, irq, -
>> dwc2_handle_common_intr, IRQF_SHARED, -
>> dev_name(hsotg->dev), hsotg); -  if (retval) -   
>> return retval; -
>> } - /* Enable common interrupts */ 
>> dwc2_enable_common_interrupts(hsotg);
>> 
>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h 
>> index 80d29c7..ec70862 100644 --- a/drivers/usb/dwc2/core.h +++
>> b/drivers/usb/dwc2/core.h @@ -967,6 +967,7 @@ extern int
>> s3c_hsotg_suspend(struct dwc2_hsotg *dwc2); extern int
>> s3c_hsotg_resume(struct dwc2_hsotg *dwc2); extern int
>> dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq); extern void
>> s3c_hsotg_core_init(struct dwc2_hsotg *dwc2); +irqreturn_t
>> s3c_hsotg_irq(int irq, void *pw); #else static inline int
>> s3c_hsotg_remove(struct dwc2_hsotg *dwc2) { return 0; } @@ -977,6
>> +978,8 @@ static inline int s3c_hsotg_resume(struct dwc2_hsotg
>> *dwc2) static inline int dwc2_gadget_init(struct dwc2_hsotg
>> *hsotg, int irq) { return 0; } static inline void
>> s3c_hsotg_core_init(struct dwc2_hsotg *dwc2) {} +static inline
>> irqreturn_t s3c_hsotg_irq(int irq, void *pw) +{ return
>> IRQ_HANDLED; } #endif
>> 
>> #if IS_ENABLED(CONFIG_USB_DWC2_HOST) ||
>> IS_ENABLED(CONFIG_USB_DWC2_DUAL_ROLE) diff --git
>> a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c 
>> index b176c2f..b0c14e0 100644 --- a/drivers/usb/dwc2/core_intr.c 
>> +++ b/drivers/usb/dwc2/core_intr.c @@ -474,6 +474,9 @@
>> irqreturn_t dwc2_handle_common_intr(int irq, void *dev)
>> 
>> spin_lock(&hsotg->lock);
>> 
>> +if (dwc2_is_device_mode(hsotg)) +   retval = 
>> s3c_hsotg_irq(irq,
>> dev); + gintsts = dwc2_read_common_intr(hsotg); if (gintsts &
>> ~GINTSTS_PRTINT) retval = IRQ_HANDLED; diff --git
>> a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index
>> 19d1b03..202f8cc 100644 --- a/drivers/usb/dwc2/gadget.c +++
>> b/drivers/usb/dwc2/gadget.c @@ -2257,14 +2257,13 @@ void
>> s3c_hsotg_core_init(struct dwc2_hsotg *hsotg) * @irq: The IRQ
>> number triggered * @pw: The pw value when registered the
>> handler. */ -static irqreturn_t s3c_hsotg_irq(int irq, void *pw) 
>> +irqreturn_t s3c_hsotg_irq(int irq, void *pw)
> 
> why ? It would've been a lot easier to just make the IRQ line
> shared.
> 

Reworked to use IRQF_SHARED...

Thanks,
Dinh
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUU6P5AAoJEBmUBAuBoyj0vWwP/1Qq0Gt9U1MF6LHJU853+P+I
jx6xVVanPSuK8yTWprh7M/endv+UkVwwt+2sGZ0MMzLDH1T7Kf6FdqhjlNqvFeRK
qK5LUkpMKvMJKcw6tQNGsjB75X93GRkWLxuZEQ9BpGjfy1fct6Wic/kv66dUVCCI
DevfZZFPGdSmiichVup0sO/cfTJ84R8xyQVuF77LvZ/Wbm606ypV4PTMEjKcFhmr
5s6BeOINm7p1NMuoDaWbmjjOHAfTwy06W3p81LMsWH5yfVCq4TgJSwMbdo8s/i/Y
po/1Nu0x5lwwao1J2OZA7b30i1vbtztCzVPtFcO5quN9rOlsaXRNBGLf9jjHP1OO
PzRSsh1EbAinc4Ohbnii/bdx2g7lWP2ktf5qqoeVocgZkrKA/k5w/QK1qL1z3Onl
ZkylCf5VMd06eOkeGbdce8UFhbceNLw0ryqAVN0bsxiD0u78aH6KvhYhBo29p/1R
VMlKPrsYVDp9xjsp24S/u7o4NvNx8VeIfaKA5JN0Hnzncy03ByaO/o5iMPLb231l
/yCoVyt2A9q7LQs/HeyCZYOFAPpG8ZbTsZrucKB9rRWXizDIrpIfJdcH3mIp71ab
fhhf8sE1kDMrqADLTd1UL96DKCJnU2N8qJLSll6uWNi95J6OogIkj+H4YFPXXWiM
+wUVqVAyYzPKsCaMRNTF
=5+gL
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majo

Re: [PATCHv6 5/8] usb: dwc2: Add call_gadget functions for perpheral mode interrupts

[Dinh Nguyen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/30/2014 09:01 AM, Felipe Balbi wrote:
> On Tue, Oct 28, 2014 at 06:25:46PM -0500,
> dingu...@opensource.altera.com wrote:
>> From: Dinh Nguyen 
>> 
>> Update the dwc2 wakeup and suspend interrupt functions to use
>> call_gadget when the IP is in peripheral mode.
> 
> it seems like you're actually fixing a bug here. Those calls
> weren't there before.
> 

This patch can be sent separately from this series.

Thanks,
Dinh
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUU6QzAAoJEBmUBAuBoyj0XpIQAKLQxsksyfEBAOWNwapO1Grx
jMK9+QpqZuGwo5Gha905iAO1Q/XP5tHvkLBzGyeEpNhEqBWXTTAvu1i2EToSiNId
JTtae/eJA5xfxoljULqL3Vuy1SfOt+EdBHoMdn/vQQfBp9kUiqfJNgZeUsDgvbBK
7xNfdocMQjqPPbseNGL3193aasOFyZdc9sI+ZR3XjeXjNPgzwJzfB9eMZH+zpRKU
nVcWY5UBkw05UnvDNwc4e/+VNpBRj4NLBBLGPleUJ1KXyunUet5r4oCLYLasZaFn
zk6VvovQMUDk9DhnK2d8w6oosmSA/eD8zKn3K3++LV/XGwb5rHP+zC5jpAkbjN/o
4ZudegACKNUiwvo0tfbgtI5no/VzlaArSM6n3WT6Fz5cDveibZbU7z78AqIqRkwF
Ai4+bn510OCgfEEu2rVRXl21r/TAt9r3ujh1mPPUwJ+nWdoxjmm7+0MyKNSeB/Ab
MmVZfQaELLGTOMHH0T0/yr6XX8Bc4LxGtbjVQRlmW7mYfafnzhE+aWAeLnyF4V9r
cA0YE09jOQoXh8WU6k18SKbapF8HDaXSLBcTWnXBR93TQu4U05qx5iB8hEZ7S9NT
z3uQdfgjk8LjhaYWTtSsT29E6oDbvho8h5TF48KiwN4Ud0wagqJq1W3vlGhrgKUd
wy94/mOPpifATM0S4KUr
=qCZw
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: gadget: f_uac1: convert to new function interface with backward compatibility

[Dan Carpenter]

Oops.  Sorry.  I forgot that I sent a patch for this.

regards,
dan carpenter

--
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: [PATCHv6 1/8] usb: dwc2: Update the gadget driver to use common dwc2_hsotg structure

[Dinh Nguyen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/30/2014 08:54 AM, Felipe Balbi wrote:
> On Tue, Oct 28, 2014 at 06:25:42PM -0500,
> dingu...@opensource.altera.com wrote:
>> From: Dinh Nguyen 
>> 
>> Adds the gadget data structure and appropriate data structure
>> pointers to the common dwc2_hsotg data structure. To keep the
>> driver data dereference code looking clean, the gadget variable
>> declares are only available for peripheral and dual-role mode.
>> This is needed so that the dwc2_hsotg data structure can be used
>> by the hcd and gadget drivers.
>> 
>> Updates gadget.c to use the dwc2_hsotg data structure and gadget
>> pointers that have been moved into the common dwc2_hsotg
>> structure.
>> 
>> Signed-off-by: Dinh Nguyen  
>> Signed-off-by: Paul Zimmerman  --- v5: Keep
>> the changes to mininum and maintain hcd and gadget driver to
>> build and work separately. Use IS_ENABLED() instead of #if
>> defined v3: Updated with paulz's suggestion to avoid double
>> pointers. v2: Left the function parameter name as 'hsotg' and
>> just changed its type. --- drivers/usb/dwc2/core.h   | 156
>> -- 
>> drivers/usb/dwc2/gadget.c | 145
>> +- 2 files changed, 154
>> insertions(+), 147 deletions(-)
>> 
>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h 
>> index 55c90c5..96c283d 100644 --- a/drivers/usb/dwc2/core.h +++
>> b/drivers/usb/dwc2/core.h @@ -84,7 +84,7 @@ static const char *
>> const s3c_hsotg_supply_names[] = { */ #define EP0_MPS_LIMIT   64
>> 
>> -struct s3c_hsotg; +struct dwc2_hsotg; struct s3c_hsotg_req;
>> 
>> /** @@ -130,7 +130,7 @@ struct s3c_hsotg_req; struct s3c_hsotg_ep
>> { struct usb_ep   ep; struct list_headqueue; -
>> struct s3c_hsotg*parent; +   struct dwc2_hsotg
>> *parent; struct s3c_hsotg_req*req; struct dentry
>> *debugfs;
>> 
>> @@ -155,67 +155,6 @@ struct s3c_hsotg_ep { };
>> 
>> /** - * struct s3c_hsotg - driver state. - * @dev: The parent
>> device supplied to the probe function - * @driver: USB gadget
>> driver - * @phy: The otg phy transceiver structure for phy
>> control. - * @uphy: The otg phy transceiver structure for old USB
>> phy control. - * @plat: The platform specific configuration data.
>> This can be removed once - * all SoCs support usb transceiver. -
>> * @regs: The memory area mapped for accessing registers. - *
>> @irq: The IRQ number we are using - * @supplies: Definition of
>> USB power supplies - * @phyif: PHY interface width - *
>> @dedicated_fifos: Set if the hardware has dedicated IN-EP fifos. 
>> - * @num_of_eps: Number of available EPs (excluding EP0) - *
>> @debug_root: root directrory for debugfs. - * @debug_file: main
>> status file for debugfs. - * @debug_fifo: FIFO status file for
>> debugfs. - * @ep0_reply: Request used for ep0 reply. - *
>> @ep0_buff: Buffer for EP0 reply data, if needed. - * @ctrl_buff:
>> Buffer for EP0 control requests. - * @ctrl_req: Request for EP0
>> control packets. - * @setup: NAK management for EP0 SETUP - *
>> @last_rst: Time of last reset - * @eps: The endpoints being
>> supplied to the gadget framework - */ -struct s3c_hsotg { -
>> struct device*dev; - struct usb_gadget_driver
>> *driver; -   struct phy   *phy; -struct usb_phy
>> *uphy; - struct s3c_hsotg_plat*plat; - - spinlock_t
>> lock; - -void __iomem*regs; -int
>> irq; -   struct clk  *clk; - -   struct
>> regulator_bulk_data
>> supplies[ARRAY_SIZE(s3c_hsotg_supply_names)]; - -u32
>> phyif; - int fifo_mem; - unsigned int
>> dedicated_fifos:1; - unsigned char   num_of_eps; -   u32
>> fifo_map; - -struct dentry   *debug_root; -  struct
>> dentry   *debug_file; -  struct dentry
>> *debug_fifo; - - struct usb_request  *ep0_reply; -   struct
>> usb_request  *ctrl_req; -u8
>> ep0_buff[8]; -   u8  ctrl_buff[8]; - -   struct
>> usb_gadget   gadget; -   unsigned intsetup; -
>> unsigned long   last_rst; -  struct s3c_hsotg_ep
>> *eps; -}; - -/** * struct s3c_hsotg_req - data transfer request *
>> @req: The USB gadget request * @queue: The list of requests for
>> the endpoint this is queued for. @@ -229,6 +168,7 @@ struct
>> s3c_hsotg_req { unsigned char   mapped; };
>> 
>> +#if IS_ENABLED(CONFIG_USB_DWC2_PERIPHERAL) ||
>> IS_ENABLED(CONFIG_USB_DWC2_DUAL_ROLE) #define call_gadget(_hs,
>> _entry) \ do { \ if ((_hs)->gadget.speed != USB_SPEED_UNKNOWN &&
>> \ @@ -238,6 +178,9 @@ do { \ spin_lock(&_hs->lock); \ } \ } while
>> (0) +#else +#define call_gadget(_hs, _entry) do {} while (0) 
>> +#endif
>> 
>> struct dwc2_hsotg; struct dwc2_host_chan; @@ -495,11 +438,13 @@
>> struct dwc2_hw_params { * struct dwc2_hsotg - Holds the state of
>> the driver, including the non-periodic * and periodic schedules 
>> * + * These a

Re: [PATCHv6 6/8] usb: dwc2: gadget: Do not fail probe if there isn't a clock node

[Dinh Nguyen]

On 10/30/2014 09:04 AM, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Oct 28, 2014 at 06:25:47PM -0500, dingu...@opensource.altera.com 
> wrote:
>> From: Dinh Nguyen 
>>
>> Since the dwc2 hcd driver is currently not looking for a clock node during
>> init, we should not completely fail if there isn't a clock provided.
>> For dual-role mode, we will only fail init for a non-clock node error. We
>> then update the HCD to only call gadget funtions if there is a proper clock
>> node.
>>
>> Signed-off-by: Dinh Nguyen 
>> ---
>> v5: reworked to not access gadget functions from the hcd.
>> ---
>>  drivers/usb/dwc2/core.h  |  3 +--
>>  drivers/usb/dwc2/core_intr.c |  9 ++---
>>  drivers/usb/dwc2/hcd.c   |  3 ++-
>>  drivers/usb/dwc2/platform.c  | 19 +++
>>  4 files changed, 24 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
>> index ec70862..48120c8 100644
>> --- a/drivers/usb/dwc2/core.h
>> +++ b/drivers/usb/dwc2/core.h
>> @@ -660,6 +660,7 @@ struct dwc2_hsotg {
>>  #endif
>>  #endif /* CONFIG_USB_DWC2_HOST || CONFIG_USB_DWC2_DUAL_ROLE */
>>  
>> +struct clk *clk;
>>  #if IS_ENABLED(CONFIG_USB_DWC2_PERIPHERAL) || 
>> IS_ENABLED(CONFIG_USB_DWC2_DUAL_ROLE)
>>  /* Gadget structures */
>>  struct usb_gadget_driver *driver;
>> @@ -667,8 +668,6 @@ struct dwc2_hsotg {
>>  struct usb_phy *uphy;
>>  struct s3c_hsotg_plat *plat;
>>  
>> -struct clk *clk;
>> -
>>  struct regulator_bulk_data supplies[ARRAY_SIZE(s3c_hsotg_supply_names)];
>>  
>>  u32 phyif;
>> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
>> index 1240875..1608037 100644
>> --- a/drivers/usb/dwc2/core_intr.c
>> +++ b/drivers/usb/dwc2/core_intr.c
>> @@ -339,7 +339,8 @@ static void dwc2_handle_wakeup_detected_intr(struct 
>> dwc2_hsotg *hsotg)
>>  }
>>  /* Change to L0 state */
>>  hsotg->lx_state = DWC2_L0;
>> -call_gadget(hsotg, resume);
>> +if (!IS_ERR(hsotg->clk))
>> +call_gadget(hsotg, resume);
> 
> instead of exposing the clock detail to the entire driver, add IS_ERR()
> checks to resume and suspend instead. In fact, NULL is a valid clock, so
> you might as well:
> 
>   clk = clk_get(foo, bar);
>   if (IS_ERR(clk))
>   dwc->clk = NULL;
>   else
>   dwc->clk = clk;
> 
> Then you don't need any IS_ERR() checks sprinkled around the driver.

But we would still need to check for the clock before accessing gadget
functionality right?

if (dwc2->clk)
call_gadget();

> 
>> @@ -400,7 +401,8 @@ static void dwc2_handle_usb_suspend_intr(struct 
>> dwc2_hsotg *hsotg)
>>  "DSTS.Suspend Status=%d HWCFG4.Power Optimize=%d\n",
>>  !!(dsts & DSTS_SUSPSTS),
>>  hsotg->hw_params.power_optimized);
>> -call_gadget(hsotg, suspend);
>> +if (!IS_ERR(hsotg->clk))
>> +call_gadget(hsotg, suspend);
>>  } else {
>>  if (hsotg->op_state == OTG_STATE_A_PERIPHERAL) {
>>  dev_dbg(hsotg->dev, "a_peripheral->a_host\n");
>> @@ -477,7 +479,8 @@ irqreturn_t dwc2_handle_common_intr(int irq, void *dev)
>>  spin_lock(&hsotg->lock);
>>  
>>  if (dwc2_is_device_mode(hsotg))
>> -retval = s3c_hsotg_irq(irq, dev);
>> +if (!IS_ERR(hsotg->clk))
>> +retval = s3c_hsotg_irq(irq, dev);
> 
> wait a minute, if there is no clock we don't call the gadget interrupt
> handler ? Why ? Who will disable the IRQ line ?

This portion is no longer needed when I use shared IRQ lines.

> 
>> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
>> index 44c609f..fa49c72 100644
>> --- a/drivers/usb/dwc2/hcd.c
>> +++ b/drivers/usb/dwc2/hcd.c
>> @@ -1371,7 +1371,8 @@ static void dwc2_conn_id_status_change(struct 
>> work_struct *work)
>>  hsotg->op_state = OTG_STATE_B_PERIPHERAL;
>>  dwc2_core_init(hsotg, false, -1);
>>  dwc2_enable_global_interrupts(hsotg);
>> -s3c_hsotg_core_init(hsotg);
>> +if (!IS_ERR(hsotg->clk))
>> +s3c_hsotg_core_init(hsotg);
>>  } else {
>>  /* A-Device connector (Host Mode) */
>>  dev_dbg(hsotg->dev, "connId A\n");
>> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
>> index 72f32f7..77c8417 100644
>> --- a/drivers/usb/dwc2/platform.c
>> +++ b/drivers/usb/dwc2/platform.c
>> @@ -217,8 +217,17 @@ static int dwc2_driver_probe(struct platform_device 
>> *dev)
>>  
>>  spin_lock_init(&hsotg->lock);
>>  retval = dwc2_gadget_init(hsotg, irq);
>> -if (retval)
>> -return retval;
>> +if (retval) {
>> +/*
>> + * We will not fail the driver initialization for dual-role
>> + * if no clock node is supplied. However, all gadget
>> + * functionality 

Re: [PATCH] usb: dwc2: add bus suspend/resume for dwc2

[Romain Perier]

Hi Kever,

2014-10-31 15:02 GMT+01:00 Kever Yang :
> This patch adds suspend/resume for dwc2 hcd controller.
>

Could you add a more explicit and detailed message ? It is redundant
with the commit subject and explains almost the same thing.

> Signed-off-by: Kever Yang 
> ---
>
>  drivers/usb/dwc2/hcd.c | 74 
> ++
>  1 file changed, 63 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index fa49c72..df68449 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -1473,6 +1473,29 @@ static void dwc2_port_suspend(struct dwc2_hsotg 
> *hsotg, u16 windex)
> }
>  }
>
> +static void dwc2_port_resume(struct dwc2_hsotg *hsotg)
> +{
> +   u32 hprt0;
> +
> +   /* After clear the Stop PHY clock bit, we should wait for a moment
> +* for PLL work stable with clock output.
> +*/
> +   writel(0, hsotg->regs + PCGCTL);
> +   usleep_range(2000, 4000);
> +
> +   hprt0 = dwc2_read_hprt0(hsotg);
> +   hprt0 |= HPRT0_RES;
> +   writel(hprt0, hsotg->regs + HPRT0);
> +   hprt0 &= ~HPRT0_SUSP;
> +   /* according to USB2.0 Spec 7.1.7.7, the host most send the resume
> +* signal for at least 20ms
> +*/

Typo here, most => must .

> +   usleep_range(2, 25000);
> +
> +   hprt0 &= ~HPRT0_RES;
> +   writel(hprt0, hsotg->regs + HPRT0);
> +}
> +
>  /* Handles hub class-specific requests */
>  static int dwc2_hcd_hub_control(struct dwc2_hsotg *hsotg, u16 typereq,
> u16 wvalue, u16 windex, char *buf, u16 
> wlength)
> @@ -1518,17 +1541,7 @@ static int dwc2_hcd_hub_control(struct dwc2_hsotg 
> *hsotg, u16 typereq,
> case USB_PORT_FEAT_SUSPEND:
> dev_dbg(hsotg->dev,
> "ClearPortFeature USB_PORT_FEAT_SUSPEND\n");
> -   writel(0, hsotg->regs + PCGCTL);
> -   usleep_range(2, 4);
> -
> -   hprt0 = dwc2_read_hprt0(hsotg);
> -   hprt0 |= HPRT0_RES;
> -   writel(hprt0, hsotg->regs + HPRT0);
> -   hprt0 &= ~HPRT0_SUSP;
> -   usleep_range(10, 15);
> -
> -   hprt0 &= ~HPRT0_RES;
> -   writel(hprt0, hsotg->regs + HPRT0);
> +   dwc2_port_resume(hsotg);
> break;
>
> case USB_PORT_FEAT_POWER:
> @@ -2301,6 +2314,42 @@ static void _dwc2_hcd_stop(struct usb_hcd *hcd)
> usleep_range(1000, 3000);
>  }
>
> +static int _dwc2_hcd_suspend(struct usb_hcd *hcd)
> +{
> +   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
> +   u32 hprt0;
> +
> +   if (hsotg->op_state != OTG_STATE_B_HOST)
> +   return 0;
> +
> +   if (hsotg->lx_state != DWC2_L0)
> +   return 0;
> +
> +   hprt0 = dwc2_read_hprt0(hsotg);
> +   if (hprt0 & HPRT0_CONNSTS)
> +   dwc2_port_suspend(hsotg, 1);
> +
> +   return 0;
> +}
> +
> +static int _dwc2_hcd_resume(struct usb_hcd *hcd)
> +{
> +   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
> +   u32 hprt0;
> +
> +   if (hsotg->op_state != OTG_STATE_B_HOST)
> +   return 0;
> +
> +   if (hsotg->lx_state != DWC2_L2)
> +   return 0;
> +
> +   hprt0 = dwc2_read_hprt0(hsotg);
> +   if ((hprt0 | HPRT0_CONNSTS) && (hprt0 | HPRT0_SUSP))
> +   dwc2_port_resume(hsotg);
> +
> +   return 0;
> +}
> +
>  /* Returns the current frame number */
>  static int _dwc2_hcd_get_frame_number(struct usb_hcd *hcd)
>  {
> @@ -2671,6 +2720,9 @@ static struct hc_driver dwc2_hc_driver = {
> .hub_status_data = _dwc2_hcd_hub_status_data,
> .hub_control = _dwc2_hcd_hub_control,
> .clear_tt_buffer_complete = _dwc2_hcd_clear_tt_buffer_complete,
> +
> +   .bus_suspend = _dwc2_hcd_suspend,
> +   .bus_resume = _dwc2_hcd_resume,

These functions should be defined and registered conditionnally under
#ifdef CONFIG_PM.

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

Re: [PATCH 1/2] [usb] make xhci platform driver use 64 bit or 32 bit DMA

[Arnd Bergmann]

On Friday 31 October 2014 09:22:26 Mark Langsdorf wrote:
> On 10/30/2014 04:05 PM, Arnd Bergmann wrote:
> > On Thursday 30 October 2014 15:09:33 Mark Langsdorf wrote:
> >
> > You should not access pdev->dev.dma_mask here, that gets set
> > by the platform code. You should be able to just use
> > dma_set_mask_and_coherent to set both.
> 
> So:
> 
> if (sizeof(dma_addr_t) < 8 ||
> dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64))) {
> ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> if (ret)
> return ret;
> }
> 
> This doesn't actually work for me. I experimented a bit on the
> hardware and I always fail if I don't set the coherent mask
> first.

Very strange, the code looks right to me. What is the initial value
of dev->dma_mask?

> >>> Also, we should no longer need to worry about the case where
> >>> pdev->dev.dma_mask is NULL, as this now gets initialized from
> >>> the DT setup.
> >>
> >> I'm running this on a system with ACPI enabled and no DT. Does
> >> that make a difference?
> >
> > I don't know how the DMA mask gets initialized on ACPI, I assume it
> > doesn't at the moment, but that is something that should be fixed
> > in the ACPI code, not worked around in the driver.
> >
> > You should definitely make sure that this also works with DT, as
> > I don't think it's possible to support X-Gene with ACPI. I know
> > that Al Stone has experimented with it in the past, but he never
> > came back with any results, so I assume the experiment failed.
> 
> I'm running my test code on an X-Gene with ACPI. Al Stone, Mark
> Salter, and I got it working.

The question is whether that is in a form that we could merge upstream.
I haven't seen any patches being posted, so I can't know for sure, but
from all I know about the hardware it doesn't seem likely, unless
you leave out all the interesting bits such as power mangement, PCI
and networking.

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 v4-real] cdc-acm: ensure that termios get set when the port is activated

[Oliver Neukum]

On Fri, 2014-10-31 at 12:45 +0100, Johan Hovold wrote:
> On Thu, Oct 30, 2014 at 11:04:47AM -0400, Jim Paris wrote:
> > The driver wasn't properly configuring the hardware for the current
> > termios settings under all conditions.  Ensure that termios are
> > written to the device when the port is activated.
> > 
> > Signed-off-by: Jim Paris 
> 
> Reviewed-by: Johan Hovold 
Acked-by: Oliver Neukum 

--
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 RESEND V4 5/9] of: Add NVIDIA Tegra xHCI controller binding

[Andrew Bresticker]

On Fri, Oct 31, 2014 at 4:32 AM, Thierry Reding
 wrote:
> On Thu, Oct 30, 2014 at 10:26:47AM -0700, Andrew Bresticker wrote:
>> On Thu, Oct 30, 2014 at 10:24 AM, Thierry Reding
>>  wrote:
>> > On Thu, Oct 30, 2014 at 10:19:21AM -0700, Andrew Bresticker wrote:
>> >> On Thu, Oct 30, 2014 at 6:55 AM, Thierry Reding
>> >>  wrote:
>> >> > On Wed, Oct 29, 2014 at 09:37:14AM -0700, Andrew Bresticker wrote:
>> >> >> On Wed, Oct 29, 2014 at 2:43 AM, Thierry Reding
>> >> >>  wrote:
>> >> >> > On Tue, Oct 28, 2014 at 03:27:50PM -0700, Andrew Bresticker wrote:
>> >> >> > [...]
>> >> >> >> diff --git 
>> >> >> >> a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
>> >> >> >>  
>> >> >> >> b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
>> >> >> > [...]
>> >> >> >> +Optional properties:
>> >> >> >> +---
>> >> >> >> +- vbus-{0,1,2}-supply: VBUS regulator for the corresponding UTMI 
>> >> >> >> pad.
>> >> >> >> +- vddio-hsic-supply: VDDIO regulator for the HSIC pads.
>> >> >> >> +- nvidia,usb3-port-{0,1}-lane: PCIe/SATA lane to which the 
>> >> >> >> corresponding USB3
>> >> >> >> +  port is mapped.  See  
>> >> >> >> for the list
>> >> >> >> +  of valid values.
>> >> >> >
>> >> >> > I dislike how we now need to provide a list of all pins in the header
>> >> >> > file, where previously we used strings for this. This could become 
>> >> >> > very
>> >> >> > ugly if the set of pins changes in future generations of this IP 
>> >> >> > block.
>> >> >> >
>> >> >> > Could we instead derive this from the pinmux nodes? For example you 
>> >> >> > have
>> >> >> > this in the example below:
>> >> >> >
>> >> >> > usb3p0 {
>> >> >> > nvidia,lanes = "pcie-0";
>> >> >> > ...
>> >> >> > };
>> >> >> >
>> >> >> > Perhaps what we need is to either key off the node name or add 
>> >> >> > another
>> >> >> > property, such as:
>> >> >> >
>> >> >> > nvidia,usb3-port = <0>;
>> >> >> >
>> >> >> > This would match the nvidia,usb2-port property that you've added 
>> >> >> > below.
>> >> >>
>> >> >> That is actually how I described the USB3 port to SS lane mapping
>> >> >> originally, but in review of an earlier version of this series,
>> >> >> Stephen suggested that I make it a separate, not pinconfig property
>> >> >> since it wasn't a value written directly to the hardware.  I'm fine
>> >> >> with changing it back as the pinconfig property makes more sense to me
>> >> >> as well.
>> >> >
>> >> > Hmm... I had considered it a mux option of the specific lane. If the
>> >> > function is usb3, it'd still need to be muxed to one of the ports. So
>> >> > it's additional information associated with the usb3 function.
>> >> >
>> >> > I did look through the driver changes and can't really make out which
>> >> > part of the code actually performs this assignment. Can you point me to
>> >> > it?
>> >>
>> >> There's not really an assignment.  The property is used to map between
>> >> a lane (e.g. PCIe-0 or SATA) and the USB3.0 port it's mapped to.  For
>> >> an example of where it's used, take a look at usb3_phy_power_on().
>> >> There are certain per-lane registers which need to be programmed in
>> >> addition to the per-USB3.0 port pad registers.  This mapping is used
>> >> to determine which lane needs to be programmed.
>> >
>> > Are you saying the mapping of lane to USB port is fixed? That is, PCIe-0
>> > lane is always used for USB port X and SATA always for USB port Y?
>>
>> No, sorry if that was unclear, it's not fixed - it's a board specific
>> property.
>
> Okay, but there's no register that contains the mapping of the port to a
> lane, similar to what's done for the functions, right?

Correct.

> I mean the driver only uses the lane to find out which register to write.
> Doesn't that imply that two lanes (or more) could be mapped to the same
> USB 3.0 port?

I guess?  Not sure how that would work in hardware to have two
SuperSpeed lanes wired up to a single port.

> I'm not sure I'm being clear here, so let me try another way. In order
> to establish a mapping between USB port and lane, I would've expected
> one of the following to happen:
>
> - A value derived from the lane number is written to a register
>   belonging to a given port.
>
> - A value derived from the port number is written to a register
>   belonging to a given lane.
>
> I can't see the code do either of the above, which to me implies that
> there's a fixed mapping between lanes and ports. What am I missing?

It's fixed in that it's not a software-modifiable property.  It's
describing an electrical connection between lane and port.  For
example, it's possible that one board has PCIe lane 1 wired up to
SuperSpeed port 1 and on another board for the SATA lane to be wired
up to SuperSpeed port 1.  Does that make sense?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vg

Re: [PATCH RESEND V4 3/9] of: Update Tegra XUSB pad controller binding for USB

[Andrew Bresticker]

On Fri, Oct 31, 2014 at 2:44 AM, Linus Walleij  wrote:
> On Tue, Oct 28, 2014 at 11:27 PM, Andrew Bresticker
>  wrote:
>
>> Add new bindings used for USB support by the Tegra XUSB pad controller.
>> This includes additional PHY types, USB-specific pinconfig properties, etc.
>>
>> Signed-off-by: Andrew Bresticker 
>> Reviewed-by: Stephen Warren 
>> ---
>> Changes from v2:
>>  - Added nvidia,otg-hs-curr-level-offset property.
>>  - Dropped "-otg" from VBUS supplies.
>>  - Added mbox-names property.
>>  - Removed extra whitespace.
>> Changes from v1:
>>  - Updated to use common mailbox bindings.
>>  - Made USB3 port-to-lane mappins a top-level binding rather than a pinconfig
>>binding.
>>  - Add #defines for the padctl lanes.
>
> Acked-by: Linus Walleij 
>
> I guess you will take this patch along with the rest through ARM SoC
> or so?

Yes, that's the plan.
--
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: [3.16.1 BISECTED REGRESSION]: Simtec Entropy Key (cdc-acm) broken in 3.16

[Nix]

Sorry for the delay: illness and work-related release time flurries.

On 24 Oct 2014, Johan Hovold told this:

> [ +CC: linux-usb ]
>
> On Wed, Oct 22, 2014 at 04:36:59PM +0100, Nix wrote:
>> On 22 Oct 2014, Johan Hovold outgrape:
>> 
>> > On Wed, Oct 22, 2014 at 10:31:17AM +0100, Nix wrote:
>> >> On 14 Oct 2014, Johan Hovold verbalised:
>> >> 
>> >> > On Sun, Oct 12, 2014 at 10:36:30PM +0100, Nix wrote:
>> >> >> I have checked: this code is being executed against a symlink that
>> >> >> points to /dev/ttyACM0, and the tcsetattr() succeeds. (At least, it's
>> >> >> succeeding on the kernel I'm running now, but of course that's 3.16.5
>> >> >> with this commit reverted...)
>> >> >
>> >> > You could verify that by enabling debugging in the cdc-acm driver and
>> >> > making sure that the corresponding control messages are indeed sent on
>> >> > close.
>> >> 
>> >> I have a debugging dump at
>> >> ; it's fairly
>> >
>> > What kernel were you using here? The log seems to suggest that it was
>> > generated with the commit in question reverted.
>> 
>> Look now :) (the previous log is still there in cdc-acm-reverted.log.)
>
> Unfortunately, it seems the logs are incomplete. There are lots of
> entries missing (e.g. "acm_tty_install" when opening, but also some
> "acm_submit_read_urb"), some of which were there in your first log.

OK. What we have now in
 is a log from the
pristine upstream 3.16.6 kernel with cdc-acm debugging turned on and the
acm_tty_write - count stuff in acm_tty_write() disabled: I've increased
the dmesg buffer size so the top isn't being cut off any more. It took a
lot of boots for it to fail this time: about a dozen. The log contains
the boot that failed and the one before.

(To my uneducated eye, the initial traffic to/from the key looks *very*
different in the second boot. Something is clearly wrong by this point,
but that's not much of a surprise!)

>> This contains two boots -- one on which the USB key worked, and the next
>> (with an identical kernel) with which the key was broken. (I'm not sure
>> whether this problem happens at startup or shutdown time, so it seemed
>> best to provide both.)
>
> That's a good idea.
>
> Is it only after reboot you've seen the device fail?

So far.

>  What if you
> physically disconnect and reconnect the device instead, or simply

That fixes it, in fact it's the only way to fix it once it's broken by
this bug.

> repeatedly open and close it?

Hm. Good idea.

... no, that doesn't help. Additional log from that shows a lot of what
looks like error returns:

Oct 31 16:38:03 fold kern debug: : [  168.135213] cdc_acm 2-1:1.0: acm_tty_close
Oct 31 16:38:08 fold kern debug: : [  173.130531] cdc_acm 2-1:1.0: acm_ctrl_msg 
- rq 0x22, val 0x0, len 0x0, result -110
Oct 31 16:38:08 fold kern debug: : [  173.130557] cdc_acm 2-1:1.0: 
acm_port_shutdown
Oct 31 16:38:08 fold kern debug: : [  173.131475] cdc_acm 2-1:1.0: acm_ctrl_irq 
- urb shutting down with status: -2
Oct 31 16:38:08 fold kern debug: : [  173.132474] cdc_acm 2-1:1.1: 
acm_write_bulk - len 0/1, status -2
Oct 31 16:38:08 fold kern debug: : [  173.132519] cdc_acm 2-1:1.1: acm_softint
Oct 31 16:38:08 fold kern debug: : [  173.133473] cdc_acm 2-1:1.1: 
acm_write_bulk - len 0/1, status -2
Oct 31 16:38:08 fold kern debug: : [  173.133510] cdc_acm 2-1:1.1: acm_softint
Oct 31 16:38:08 fold kern debug: : [  173.134471] cdc_acm 2-1:1.1: 
acm_write_bulk - len 0/1, status -2
Oct 31 16:38:08 fold kern debug: : [  173.134507] cdc_acm 2-1:1.1: acm_softint
Oct 31 16:38:08 fold kern debug: : [  173.135471] cdc_acm 2-1:1.1: 
acm_write_bulk - len 0/1, status -2
Oct 31 16:38:08 fold kern debug: : [  173.135509] cdc_acm 2-1:1.1: acm_softint
Oct 31 16:38:08 fold kern debug: : [  173.136472] cdc_acm 2-1:1.1: 
acm_write_bulk - len 0/1, status -2
Oct 31 16:38:08 fold kern debug: : [  173.136507] cdc_acm 2-1:1.1: acm_softint
Oct 31 16:38:08 fold kern debug: : [  173.137471] cdc_acm 2-1:1.1: 
acm_write_bulk - len 0/1, status -2
Oct 31 16:38:08 fold kern debug: : [  173.137517] cdc_acm 2-1:1.1: acm_softint
Oct 31 16:38:08 fold kern debug: : [  173.138471] cdc_acm 2-1:1.1: 
acm_write_bulk - len 0/1, status -2
Oct 31 16:38:08 fold kern debug: : [  173.138520] cdc_acm 2-1:1.1: acm_softint
Oct 31 16:38:08 fold kern debug: : [  173.139469] cdc_acm 2-1:1.1: 
acm_write_bulk - len 0/1, status -2
Oct 31 16:38:08 fold kern debug: : [  173.139515] cdc_acm 2-1:1.1: acm_softint
Oct 31 16:38:08 fold kern debug: : [  173.140470] cdc_acm 2-1:1.1: 
acm_read_bulk_callback - urb 0, len 0
Oct 31 16:38:08 fold kern debug: : [  173.140491] cdc_acm 2-1:1.1: 
acm_read_bulk_callback - non-zero urb status: -2
Oct 31 16:38:08 fold kern debug: : [  173.141469] cdc_acm 2-1:1.1: 
acm_read_bulk_callback - urb 1, len 0
Oct 31 16:38:08 fold kern debug: : [  173.141489] cdc_acm 2-1:1.1: 
acm_read_bulk_callb

[PATCH v2] usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC

[Ashwini Pahuja]

- The v2 version includes all the feedback provided by Felipe on the v1 and 
also
-- Removed unnecessary out of memory messages.
-- Added usb_gadget_giveback_request
-- udc_stop: removed unnecessary driver argument.
-- Removed unused defines
-- Renamed upsc to uspc

- I would consider adding tracepoint support in near future, but not 
immediately.

- This patch adds a UDC driver for Broadcom's USB3.0 device controller 
IP(BDC).

- The driver was written using the Felipe's USB testing/next branch as a 
baseline from:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git

- The driver is tested on FPGA-PCIe based platform using various gadget 
drivers such as zero, mass storage, ether(rndis), hid and also with tools such 
as USB3CV, USB2CV and Link layer compliance.

Signed-off-by: Ashwini Pahuja 
---
 drivers/usb/gadget/udc/Kconfig|2 +
 drivers/usb/gadget/udc/Makefile   |1 +
 drivers/usb/gadget/udc/bdc/Kconfig|   21 +
 drivers/usb/gadget/udc/bdc/Makefile   |3 +
 drivers/usb/gadget/udc/bdc/bdc.h  |  490 
 drivers/usb/gadget/udc/bdc/bdc_cmd.c  |  371 ++
 drivers/usb/gadget/udc/bdc/bdc_cmd.h  |   29 +
 drivers/usb/gadget/udc/bdc/bdc_core.c |  527 +
 drivers/usb/gadget/udc/bdc/bdc_dbg.c  |  231 
 drivers/usb/gadget/udc/bdc/bdc_dbg.h  |   26 +
 drivers/usb/gadget/udc/bdc/bdc_ep.c   | 2019 +
 drivers/usb/gadget/udc/bdc/bdc_ep.h   |   22 +
 drivers/usb/gadget/udc/bdc/bdc_pci.c  |  132 +++
 drivers/usb/gadget/udc/bdc/bdc_udc.c  |  588 ++
 14 files changed, 4462 insertions(+), 0 deletions(-)
 create mode 100644 drivers/usb/gadget/udc/bdc/Kconfig
 create mode 100644 drivers/usb/gadget/udc/bdc/Makefile
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc.h
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_cmd.c
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_cmd.h
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_core.c
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_dbg.c
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_dbg.h
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_ep.c
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_ep.h
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_pci.c
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_udc.c

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 217365d..b8e213e 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -241,6 +241,8 @@ config USB_M66592
   dynamically linked module called "m66592_udc" and force all
   gadget drivers to also be dynamically linked.
 
+source "drivers/usb/gadget/udc/bdc/Kconfig"
+
 #
 # Controllers available only in discrete form (and all PCI controllers)
 #
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index a7f4491..fba2049 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_USB_FOTG210_UDC) += fotg210-udc.o
 obj-$(CONFIG_USB_MV_U3D)   += mv_u3d_core.o
 obj-$(CONFIG_USB_GR_UDC)   += gr_udc.o
 obj-$(CONFIG_USB_GADGET_XILINX)+= udc-xilinx.o
+obj-$(CONFIG_USB_BDC_UDC)  += bdc/
diff --git a/drivers/usb/gadget/udc/bdc/Kconfig 
b/drivers/usb/gadget/udc/bdc/Kconfig
new file mode 100644
index 000..0d7b8c9
--- /dev/null
+++ b/drivers/usb/gadget/udc/bdc/Kconfig
@@ -0,0 +1,21 @@
+config USB_BDC_UDC
+   tristate "Broadcom USB3.0 device controller IP driver(BDC)"
+   depends on USB_GADGET && HAS_DMA
+
+   help
+   BDC is Broadcom's USB3.0 device controller IP. If your SOC has a BDC IP
+   then select this driver.
+
+   Say "y" here to link the driver statically, or "m" to build a 
dynamically
+   linked module called "bdc".
+
+if USB_BDC_UDC
+
+comment "Platform Support"
+config USB_BDC_PCI
+   tristate "BDC support for PCIe based platforms"
+   depends on PCI
+   default USB_BDC_UDC
+   help
+   Enable support for platforms which have BDC connected through 
PCIe, such as Lego3 FPGA platform.
+endif
diff --git a/drivers/usb/gadget/udc/bdc/Makefile 
b/drivers/usb/gadget/udc/bdc/Makefile
new file mode 100644
index 000..66383d3
--- /dev/null
+++ b/drivers/usb/gadget/udc/bdc/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_USB_BDC_UDC)  += bdc.o
+bdc-y  := bdc_core.o bdc_cmd.o bdc_ep.o bdc_udc.o bdc_dbg.o
+obj-$(CONFIG_USB_BDC_PCI)  += bdc_pci.o
diff --git a/drivers/usb/gadget/udc/bdc/bdc.h b/drivers/usb/gadget/udc/bdc/bdc.h
new file mode 100644
index 000..dc18a20
--- /dev/null
+++ b/drivers/usb/gadget/udc/bdc/bdc.h
@@ -0,0 +1,490 @@
+/*
+ * bdc.h - header for the BRCM BDC USB3.0 device controller
+ *
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * Author: Ashwini Pahuja
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the 

Re: USB3: unable to enumerate, device not accepting address

[Alan Stern]

On Fri, 31 Oct 2014, parafin wrote:

> I assumed Sarah reads this mailing list (she replied here sometime ago
> when I posted about another issue), but OK, I will forward my email to
> her directly as well.

You might also bear in mind that Sarah is no longer the xHCI maintainer 
and she is not actively working in this area any longer.  You might 
want also to CC: the current xHCI maintainer.

> P.S.
> I also cross-posted this to this bug which seems to be at least related:
> https://bugzilla.kernel.org/show_bug.cgi?id=41752

There have been a lot of bugs related to xHCI.  Even though your may 
seem related to that other one, there's a good chance that it isn't.

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: USB3: unable to enumerate, device not accepting address

[parafin]

On Fri, 31 Oct 2014 12:52:04 -0400 (EDT)
Alan Stern  wrote:

> On Fri, 31 Oct 2014, parafin wrote:
> 
> > I assumed Sarah reads this mailing list (she replied here sometime
> > ago when I posted about another issue), but OK, I will forward my
> > email to her directly as well.
> 
> You might also bear in mind that Sarah is no longer the xHCI
> maintainer and she is not actively working in this area any longer.
> You might want also to CC: the current xHCI maintainer.

Who is currently maintaining XHCI or/and where should I look for this
kind of information?

> 
> > P.S.
> > I also cross-posted this to this bug which seems to be at least
> > related: https://bugzilla.kernel.org/show_bug.cgi?id=41752
> 
> There have been a lot of bugs related to xHCI.  Even though your may 
> seem related to that other one, there's a good chance that it isn't.

That bug caught my attention because mentioned commit removed code
written to fix it.

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

[PATCH] HID: usbhid: enable always-poll quirk for Elan Touchscreen 0103

[Adel Gadllah]

Yet another device that needs this quirk.

Reported-by: Tanguy de Baritault 
Signed-off-by: Adel Gadllah 
---
 drivers/hid/hid-ids.h   | 1 +
 drivers/hid/usbhid/hid-quirks.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index e23ab8b..7c86373 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -299,6 +299,7 @@
 #define USB_VENDOR_ID_ELAN 0x04f3
 #define USB_DEVICE_ID_ELAN_TOUCHSCREEN 0x0089
 #define USB_DEVICE_ID_ELAN_TOUCHSCREEN_009B0x009b
+#define USB_DEVICE_ID_ELAN_TOUCHSCREEN_01030x0103
 #define USB_DEVICE_ID_ELAN_TOUCHSCREEN_016F0x016f
 
 #define USB_VENDOR_ID_ELECOM   0x056e
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 5014bb5..552671e 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -72,6 +72,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN, 
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_009B, 
HID_QUIRK_ALWAYS_POLL },
+   { USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_0103, 
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_016F, 
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_TS2700, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_FORMOSA, USB_DEVICE_ID_FORMOSA_IR_RECEIVER, 
HID_QUIRK_NO_INIT_REPORTS },
-- 
1.9.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: USB3: unable to enumerate, device not accepting address

[Alan Stern]

On Fri, 31 Oct 2014, parafin wrote:

> On Fri, 31 Oct 2014 12:52:04 -0400 (EDT)
> Alan Stern  wrote:
> 
> > On Fri, 31 Oct 2014, parafin wrote:
> > 
> > > I assumed Sarah reads this mailing list (she replied here sometime
> > > ago when I posted about another issue), but OK, I will forward my
> > > email to her directly as well.
> > 
> > You might also bear in mind that Sarah is no longer the xHCI
> > maintainer and she is not actively working in this area any longer.
> > You might want also to CC: the current xHCI maintainer.
> 
> Who is currently maintaining XHCI or/and where should I look for this
> kind of information?

See the MAINTAINERS file in the top-level directory of the kernel 
source tree.  You can also use the scripts/get_maintainer.pl program.

Alan Stern

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

Re: [PATCH v2] usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC

[Felipe Balbi]

On Fri, Oct 31, 2014 at 09:51:03AM -0700, Ashwini Pahuja wrote:
> - The v2 version includes all the feedback provided by Felipe on the v1 
> and also
>   -- Removed unnecessary out of memory messages.
>   -- Added usb_gadget_giveback_request
>   -- udc_stop: removed unnecessary driver argument.
>   -- Removed unused defines
>   -- Renamed upsc to uspc
> 
> - I would consider adding tracepoint support in near future, but not 
> immediately.
> 
> - This patch adds a UDC driver for Broadcom's USB3.0 device controller 
> IP(BDC).
> 
> - The driver was written using the Felipe's USB testing/next branch as a 
> baseline from:
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
> 
> - The driver is tested on FPGA-PCIe based platform using various gadget 
> drivers such as zero, mass storage, ether(rndis), hid and also with tools 
> such as USB3CV, USB2CV and Link layer compliance.

you need to improve your commit log, There's way too much here which
shouldn't go to git log. I won't review until this part is sorted out,
sorry.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCHv6 6/8] usb: dwc2: gadget: Do not fail probe if there isn't a clock node

[Felipe Balbi]

Hi,

On Fri, Oct 31, 2014 at 10:20:06AM -0500, Dinh Nguyen wrote:
> >> @@ -339,7 +339,8 @@ static void dwc2_handle_wakeup_detected_intr(struct 
> >> dwc2_hsotg *hsotg)
> >>}
> >>/* Change to L0 state */
> >>hsotg->lx_state = DWC2_L0;
> >> -  call_gadget(hsotg, resume);
> >> +  if (!IS_ERR(hsotg->clk))
> >> +  call_gadget(hsotg, resume);
> > 
> > instead of exposing the clock detail to the entire driver, add IS_ERR()
> > checks to resume and suspend instead. In fact, NULL is a valid clock, so
> > you might as well:
> > 
> > clk = clk_get(foo, bar);
> > if (IS_ERR(clk))
> > dwc->clk = NULL;
> > else
> > dwc->clk = clk;
> > 
> > Then you don't need any IS_ERR() checks sprinkled around the driver.
> 
> But we would still need to check for the clock before accessing gadget
> functionality right?
> 
>   if (dwc2->clk)
>   call_gadget();

Read my comment again. "NULL is a valid clock".  Look at what
clk_enable() does when a NULL pointer is passed:

static int __clk_enable(struct clk *clk)
{
int ret = 0;

if (!clk)
return 0;

if (WARN_ON(clk->prepare_count == 0))
return -ESHUTDOWN;

if (clk->enable_count == 0) {
ret = __clk_enable(clk->parent);

if (ret)
return ret;

if (clk->ops->enable) {
ret = clk->ops->enable(clk->hw);
if (ret) {
__clk_disable(clk->parent);
return ret;
}
}
}

clk->enable_count++;
return 0;
}

int clk_enable(struct clk *clk)
{
unsigned long flags;
int ret;

flags = clk_enable_lock();
ret = __clk_enable(clk);
clk_enable_unlock(flags);

return ret;
}
EXPORT_SYMBOL_GPL(clk_enable);

> >> @@ -400,7 +401,8 @@ static void dwc2_handle_usb_suspend_intr(struct 
> >> dwc2_hsotg *hsotg)
> >>"DSTS.Suspend Status=%d HWCFG4.Power Optimize=%d\n",
> >>!!(dsts & DSTS_SUSPSTS),
> >>hsotg->hw_params.power_optimized);
> >> -  call_gadget(hsotg, suspend);
> >> +  if (!IS_ERR(hsotg->clk))
> >> +  call_gadget(hsotg, suspend);
> >>} else {
> >>if (hsotg->op_state == OTG_STATE_A_PERIPHERAL) {
> >>dev_dbg(hsotg->dev, "a_peripheral->a_host\n");
> >> @@ -477,7 +479,8 @@ irqreturn_t dwc2_handle_common_intr(int irq, void *dev)
> >>spin_lock(&hsotg->lock);
> >>  
> >>if (dwc2_is_device_mode(hsotg))
> >> -  retval = s3c_hsotg_irq(irq, dev);
> >> +  if (!IS_ERR(hsotg->clk))
> >> +  retval = s3c_hsotg_irq(irq, dev);
> > 
> > wait a minute, if there is no clock we don't call the gadget interrupt
> > handler ? Why ? Who will disable the IRQ line ?
> 
> This portion is no static int __clk_enable(struct clk *clk)

huh ? What I mean is that this has the potential of leaving that IRQ
line enabled. Imagine you don't have a clock and s3c_hsotg_irq() isn't
called, then a peripheral IRQ fires, since the handler isn't called, who
will clear the interrupt ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH net] r8152: stop submitting intr for -EPROTO

[David Miller]

From: Hayes Wang 
Date: Fri, 31 Oct 2014 13:35:57 +0800

> For Renesas USB 3.0 host controller, when unplugging the usb hub which
> has the RTL8153 plugged, the driver would get -EPROTO for interrupt
> transfer. There is high probability to get the information of "HC died;
> cleaning up", if the driver continues to submit the interrupt transfer
> before the disconnect() is called.
 ...
> Signed-off-by: Hayes Wang 

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

Re: [PATCH 1/2] [usb] make xhci platform driver use 64 bit or 32 bit DMA

[Mark Langsdorf]

On 10/31/2014 10:49 AM, Arnd Bergmann wrote:

On Friday 31 October 2014 09:22:26 Mark Langsdorf wrote:

On 10/30/2014 04:05 PM, Arnd Bergmann wrote:

On Thursday 30 October 2014 15:09:33 Mark Langsdorf wrote:

You should not access pdev->dev.dma_mask here, that gets set
by the platform code. You should be able to just use
dma_set_mask_and_coherent to set both.


So:

 if (sizeof(dma_addr_t) < 8 ||
 dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64))) {
 ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
 if (ret)
 return ret;
 }

This doesn't actually work for me. I experimented a bit on the
hardware and I always fail if I don't set the coherent mask
first.


Very strange, the code looks right to me. What is the initial value
of dev->dma_mask?


Did you mean &pdev->dev.dma_mask? It's 0xdc759df8.

--Mark Langsdorf
--
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: dwc2: add bus suspend/resume for dwc2

[Paul Zimmerman]

> From: Kever Yang [mailto:kever.y...@gmail.com] On Behalf Of Kever Yang
> Sent: Friday, October 31, 2014 7:03 AM
> 
> This patch adds suspend/resume for dwc2 hcd controller.
> 
> Signed-off-by: Kever Yang 
> ---
> 
>  drivers/usb/dwc2/hcd.c | 74 
> ++
>  1 file changed, 63 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index fa49c72..df68449 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -1473,6 +1473,29 @@ static void dwc2_port_suspend(struct dwc2_hsotg 
> *hsotg, u16 windex)
>   }
>  }
> 
> +static void dwc2_port_resume(struct dwc2_hsotg *hsotg)
> +{
> + u32 hprt0;
> +
> + /* After clear the Stop PHY clock bit, we should wait for a moment
> +  * for PLL work stable with clock output.
> +  */
> + writel(0, hsotg->regs + PCGCTL);
> + usleep_range(2000, 4000);
> +
> + hprt0 = dwc2_read_hprt0(hsotg);
> + hprt0 |= HPRT0_RES;
> + writel(hprt0, hsotg->regs + HPRT0);
> + hprt0 &= ~HPRT0_SUSP;
> + /* according to USB2.0 Spec 7.1.7.7, the host most send the resume
> +  * signal for at least 20ms
> +  */
> + usleep_range(2, 25000);
> +
> + hprt0 &= ~HPRT0_RES;
> + writel(hprt0, hsotg->regs + HPRT0);
> +}
> +
>  /* Handles hub class-specific requests */
>  static int dwc2_hcd_hub_control(struct dwc2_hsotg *hsotg, u16 typereq,
>   u16 wvalue, u16 windex, char *buf, u16 wlength)
> @@ -1518,17 +1541,7 @@ static int dwc2_hcd_hub_control(struct dwc2_hsotg 
> *hsotg, u16 typereq,
>   case USB_PORT_FEAT_SUSPEND:
>   dev_dbg(hsotg->dev,
>   "ClearPortFeature USB_PORT_FEAT_SUSPEND\n");
> - writel(0, hsotg->regs + PCGCTL);
> - usleep_range(2, 4);
> -
> - hprt0 = dwc2_read_hprt0(hsotg);
> - hprt0 |= HPRT0_RES;
> - writel(hprt0, hsotg->regs + HPRT0);
> - hprt0 &= ~HPRT0_SUSP;
> - usleep_range(10, 15);
> -
> - hprt0 &= ~HPRT0_RES;
> - writel(hprt0, hsotg->regs + HPRT0);
> + dwc2_port_resume(hsotg);
>   break;
> 
>   case USB_PORT_FEAT_POWER:
> @@ -2301,6 +2314,42 @@ static void _dwc2_hcd_stop(struct usb_hcd *hcd)
>   usleep_range(1000, 3000);
>  }
> 
> +static int _dwc2_hcd_suspend(struct usb_hcd *hcd)
> +{
> + struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
> + u32 hprt0;
> +
> + if (hsotg->op_state != OTG_STATE_B_HOST)
> + return 0;
> +
> + if (hsotg->lx_state != DWC2_L0)
> + return 0;
> +
> + hprt0 = dwc2_read_hprt0(hsotg);
> + if (hprt0 & HPRT0_CONNSTS)
> + dwc2_port_suspend(hsotg, 1);
> +
> + return 0;
> +}
> +
> +static int _dwc2_hcd_resume(struct usb_hcd *hcd)
> +{
> + struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
> + u32 hprt0;
> +
> + if (hsotg->op_state != OTG_STATE_B_HOST)
> + return 0;
> +
> + if (hsotg->lx_state != DWC2_L2)
> + return 0;
> +
> + hprt0 = dwc2_read_hprt0(hsotg);
> + if ((hprt0 | HPRT0_CONNSTS) && (hprt0 | HPRT0_SUSP))

This isn't right, the condition will always be true.

Per your previous email, you are not able to test this because your
platform does not support suspend/resume yet, is that right? I don't
want to apply any untested patches to the driver.

-- 
Paul

--
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: dwc2/gadget: report disconnect event from 'end session' irq

[Paul Zimmerman]

> From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
> Sent: Friday, October 31, 2014 1:04 AM
> To: linux-usb@vger.kernel.org; linux-samsung-...@vger.kernel.org
> Cc: Marek Szyprowski; Kyungmin Park; Robert Baldyga; Paul Zimmerman; 
> Krzysztof Kozlowski; Felipe Balbi
> Subject: [PATCH v3] usb: dwc2/gadget: report disconnect event from 'end 
> session' irq
> 
> This patch adds a call to s3c_hsotg_disconnect() from 'end session'
> interrupt (GOTGINT_SES_END_DET) to correctly notify gadget subsystem
> about unplugged usb cable. 'disconnected' interrupt (DISCONNINT) might
> look a bit more suitable for this event, but it is asserted only in
> host mode, so in device mode we need to use something else.
> 
> Additional check has been added in s3c_hsotg_disconnect() function
> to ensure that the event is reported only once after successful device
> enumeration.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/usb/dwc2/core.h   |  1 +
>  drivers/usb/dwc2/gadget.c | 10 ++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 55c90c53f2d6..b42df32e7737 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -212,6 +212,7 @@ struct s3c_hsotg {
>   struct usb_gadget   gadget;
>   unsigned intsetup;
>   unsigned long   last_rst;
> + unsigned intaddress;
>   struct s3c_hsotg_ep *eps;
>  };
> 
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index fcd2bb55ccca..6304efba11aa 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -1114,6 +1114,7 @@ static void s3c_hsotg_process_control(struct s3c_hsotg 
> *hsotg,
>DCFG_DEVADDR_SHIFT) & DCFG_DEVADDR_MASK;
>   writel(dcfg, hsotg->regs + DCFG);
> 
> + hsotg->address = ctrl->wValue;
>   dev_info(hsotg->dev, "new address %d\n", ctrl->wValue);
> 
>   ret = s3c_hsotg_send_reply(hsotg, ep0, NULL, 0);
> @@ -2031,6 +2032,10 @@ static void s3c_hsotg_disconnect(struct s3c_hsotg 
> *hsotg)
>  {
>   unsigned ep;
> 
> + if (!hsotg->address)
> + return;
> +
> + hsotg->address = 0;
>   for (ep = 0; ep < hsotg->num_of_eps; ep++)
>   kill_all_requests(hsotg, &hsotg->eps[ep], -ESHUTDOWN, true);
> 
> @@ -2290,6 +2295,11 @@ irq_retry:
>   dev_info(hsotg->dev, "OTGInt: %08x\n", otgint);
> 
>   writel(otgint, hsotg->regs + GOTGINT);
> +
> + if (otgint & GOTGINT_SES_END_DET) {
> + s3c_hsotg_disconnect(hsotg);
> + hsotg->gadget.speed = USB_SPEED_UNKNOWN;
> + }
>   }
> 
>   if (gintsts & GINTSTS_SESSREQINT) {

I don't think this is right. The host can send control requests to
the device before it sends a SetAddress to change from the default
address of 0. So if a GOTGINT_SES_END_DET happens before the
SetAddress, it will be ignored.

Or am I missing something?

-- 
Paul

--
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: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC

[Ashwini Pahuja]

On Fri, Oct 31, 2014 at 10:44 AM, Felipe Balbi  wrote:
> On Fri, Oct 31, 2014 at 09:51:03AM -0700, Ashwini Pahuja wrote:
>> - The v2 version includes all the feedback provided by Felipe on the v1 
>> and also
>>   -- Removed unnecessary out of memory messages.
>>   -- Added usb_gadget_giveback_request
>>   -- udc_stop: removed unnecessary driver argument.
>>   -- Removed unused defines
>>   -- Renamed upsc to uspc
>>
>> - I would consider adding tracepoint support in near future, but not 
>> immediately.
>>
>> - This patch adds a UDC driver for Broadcom's USB3.0 device controller 
>> IP(BDC).
>>
>> - The driver was written using the Felipe's USB testing/next branch as a 
>> baseline from:
>> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
>>
>> - The driver is tested on FPGA-PCIe based platform using various gadget 
>> drivers such as zero, mass storage, ether(rndis), hid and also with tools 
>> such as USB3CV, USB2CV and Link layer compliance.
>
> you need to improve your commit log, There's way too much here which
> shouldn't go to git log. I won't review until this part is sorted out,
> sorry.
>
Re-sending the v2 again with improved commit log. Hope its OK now. thanks
> --
> balbi
--
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: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC

[Ashwini Pahuja]

- This patch adds a UDC driver for Broadcom's USB3.0 device controller 
IP(BDC).

- The driver was written using the Felipe's USB testing/next branch as a 
baseline from:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git

- The driver is tested on FPGA-PCIe based platform using various gadget 
drivers such as zero, mass storage, ether(rndis), hid and also with tools such 
as USB3CV, USB2CV and Link layer compliance.

Signed-off-by: Ashwini Pahuja 
---
Changes for v2:
 - Includes all the feedback provided by Felipe on the v1.
 - Removed unnecessary out of memory messages.
 - Added usb_gadget_giveback_request.
 - udc_stop: removed unnecessary driver argument.
 - Removed unused defines.
 - Renamed upsc to uspc.
---
 drivers/usb/gadget/udc/Kconfig|2 +
 drivers/usb/gadget/udc/Makefile   |1 +
 drivers/usb/gadget/udc/bdc/Kconfig|   21 +
 drivers/usb/gadget/udc/bdc/Makefile   |3 +
 drivers/usb/gadget/udc/bdc/bdc.h  |  490 
 drivers/usb/gadget/udc/bdc/bdc_cmd.c  |  371 ++
 drivers/usb/gadget/udc/bdc/bdc_cmd.h  |   29 +
 drivers/usb/gadget/udc/bdc/bdc_core.c |  527 +
 drivers/usb/gadget/udc/bdc/bdc_dbg.c  |  231 
 drivers/usb/gadget/udc/bdc/bdc_dbg.h  |   26 +
 drivers/usb/gadget/udc/bdc/bdc_ep.c   | 2019 +
 drivers/usb/gadget/udc/bdc/bdc_ep.h   |   22 +
 drivers/usb/gadget/udc/bdc/bdc_pci.c  |  132 +++
 drivers/usb/gadget/udc/bdc/bdc_udc.c  |  588 ++
 14 files changed, 4462 insertions(+), 0 deletions(-)
 create mode 100644 drivers/usb/gadget/udc/bdc/Kconfig
 create mode 100644 drivers/usb/gadget/udc/bdc/Makefile
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc.h
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_cmd.c
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_cmd.h
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_core.c
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_dbg.c
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_dbg.h
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_ep.c
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_ep.h
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_pci.c
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_udc.c

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 217365d..b8e213e 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -241,6 +241,8 @@ config USB_M66592
   dynamically linked module called "m66592_udc" and force all
   gadget drivers to also be dynamically linked.
 
+source "drivers/usb/gadget/udc/bdc/Kconfig"
+
 #
 # Controllers available only in discrete form (and all PCI controllers)
 #
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index a7f4491..fba2049 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_USB_FOTG210_UDC) += fotg210-udc.o
 obj-$(CONFIG_USB_MV_U3D)   += mv_u3d_core.o
 obj-$(CONFIG_USB_GR_UDC)   += gr_udc.o
 obj-$(CONFIG_USB_GADGET_XILINX)+= udc-xilinx.o
+obj-$(CONFIG_USB_BDC_UDC)  += bdc/
diff --git a/drivers/usb/gadget/udc/bdc/Kconfig 
b/drivers/usb/gadget/udc/bdc/Kconfig
new file mode 100644
index 000..0d7b8c9
--- /dev/null
+++ b/drivers/usb/gadget/udc/bdc/Kconfig
@@ -0,0 +1,21 @@
+config USB_BDC_UDC
+   tristate "Broadcom USB3.0 device controller IP driver(BDC)"
+   depends on USB_GADGET && HAS_DMA
+
+   help
+   BDC is Broadcom's USB3.0 device controller IP. If your SOC has a BDC IP
+   then select this driver.
+
+   Say "y" here to link the driver statically, or "m" to build a 
dynamically
+   linked module called "bdc".
+
+if USB_BDC_UDC
+
+comment "Platform Support"
+config USB_BDC_PCI
+   tristate "BDC support for PCIe based platforms"
+   depends on PCI
+   default USB_BDC_UDC
+   help
+   Enable support for platforms which have BDC connected through 
PCIe, such as Lego3 FPGA platform.
+endif
diff --git a/drivers/usb/gadget/udc/bdc/Makefile 
b/drivers/usb/gadget/udc/bdc/Makefile
new file mode 100644
index 000..66383d3
--- /dev/null
+++ b/drivers/usb/gadget/udc/bdc/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_USB_BDC_UDC)  += bdc.o
+bdc-y  := bdc_core.o bdc_cmd.o bdc_ep.o bdc_udc.o bdc_dbg.o
+obj-$(CONFIG_USB_BDC_PCI)  += bdc_pci.o
diff --git a/drivers/usb/gadget/udc/bdc/bdc.h b/drivers/usb/gadget/udc/bdc/bdc.h
new file mode 100644
index 000..dc18a20
--- /dev/null
+++ b/drivers/usb/gadget/udc/bdc/bdc.h
@@ -0,0 +1,490 @@
+/*
+ * bdc.h - header for the BRCM BDC USB3.0 device controller
+ *
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * Author: Ashwini Pahuja
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#ifndef 

Re: [PATCH v2] usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC

[Felipe Balbi]

On Fri, Oct 31, 2014 at 11:21:29AM -0700, Ashwini Pahuja wrote:
> - This patch adds a UDC driver for Broadcom's USB3.0 device controller 
> IP(BDC).

why all these extra spaces here ? why isn't this wrapped at 72
characters (or so) ?

> - The driver was written using the Felipe's USB testing/next branch as a 
> baseline from:
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git

you don't need to mention this in commit log.

> - The driver is tested on FPGA-PCIe based platform using various gadget 
> drivers such as zero, mass storage, ether(rndis), hid and also with tools 
> such as USB3CV, USB2CV and Link layer compliance.

Use commit log to talk abou this new driver, its features and so on.
Look at kernel's git log if you need inspiration but this isn't supposed
to be a bullet-point list of information.

BTW, is this controller peripheral-only or can it also run as host ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2] usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC

[Ashwini Pahuja]

On Fri, Oct 31, 2014 at 11:31 AM, Felipe Balbi  wrote:
> On Fri, Oct 31, 2014 at 11:21:29AM -0700, Ashwini Pahuja wrote:
>> - This patch adds a UDC driver for Broadcom's USB3.0 device controller 
>> IP(BDC).
>
> why all these extra spaces here ? why isn't this wrapped at 72
> characters (or so) ?
>
>> - The driver was written using the Felipe's USB testing/next branch as a 
>> baseline from:
>> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
>
> you don't need to mention this in commit log.
>
OK
>> - The driver is tested on FPGA-PCIe based platform using various gadget 
>> drivers such as zero, mass storage, ether(rndis), hid and also with tools 
>> such as USB3CV, USB2CV and Link layer compliance.
>
> Use commit log to talk abou this new driver, its features and so on.
> Look at kernel's git log if you need inspiration but this isn't supposed
> to be a bullet-point list of information.
>
OK
> BTW, is this controller peripheral-only or can it also run as host ?
>
peripheral-only.
> --
Let me resend v2 with further improved commit log, thanks for your
patience. I also need to edit the subject to have RESEND in the
subject line.
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v3 1/2] usb: dwc2/gadget: add mutex to serialize init/deinit calls

[Paul Zimmerman]

> From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
> Sent: Friday, October 31, 2014 3:13 AM
> 
> This patch adds mutex, which protects initialization and
> deinitialization procedures against suspend/resume methods.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/usb/dwc2/core.h   |  1 +
>  drivers/usb/dwc2/gadget.c | 20 
>  2 files changed, 21 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 9f77b4d1c5ff..58732a9a0019 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -187,6 +187,7 @@ struct s3c_hsotg {
>   struct s3c_hsotg_plat*plat;
> 
>   spinlock_t  lock;
> + struct mutexinit_mutex;
> 
>   void __iomem*regs;
>   int irq;
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index d8dda39c9e16..a2e4272a904e 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -2908,6 +2909,7 @@ static int s3c_hsotg_udc_start(struct usb_gadget 
> *gadget,
>   return -EINVAL;
>   }
> 
> + mutex_lock(&hsotg->init_mutex);
>   WARN_ON(hsotg->driver);
> 
>   driver->driver.bus = NULL;
> @@ -2933,9 +2935,12 @@ static int s3c_hsotg_udc_start(struct usb_gadget 
> *gadget,
> 
>   dev_info(hsotg->dev, "bound driver %s\n", driver->driver.name);
> 
> + mutex_unlock(&hsotg->init_mutex);
> +
>   return 0;
> 
>  err:
> + mutex_unlock(&hsotg->init_mutex);
>   hsotg->driver = NULL;
>   return ret;
>  }
> @@ -2957,6 +2962,8 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget,
>   if (!hsotg)
>   return -ENODEV;
> 
> + mutex_lock(&hsotg->init_mutex);
> +
>   /* all endpoints should be shutdown */
>   for (ep = 1; ep < hsotg->num_of_eps; ep++)
>   s3c_hsotg_ep_disable(&hsotg->eps[ep].ep);
> @@ -2974,6 +2981,8 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget,
> 
>   clk_disable(hsotg->clk);
> 
> + mutex_unlock(&hsotg->init_mutex);
> +
>   return 0;
>  }
> 
> @@ -3002,6 +3011,7 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget, 
> int is_on)
> 
>   dev_dbg(hsotg->dev, "%s: is_on: %d\n", __func__, is_on);
> 
> + mutex_lock(&hsotg->init_mutex);
>   spin_lock_irqsave(&hsotg->lock, flags);
>   if (is_on) {
>   clk_enable(hsotg->clk);
> @@ -3013,6 +3023,7 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget, 
> int is_on)
> 
>   hsotg->gadget.speed = USB_SPEED_UNKNOWN;
>   spin_unlock_irqrestore(&hsotg->lock, flags);
> + mutex_unlock(&hsotg->init_mutex);
> 
>   return 0;
>  }
> @@ -3507,6 +3518,7 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
>   }
> 
>   spin_lock_init(&hsotg->lock);
> + mutex_init(&hsotg->init_mutex);
> 
>   hsotg->irq = ret;
> 
> @@ -3652,6 +3664,8 @@ static int s3c_hsotg_suspend(struct platform_device 
> *pdev, pm_message_t state)
>   unsigned long flags;
>   int ret = 0;
> 
> + mutex_lock(&hsotg->init_mutex);
> +
>   if (hsotg->driver)
>   dev_info(hsotg->dev, "suspending usb gadget %s\n",
>hsotg->driver->driver.name);
> @@ -3674,6 +3688,8 @@ static int s3c_hsotg_suspend(struct platform_device 
> *pdev, pm_message_t state)
>   clk_disable(hsotg->clk);
>   }
> 
> + mutex_unlock(&hsotg->init_mutex);
> +
>   return ret;
>  }
> 
> @@ -3683,7 +3699,9 @@ static int s3c_hsotg_resume(struct platform_device 
> *pdev)
>   unsigned long flags;
>   int ret = 0;
> 
> + mutex_lock(&hsotg->init_mutex);
>   if (hsotg->driver) {
> +
>   dev_info(hsotg->dev, "resuming usb gadget %s\n",
>hsotg->driver->driver.name);
> 
> @@ -3699,6 +3717,8 @@ static int s3c_hsotg_resume(struct platform_device 
> *pdev)
>   s3c_hsotg_core_connect(hsotg);
>   spin_unlock_irqrestore(&hsotg->lock, flags);
> 
> + mutex_unlock(&hsotg->init_mutex);
> +
>   return ret;
>  }
> 

Hmm. I can't find any other UDC driver that uses a mutex in its
suspend/resume functions. Can you explain why this is needed only
for dwc2?

-- 
Paul

--
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-storage: handle a skipped data phase

[Alan Stern]

Sometimes mass-storage devices using the Bulk-only transport will
mistakenly skip the data phase of a command.  Rather than sending the
data expected by the host or sending a zero-length packet, they go
directly to the status phase and send the CSW.

This causes problems for usb-storage, for obvious reasons.  The driver
will interpret the CSW as a short data transfer and will wait to
receive a CSW.  The device won't have anything left to send, so the
command eventually times out.

The SCSI layer doesn't retry commands after they time out (this is a
relatively recent change).  Therefore we should do our best to detect
a skipped data phase and handle it promptly.

This patch adds code to do that.  If usb-storage receives a short
13-byte data transfer from the device, and if the first four bytes of
the data match the CSW signature, the driver will set the residue to
the full transfer length and interpret the data as a CSW.

This fixes Bugzilla #86611.

Signed-off-by: Alan Stern 
CC: Matthew Dharm 
Tested-by: Paul Osmialowski 
CC: 

---


as1767


Index: usb-3.17/drivers/usb/storage/transport.c
===
--- usb-3.17.orig/drivers/usb/storage/transport.c
+++ usb-3.17/drivers/usb/storage/transport.c
@@ -1118,6 +1118,31 @@ int usb_stor_Bulk_transport(struct scsi_
 */
if (result == USB_STOR_XFER_LONG)
fake_sense = 1;
+
+   /*
+* Sometimes a device will mistakenly skip the data phase
+* and go directly to the status phase without sending a
+* zero-length packet.  If we get a 13-byte response here,
+* check whether it really is a CSW.
+*/
+   if (result == USB_STOR_XFER_SHORT &&
+   srb->sc_data_direction == DMA_FROM_DEVICE &&
+   transfer_length - scsi_get_resid(srb) ==
+   US_BULK_CS_WRAP_LEN) {
+   struct scatterlist *sg = NULL;
+   unsigned int offset = 0;
+
+   if (usb_stor_access_xfer_buf((unsigned char *) bcs,
+   US_BULK_CS_WRAP_LEN, srb, &sg,
+   &offset, FROM_XFER_BUF) ==
+   US_BULK_CS_WRAP_LEN &&
+   bcs->Signature ==
+   cpu_to_le32(US_BULK_CS_SIGN)) {
+   usb_stor_dbg(us, "Device skipped data phase\n");
+   scsi_set_resid(srb, transfer_length);
+   goto skipped_data_phase;
+   }
+   }
}
 
/* See flow chart on pg 15 of the Bulk Only Transport spec for
@@ -1153,6 +1178,7 @@ int usb_stor_Bulk_transport(struct scsi_
if (result != USB_STOR_XFER_GOOD)
return USB_STOR_TRANSPORT_ERROR;
 
+ skipped_data_phase:
/* check bulk status */
residue = le32_to_cpu(bcs->Residue);
usb_stor_dbg(us, "Bulk Status S 0x%x T 0x%x R %u Stat 0x%x\n",

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

Re: [PATCH 1/2] [usb] make xhci platform driver use 64 bit or 32 bit DMA

[Arnd Bergmann]

On Friday 31 October 2014 12:32:47 Mark Langsdorf wrote:
> On 10/31/2014 10:49 AM, Arnd Bergmann wrote:
> > On Friday 31 October 2014 09:22:26 Mark Langsdorf wrote:
> >> On 10/30/2014 04:05 PM, Arnd Bergmann wrote:
> >>> On Thursday 30 October 2014 15:09:33 Mark Langsdorf wrote:
> >>>
> >>> You should not access pdev->dev.dma_mask here, that gets set
> >>> by the platform code. You should be able to just use
> >>> dma_set_mask_and_coherent to set both.
> >>
> >> So:
> >>
> >>  if (sizeof(dma_addr_t) < 8 ||
> >>  dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64))) {
> >>  ret = dma_set_mask_and_coherent(&pdev->dev, 
> >> DMA_BIT_MASK(32));
> >>  if (ret)
> >>  return ret;
> >>  }
> >>
> >> This doesn't actually work for me. I experimented a bit on the
> >> hardware and I always fail if I don't set the coherent mask
> >> first.
> >
> > Very strange, the code looks right to me. What is the initial value
> > of dev->dma_mask?
> 
> Did you mean &pdev->dev.dma_mask? It's 0xdc759df8.

No, that would be the pointer to the pointer to the dma mask ;-)

I meant the DMA mask that was set by the platform code in
*pdev->dev.dma_mask. It would also be interesting to know where
pdev->dev.dma_mask points to. Does ACPI allocate memory for that,
or does it point to the coherent mask?

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: [PATCHv6 6/8] usb: dwc2: gadget: Do not fail probe if there isn't a clock node

[Dinh Nguyen]

On 10/31/2014 12:42 PM, Felipe Balbi wrote:
> Hi,
> 
> On Fri, Oct 31, 2014 at 10:20:06AM -0500, Dinh Nguyen wrote:
 @@ -339,7 +339,8 @@ static void dwc2_handle_wakeup_detected_intr(struct 
 dwc2_hsotg *hsotg)
}
/* Change to L0 state */
hsotg->lx_state = DWC2_L0;
 -  call_gadget(hsotg, resume);
 +  if (!IS_ERR(hsotg->clk))
 +  call_gadget(hsotg, resume);
>>>
>>> instead of exposing the clock detail to the entire driver, add IS_ERR()
>>> checks to resume and suspend instead. In fact, NULL is a valid clock, so
>>> you might as well:
>>>
>>> clk = clk_get(foo, bar);
>>> if (IS_ERR(clk))
>>> dwc->clk = NULL;
>>> else
>>> dwc->clk = clk;
>>>
>>> Then you don't need any IS_ERR() checks sprinkled around the driver.
>>
>> But we would still need to check for the clock before accessing gadget
>> functionality right?
>>
>>  if (dwc2->clk)
>>  call_gadget();
> 
> Read my comment again. "NULL is a valid clock".  Look at what
> clk_enable() does when a NULL pointer is passed:
> 
> static int __clk_enable(struct clk *clk)
> {
>   int ret = 0;
> 
>   if (!clk)
>   return 0;
> 
>   if (WARN_ON(clk->prepare_count == 0))
>   return -ESHUTDOWN;
> 
>   if (clk->enable_count == 0) {
>   ret = __clk_enable(clk->parent);
> 
>   if (ret)
>   return ret;
> 
>   if (clk->ops->enable) {
>   ret = clk->ops->enable(clk->hw);
>   if (ret) {
>   __clk_disable(clk->parent);
>   return ret;
>   }
>   }
>   }
> 
>   clk->enable_count++;
>   return 0;
> }
> 
> int clk_enable(struct clk *clk)
> {
>   unsigned long flags;
>   int ret;
> 
>   flags = clk_enable_lock();
>   ret = __clk_enable(clk);
>   clk_enable_unlock(flags);
> 
>   return ret;
> }
> EXPORT_SYMBOL_GPL(clk_enable);

Ah yes, thanks for the explanation. So if clk=NULL, it just return 0.
But what I'm saying is that if the driver is configured for dual-role
mode, and no clock is specified, then the driver should not be accessing
any gadget functionality.

So as the patch series stands right now, if I swap out an A connector to
a B-connector, then I get a connect_id_status change interrupt. The
status would show a device and I would initialize the gadget portion of
the driver.

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 44c609f..96810f7 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1371,7 +1371,8 @@ static void dwc2_conn_id_status_change(struct
work_struct *work)
hsotg->op_state = OTG_STATE_B_PERIPHERAL;
dwc2_core_init(hsotg, false, -1);
dwc2_enable_global_interrupts(hsotg);
-   s3c_hsotg_core_init(hsotg);
+   if (hsotg->clk)
+   s3c_hsotg_core_init(hsotg);

So if I don't have a valid clock, I'll be accessing the peripheral
portion of the IP.

But I guess not having the check for the valid clock here should be fine
as I don't see a case where there can be 2 different clocks for host and
peripheral?


> 
 @@ -400,7 +401,8 @@ static void dwc2_handle_usb_suspend_intr(struct 
 dwc2_hsotg *hsotg)
"DSTS.Suspend Status=%d HWCFG4.Power Optimize=%d\n",
!!(dsts & DSTS_SUSPSTS),
hsotg->hw_params.power_optimized);
 -  call_gadget(hsotg, suspend);
 +  if (!IS_ERR(hsotg->clk))
 +  call_gadget(hsotg, suspend);
} else {
if (hsotg->op_state == OTG_STATE_A_PERIPHERAL) {
dev_dbg(hsotg->dev, "a_peripheral->a_host\n");
 @@ -477,7 +479,8 @@ irqreturn_t dwc2_handle_common_intr(int irq, void *dev)
spin_lock(&hsotg->lock);
  
if (dwc2_is_device_mode(hsotg))
 -  retval = s3c_hsotg_irq(irq, dev);
 +  if (!IS_ERR(hsotg->clk))
 +  retval = s3c_hsotg_irq(irq, dev);
>>>
>>> wait a minute, if there is no clock we don't call the gadget interrupt
>>> handler ? Why ? Who will disable the IRQ line ?
>>
>> This portion is no static int __clk_enable(struct clk *clk)
> 
> huh ? What I mean is that this has the potential of leaving that IRQ
> line enabled. Imagine you don't have a clock and s3c_hsotg_irq() isn't
> called, then a peripheral IRQ fires, since the handler isn't called, who
> will clear the interrupt ?
> 

Yes, right. This portion of the code is no longer needed when I switched
to use a shared IRQ.

Dinh
--
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: [PATCHv6 6/8] usb: dwc2: gadget: Do not fail probe if there isn't a clock node

[Dinh Nguyen]

On 10/31/2014 02:31 PM, Dinh Nguyen wrote:
> On 10/31/2014 12:42 PM, Felipe Balbi wrote:
>> Hi,
>>
>> On Fri, Oct 31, 2014 at 10:20:06AM -0500, Dinh Nguyen wrote:
> @@ -339,7 +339,8 @@ static void dwc2_handle_wakeup_detected_intr(struct 
> dwc2_hsotg *hsotg)
>   }
>   /* Change to L0 state */
>   hsotg->lx_state = DWC2_L0;
> - call_gadget(hsotg, resume);
> + if (!IS_ERR(hsotg->clk))
> + call_gadget(hsotg, resume);

 instead of exposing the clock detail to the entire driver, add IS_ERR()
 checks to resume and suspend instead. In fact, NULL is a valid clock, so
 you might as well:

clk = clk_get(foo, bar);
if (IS_ERR(clk))
dwc->clk = NULL;
else
dwc->clk = clk;

 Then you don't need any IS_ERR() checks sprinkled around the driver.
>>>
>>> But we would still need to check for the clock before accessing gadget
>>> functionality right?
>>>
>>> if (dwc2->clk)
>>> call_gadget();
>>
>> Read my comment again. "NULL is a valid clock".  Look at what
>> clk_enable() does when a NULL pointer is passed:
>>
>> static int __clk_enable(struct clk *clk)
>> {
>>  int ret = 0;
>>
>>  if (!clk)
>>  return 0;
>>
>>  if (WARN_ON(clk->prepare_count == 0))
>>  return -ESHUTDOWN;
>>
>>  if (clk->enable_count == 0) {
>>  ret = __clk_enable(clk->parent);
>>
>>  if (ret)
>>  return ret;
>>
>>  if (clk->ops->enable) {
>>  ret = clk->ops->enable(clk->hw);
>>  if (ret) {
>>  __clk_disable(clk->parent);
>>  return ret;
>>  }
>>  }
>>  }
>>
>>  clk->enable_count++;
>>  return 0;
>> }
>>
>> int clk_enable(struct clk *clk)
>> {
>>  unsigned long flags;
>>  int ret;
>>
>>  flags = clk_enable_lock();
>>  ret = __clk_enable(clk);
>>  clk_enable_unlock(flags);
>>
>>  return ret;
>> }
>> EXPORT_SYMBOL_GPL(clk_enable);
> 
> Ah yes, thanks for the explanation. So if clk=NULL, it just return 0.
> But what I'm saying is that if the driver is configured for dual-role
> mode, and no clock is specified, then the driver should not be accessing
> any gadget functionality.
> 
> So as the patch series stands right now, if I swap out an A connector to
> a B-connector, then I get a connect_id_status change interrupt. The
> status would show a device and I would initialize the gadget portion of
> the driver.
> 
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 44c609f..96810f7 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -1371,7 +1371,8 @@ static void dwc2_conn_id_status_change(struct
> work_struct *work)
> hsotg->op_state = OTG_STATE_B_PERIPHERAL;
> dwc2_core_init(hsotg, false, -1);
> dwc2_enable_global_interrupts(hsotg);
> -   s3c_hsotg_core_init(hsotg);
> +   if (hsotg->clk)
> +   s3c_hsotg_core_init(hsotg);
> 
> So if I don't have a valid clock, I'll be accessing the peripheral
> portion of the IP.
> 
> But I guess not having the check for the valid clock here should be fine
> as I don't see a case where there can be 2 different clocks for host and
> peripheral?
> 

Ah...nevermind. I don't need to check for clocks at all because in
dwc2_gadget_init(), the clock node check comes before
usb_add_gadget_udc(). Thus without a clock node, gadget functionality is
disabled already.

Thanks,
Dinh

--
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: [PATCHv6 4/8] usb: dwc2: Update common interrupt handler to call gadget interrupt handler

[Paul Zimmerman]

> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Thursday, October 30, 2014 7:01 AM
> 
> On Tue, Oct 28, 2014 at 06:25:45PM -0500, dingu...@opensource.altera.com 
> wrote:
> > From: Dinh Nguyen 
> >
> > Make dwc2_handle_common_intr call the gadget interrupt function when 
> > operating
> > in peripheral mode. Remove the spinlock functions in s3c_hsotg_irq as
> > dwc2_handle_common_intr() already has the spinlocks.
> >
> > Move the registeration of the IRQ to common code for platform and PCI.
> >
> > Remove duplicate interrupt conditions that was in gadget, as those are 
> > handled
> > by dwc2 common interrupt handler.
> >
> > Signed-off-by: Dinh Nguyen 
> > Acked-by: Paul Zimmerman 
> > ---
> > v5: remove individual devm_request_irq from gadget and hcd, and place a
> > single devm_request_irq in platform and pci.
> > v2: Keep interrupt handler for host and peripheral modes separate
> > ---
> >  drivers/usb/dwc2/core.c  | 10 
> >  drivers/usb/dwc2/core.h  |  3 +++
> >  drivers/usb/dwc2/core_intr.c |  3 +++
> >  drivers/usb/dwc2/gadget.c| 57 
> > ++--
> >  drivers/usb/dwc2/pci.c   |  6 +
> >  drivers/usb/dwc2/platform.c  |  9 +++
> >  6 files changed, 23 insertions(+), 65 deletions(-)
> >
> > diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> > index d926945..7605850b 100644
> > --- a/drivers/usb/dwc2/core.c
> > +++ b/drivers/usb/dwc2/core.c
> > @@ -458,16 +458,6 @@ int dwc2_core_init(struct dwc2_hsotg *hsotg, bool 
> > select_phy, int irq)
> > /* Clear the SRP success bit for FS-I2c */
> > hsotg->srp_success = 0;
> >
> > -   if (irq >= 0) {
> > -   dev_dbg(hsotg->dev, "registering common handler for irq%d\n",
> > -   irq);
> > -   retval = devm_request_irq(hsotg->dev, irq,
> > - dwc2_handle_common_intr, IRQF_SHARED,
> > - dev_name(hsotg->dev), hsotg);
> > -   if (retval)
> > -   return retval;
> > -   }
> > -
> > /* Enable common interrupts */
> > dwc2_enable_common_interrupts(hsotg);
> >
> > diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> > index 80d29c7..ec70862 100644
> > --- a/drivers/usb/dwc2/core.h
> > +++ b/drivers/usb/dwc2/core.h
> > @@ -967,6 +967,7 @@ extern int s3c_hsotg_suspend(struct dwc2_hsotg *dwc2);
> >  extern int s3c_hsotg_resume(struct dwc2_hsotg *dwc2);
> >  extern int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq);
> >  extern void s3c_hsotg_core_init(struct dwc2_hsotg *dwc2);
> > +irqreturn_t s3c_hsotg_irq(int irq, void *pw);
> >  #else
> >  static inline int s3c_hsotg_remove(struct dwc2_hsotg *dwc2)
> >  { return 0; }
> > @@ -977,6 +978,8 @@ static inline int s3c_hsotg_resume(struct dwc2_hsotg 
> > *dwc2)
> >  static inline int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
> >  { return 0; }
> >  static inline void s3c_hsotg_core_init(struct dwc2_hsotg *dwc2) {}
> > +static inline irqreturn_t s3c_hsotg_irq(int irq, void *pw)
> > +{ return IRQ_HANDLED; }
> >  #endif
> >
> >  #if IS_ENABLED(CONFIG_USB_DWC2_HOST) || 
> > IS_ENABLED(CONFIG_USB_DWC2_DUAL_ROLE)
> > diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
> > index b176c2f..b0c14e0 100644
> > --- a/drivers/usb/dwc2/core_intr.c
> > +++ b/drivers/usb/dwc2/core_intr.c
> > @@ -474,6 +474,9 @@ irqreturn_t dwc2_handle_common_intr(int irq, void *dev)
> >
> > spin_lock(&hsotg->lock);
> >
> > +   if (dwc2_is_device_mode(hsotg))
> > +   retval = s3c_hsotg_irq(irq, dev);
> > +
> > gintsts = dwc2_read_common_intr(hsotg);
> > if (gintsts & ~GINTSTS_PRTINT)
> > retval = IRQ_HANDLED;
> > diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> > index 19d1b03..202f8cc 100644
> > --- a/drivers/usb/dwc2/gadget.c
> > +++ b/drivers/usb/dwc2/gadget.c
> > @@ -2257,14 +2257,13 @@ void s3c_hsotg_core_init(struct dwc2_hsotg *hsotg)
> >   * @irq: The IRQ number triggered
> >   * @pw: The pw value when registered the handler.
> >   */
> > -static irqreturn_t s3c_hsotg_irq(int irq, void *pw)
> > +irqreturn_t s3c_hsotg_irq(int irq, void *pw)
> 
> why ? It would've been a lot easier to just make the IRQ line shared.

Actually, I would prefer to keep the common interrupt handler. Reason
being, the HSOTG core can spew a *lot* of interrupts when in host mode,
and the driver already struggles to keep up with them on some platforms.
We see this problem especially on the Raspberry Pi.

So I think adding the overhead of an additional interrupt handling
path is a bad idea. Unless the peripheral-mode interrupt handler can
somehow be disabled when the controller is in host mode.

Maybe we could delay registering the gadget interrupt handler until
the controller switches to peripheral mode, and unregister it when it
switches back to host mode? But that seems pretty "odd" to me.

Felipe, what do you think?

-- 
Paul

--
To unsubscribe from this l

[PATCH RESEND v2] usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC

[Ashwini Pahuja]

This patch adds a UDC driver for Broadcom's USB3.0 Peripheral core
named BDC. BDC is capable of supporting all transfer types control,
bulk, Int and isoch on each endpoint.

Signed-off-by: Ashwini Pahuja 
---
Changes for v2:
- Includes all the feedback provided by Felipe on the v1.
- Removed unnecessary out of memory messages.
- Added usb_gadget_giveback_request.
- udc_stop: removed unnecessary driver argument.
- Removed unused defines.
- Renamed upsc to uspc.
---
 drivers/usb/gadget/udc/Kconfig|2 +
 drivers/usb/gadget/udc/Makefile   |1 +
 drivers/usb/gadget/udc/bdc/Kconfig|   21 +
 drivers/usb/gadget/udc/bdc/Makefile   |3 +
 drivers/usb/gadget/udc/bdc/bdc.h  |  490 
 drivers/usb/gadget/udc/bdc/bdc_cmd.c  |  371 ++
 drivers/usb/gadget/udc/bdc/bdc_cmd.h  |   29 +
 drivers/usb/gadget/udc/bdc/bdc_core.c |  527 +
 drivers/usb/gadget/udc/bdc/bdc_dbg.c  |  231 
 drivers/usb/gadget/udc/bdc/bdc_dbg.h  |   26 +
 drivers/usb/gadget/udc/bdc/bdc_ep.c   | 2019 +
 drivers/usb/gadget/udc/bdc/bdc_ep.h   |   22 +
 drivers/usb/gadget/udc/bdc/bdc_pci.c  |  132 +++
 drivers/usb/gadget/udc/bdc/bdc_udc.c  |  588 ++
 14 files changed, 4462 insertions(+), 0 deletions(-)
 create mode 100644 drivers/usb/gadget/udc/bdc/Kconfig
 create mode 100644 drivers/usb/gadget/udc/bdc/Makefile
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc.h
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_cmd.c
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_cmd.h
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_core.c
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_dbg.c
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_dbg.h
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_ep.c
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_ep.h
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_pci.c
 create mode 100644 drivers/usb/gadget/udc/bdc/bdc_udc.c

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 217365d..b8e213e 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -241,6 +241,8 @@ config USB_M66592
   dynamically linked module called "m66592_udc" and force all
   gadget drivers to also be dynamically linked.
 
+source "drivers/usb/gadget/udc/bdc/Kconfig"
+
 #
 # Controllers available only in discrete form (and all PCI controllers)
 #
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index a7f4491..fba2049 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_USB_FOTG210_UDC) += fotg210-udc.o
 obj-$(CONFIG_USB_MV_U3D)   += mv_u3d_core.o
 obj-$(CONFIG_USB_GR_UDC)   += gr_udc.o
 obj-$(CONFIG_USB_GADGET_XILINX)+= udc-xilinx.o
+obj-$(CONFIG_USB_BDC_UDC)  += bdc/
diff --git a/drivers/usb/gadget/udc/bdc/Kconfig 
b/drivers/usb/gadget/udc/bdc/Kconfig
new file mode 100644
index 000..0d7b8c9
--- /dev/null
+++ b/drivers/usb/gadget/udc/bdc/Kconfig
@@ -0,0 +1,21 @@
+config USB_BDC_UDC
+   tristate "Broadcom USB3.0 device controller IP driver(BDC)"
+   depends on USB_GADGET && HAS_DMA
+
+   help
+   BDC is Broadcom's USB3.0 device controller IP. If your SOC has a BDC IP
+   then select this driver.
+
+   Say "y" here to link the driver statically, or "m" to build a 
dynamically
+   linked module called "bdc".
+
+if USB_BDC_UDC
+
+comment "Platform Support"
+config USB_BDC_PCI
+   tristate "BDC support for PCIe based platforms"
+   depends on PCI
+   default USB_BDC_UDC
+   help
+   Enable support for platforms which have BDC connected through 
PCIe, such as Lego3 FPGA platform.
+endif
diff --git a/drivers/usb/gadget/udc/bdc/Makefile 
b/drivers/usb/gadget/udc/bdc/Makefile
new file mode 100644
index 000..66383d3
--- /dev/null
+++ b/drivers/usb/gadget/udc/bdc/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_USB_BDC_UDC)  += bdc.o
+bdc-y  := bdc_core.o bdc_cmd.o bdc_ep.o bdc_udc.o bdc_dbg.o
+obj-$(CONFIG_USB_BDC_PCI)  += bdc_pci.o
diff --git a/drivers/usb/gadget/udc/bdc/bdc.h b/drivers/usb/gadget/udc/bdc/bdc.h
new file mode 100644
index 000..dc18a20
--- /dev/null
+++ b/drivers/usb/gadget/udc/bdc/bdc.h
@@ -0,0 +1,490 @@
+/*
+ * bdc.h - header for the BRCM BDC USB3.0 device controller
+ *
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * Author: Ashwini Pahuja
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#ifndef__LINUX_BDC_H__
+#define__LINUX_BDC_H__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define BRCM_BDC_NAME "bdc_usb3"
+#define BRCM_BDC_DESC "BDC device controller driver"
+
+#define DMA_ADDR

Re: [PATCH net-next v2 2/3] r8152: clear the flag of SCHEDULE_TASKLET in tasklet

[David Miller]

From: Hayes Wang 
Date: Fri, 31 Oct 2014 17:56:41 +0800

> Clear the flag of SCHEDULE_TASKLET in bottom_half() to avoid
> re-schedule the tasklet again by workqueue.
> 
> Signed-off-by: Hayes Wang 
> ---
>  drivers/net/usb/r8152.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index ff54098..670279a 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -1798,6 +1798,9 @@ static void bottom_half(unsigned long data)
>   if (!netif_carrier_ok(tp->netdev))
>   return;
>  
> + if (test_bit(SCHEDULE_TASKLET, &tp->flags))
> + clear_bit(SCHEDULE_TASKLET, &tp->flags);

This is racey.

If another thread of control sets the bit between the test and the
clear, you will lose an event.

It really never makes sense to work with atomic bitops in a non-atomic
test-and-whatever manner like this, it's always a red flag and
indicates you're doing something very wrong.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btusb_intr_complete returns -EPIPE

[Alan Stern]

On Wed, 29 Oct 2014, Naveen Kumar Parna wrote:

> Split packet transactions are hidden. I could see them by clicking on
> the (Show/Hide Split transactions) button. For INT IN, I could see
> only Start Split packet.
> 
> I attached([2014-10-28 session 144012] Trace0003.rar) complete log for
> this scenario.

How come the log doesn't contain any SOF packets?

> SSPLIT IN transaction  114 1
> HS   No data884.562 264 267
> 
> SSPLIT IN transaction  115 1
> HS   No data884.562 265 217
> 
> SSPLIT IN transaction  116 1
> HS   No data884.562 285 417
> 
> SSPLIT IN transaction  117 1
> HS   No data884.562 286 467

I see what you mean -- the log doesn't contain any CSPLIT transactions 
for the interrupt endpoints.  Only SSPLIT.

I'll need to see the scheduling information for these endpoints.  
You'll have to run a 3.13 or later kernel; then the important files 
will be under /sys/kernel/debug/usb/ehci/X/, where X is the PCI address 
of the EHCI controller you are using.

Copy the files in that directory while the test is running.

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

musb: cppi41: tweak usb-storage performance a little

[Sebastian Andrzej Siewior]

Daniel,

could you give those a two chance? In my host-mode testing the perfomance of
 dd if=/dev/null of=/dev/sda2 bs=4096 count=4
went from 
 16384 bytes (164 MB) copied, 12.2608 s, 13.4 MB/s
to
 16384 bytes (164 MB) copied, 8.80694 s, 18.6 MB/s

If you keep lowering the timer as you do now you can remove the timer and
just poll for the register :)

Sebastian

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

[PATCH 1/2] usb: musb: musb_cppi41: recognize HS devices in hostmode

[Sebastian Andrzej Siewior]

There is a poll loop for max 25us for HS devices. Now guess what, I
tested it in gadget mode and forgot about the little detail. Nobody seem
to have it noticed…
This patch adds the missing logic for hostmode so it is recognized in
host and device mode properly.

Signed-off-by: Sebastian Andrzej Siewior 
---
 drivers/usb/musb/musb_cppi41.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index acdfb3e68a90..d16b7561cce4 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -252,6 +252,7 @@ static void cppi41_dma_callback(void *private_data)
cppi41_trans_done(cppi41_channel);
} else {
struct cppi41_dma_controller *controller;
+   int is_hs = 0;
/*
 * On AM335x it has been observed that the TX interrupt fires
 * too early that means the TXFIFO is not yet empty but the DMA
@@ -264,7 +265,14 @@ static void cppi41_dma_callback(void *private_data)
 */
controller = cppi41_channel->controller;
 
-   if (musb->g.speed == USB_SPEED_HIGH) {
+   if (is_host_active(musb)) {
+   if (musb->port1_status & USB_PORT_STAT_HIGH_SPEED)
+   is_hs = 1;
+   } else {
+   if (musb->g.speed == USB_SPEED_HIGH)
+   is_hs = 1;
+   }
+   if (is_hs) {
unsigned wait = 25;
 
do {
-- 
2.1.1

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

[PATCH 2/2] usb: musb: musb_cppi41: revert to old timer poll intervals

[Sebastian Andrzej Siewior]

Commit 50aea6fca ("usb: musb: cppi41: fire hrtimer according to
programmed channel length") altered the hrtimer intervals and tried to
make it better for ISOC. This patch reverts those changes and here is
why:
- Daniel said that for his ISOC case a timer interval of 3 us would be
  best. This should be handled now in the previous commit ("usb: musb:
  musb_cppi41: recognize HS devices in hostmode") where we poll for up
  to 25us before we setup a timer.

- the patch took total_len / 10 for the total delay. This isn't really
  what should be done. According to my understanding (how the  HW would
  work) is that the DMA engine feeds packet_size bytes into MUSB and
  then triggers the transfer. This is repeated over and over until
  ->total_len is transferred. That means upon DMA interrupt we need to
  transfer the remaining 512 bytes (assuming that is our max packet)
  in the worst case scenario.
  With a USB Storage request size of 64KiB (not uncommon) the timer is
  programmed with a delay of ~6.5ms while the completion of the transfer
  could happen in as little as a few micro seconds.

Here is an example from the usb-storage:
|usb-storage  3459.798879: cppi41_dma_channel_program: len = 65536
|-0 3459.929518: cppi41_dma_callback:
The interrupt arrived ~131ms later.
|-0 3459.938388: cppi41_trans_done:
The transfer completed approx 9ms later.

The DMA transfer itself took ~131ms. USB could send the data quicker but
since the device on the other side was not fast enough it kept sending
NAKs. Now imagine, the DMA engine transferred the last 512 bytes and
raised the interrupt. Now MUSB would be pleased to send the remaining few
bytes but since the device is sending NAKs, it has to wait.
With a re-try of 50us we check three times that often for such "long
standing" conditions.
I've been testing with a USB-disk and I haven't needed the hrtimer at
all (the 25us was enough). The sdcards on the other hand needed the
timer more often. Here I noticed hardly a difference. Even with the
retry of 50us it jumped between 5.8 MiB/sec and 4.9MiB/sec.

Cc: Daniel Mack 
Cc: Sebastian Reimers 
Cc: Sven Neumann 
Signed-off-by: Sebastian Andrzej Siewior 
---
 drivers/usb/musb/musb_cppi41.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index 4aceb35dea4a..87b0ca0786d7 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -199,7 +199,7 @@ static enum hrtimer_restart cppi41_recheck_tx_req(struct 
hrtimer *timer)
if (!list_empty(&controller->early_tx_list)) {
ret = HRTIMER_RESTART;
hrtimer_forward_now(&controller->early_tx,
-   ktime_set(0, 50 * NSEC_PER_USEC));
+   ktime_set(0, 150 * NSEC_PER_USEC));
}

spin_unlock_irqrestore(&musb->lock, flags);
@@ -282,9 +282,8 @@ static void cppi41_dma_callback(void *private_data)
&controller->early_tx_list);

if (!hrtimer_active(&controller->early_tx)) {
-   unsigned long usecs = cppi41_channel->total_len / 10;
hrtimer_start_range_ns(&controller->early_tx,
-   ktime_set(0, usecs * NSEC_PER_USEC),
+   ktime_set(0, 140 * NSEC_PER_USEC),
40 * NSEC_PER_USEC,
HRTIMER_MODE_REL);
}
--
2.1.1
---
 drivers/usb/musb/musb_cppi41.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index d16b7561cce4..355f0dac9f0f 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -212,7 +212,7 @@ static enum hrtimer_restart cppi41_recheck_tx_req(struct 
hrtimer *timer)
if (!list_empty(&controller->early_tx_list)) {
ret = HRTIMER_RESTART;
hrtimer_forward_now(&controller->early_tx,
-   ktime_set(0, 20 * NSEC_PER_USEC));
+   ktime_set(0, 150 * NSEC_PER_USEC));
}
 
spin_unlock_irqrestore(&musb->lock, flags);
@@ -293,14 +293,11 @@ static void cppi41_dma_callback(void *private_data)
}
list_add_tail(&cppi41_channel->tx_check,
&controller->early_tx_list);
-   if (!hrtimer_is_queued(&controller->early_tx)) {
-   unsigned long usecs = cppi41_channel->total_len / 10;
-
+   if (!hrtimer_is_queued(&controller->early_tx))
hrtimer_start_range_ns(&controller->early_tx,
-   ktime_set(0, usecs * NSEC_PER_USEC),
+   ktime_set(0, 130 * NSEC_PER_USEC),
20 * NSEC_PER_USEC,
HRTIMER_MODE_REL);
-  

Re: [PATCH 2/2] usb: musb: musb_cppi41: revert to old timer poll intervals

[Sebastian Andrzej Siewior]

On 10/31/2014 10:36 PM, Sebastian Andrzej Siewior wrote:
> diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
> index d16b7561cce4..355f0dac9f0f 100644
> --- a/drivers/usb/musb/musb_cppi41.c
> +++ b/drivers/usb/musb/musb_cppi41.c
> @@ -212,7 +212,7 @@ static enum hrtimer_restart cppi41_recheck_tx_req(struct 
> hrtimer *timer)
>   if (!list_empty(&controller->early_tx_list)) {
>   ret = HRTIMER_RESTART;
>   hrtimer_forward_now(&controller->early_tx,
> - ktime_set(0, 20 * NSEC_PER_USEC));
> + ktime_set(0, 150 * NSEC_PER_USEC));
>   }
>  
>   spin_unlock_irqrestore(&musb->lock, flags);
> @@ -293,14 +293,11 @@ static void cppi41_dma_callback(void *private_data)
>   }
>   list_add_tail(&cppi41_channel->tx_check,
>   &controller->early_tx_list);
> - if (!hrtimer_is_queued(&controller->early_tx)) {
> - unsigned long usecs = cppi41_channel->total_len / 10;
> -
> + if (!hrtimer_is_queued(&controller->early_tx))
>   hrtimer_start_range_ns(&controller->early_tx,
> - ktime_set(0, usecs * NSEC_PER_USEC),
> + ktime_set(0, 130 * NSEC_PER_USEC),
>   20 * NSEC_PER_USEC,
>   HRTIMER_MODE_REL);
> - }
>   }
>  out:
>   spin_unlock_irqrestore(&musb->lock, flags);
> 

sending patches after 6pm on a Friday. This is the correct hunk :)

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

Re: [PATCH 1/2] usb: musb: musb_cppi41: recognize HS devices in hostmode

[Sergei Shtylyov]

Hello.

On 11/01/2014 12:36 AM, Sebastian Andrzej Siewior wrote:


There is a poll loop for max 25us for HS devices. Now guess what, I
tested it in gadget mode and forgot about the little detail. Nobody seem
to have it noticed…
This patch adds the missing logic for hostmode so it is recognized in
host and device mode properly.



Signed-off-by: Sebastian Andrzej Siewior 
---
  drivers/usb/musb/musb_cppi41.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)



diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index acdfb3e68a90..d16b7561cce4 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c

[...]

@@ -264,7 +265,14 @@ static void cppi41_dma_callback(void *private_data)
 */
controller = cppi41_channel->controller;

-   if (musb->g.speed == USB_SPEED_HIGH) {
+   if (is_host_active(musb)) {
+   if (musb->port1_status & USB_PORT_STAT_HIGH_SPEED)
+   is_hs = 1;


   Indent with tabs, not spaces please...


+   } else {
+   if (musb->g.speed == USB_SPEED_HIGH)
+   is_hs = 1;


   ... like here.


+   }
+   if (is_hs) {


WBR, Sergei

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

Re: bugreport: huawei_cdc_ncm control device freezes for 3-5 minutes on connect with E3276 LTE modem

[Aleksander Morgado]

On Fri, Oct 3, 2014 at 10:01 AM, Erik Alapää  wrote:
> Problem: When connecting to a Huawei E3276 LTE modem using
> 'AT+CGACT=1,1' in minicom over /dev/cdc-wdm1, the cdc-wdm device
> freezes for 3-5 minutes until accepting AT commands again.
>
> Keywords: huawei_cdc_ncm, LTE, AT commands, cdc-wdm
>
> Detailed problem description:
>
> I am using a 4G mobile USB dongle with the huawei_cdc_ncm driver in
> Linux kernel 3.16. In general, the driver works well, but one major
> issue is that bringing the modem up using 'AT+CGACT=1.1' freezes the
> /dev/cdc-wdm1 control device for 3-5 minutes. After that, the device
> accepts more commands over minicom. Note that I do get connectivity,
> directly after the CGACT I can get a DHCP address for wwan0 and the
> bandwidth is approx 20 Mbit/s downstream and 6 Mbit/s upstream.
>
> I have tried building a custom 3.16 kernel with a few printk:s in
> cdc_ncm.c and huawei_cdc_ncm.c, but found nothing suspicious.
>
> Kernel version (from /proc/version): 3.16
> Environment: Thinkpad L440 64-bit x86 (Intel Core i5-4200M cpu) laptop
> with Kubuntu 14.04.1 LTS
> Kernel modules: huawei_cdc_ncm,cdc_ncm
>
> Workaround: Bring up the device with
> AT^NDISDUP=1,1,"internet.telenor.se" instead. Also worth noting is
> that AT+CGACT=1,1 does not freeze the control connection if using
> /dev/ttyUSB0.


Regardless of the actual issue in the kernel driver, if any, NDISDUP
in the cdc-wdm device is the way to go to connect that modem.

-- 
Aleksander
https://aleksander.es
--
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 : add support for HuiJia USB Gamepad connector (0e8f:1006 and 0e8f:3010)

[Prédhomme Philippe]

Create each gamepad as a separate joystick
Both device (1006 is for Sega Saturn controllers, 3010 is for Sony
Playstation 1/2 controllers) work the same as 0e8f:3013 (which is for
Nintendo 64 controllers), so i used this device as reference to make
my patch.
Work with kernel 3.14, 3.15, 3.16, 3.17.

Signed-off-by: Philippe Prédhomme 

diff -git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -362,6 +362,8 @@

 #define USB_VENDOR_ID_GREENASIA 0x0e8f
 #define USB_DEVICE_ID_GREENASIA_DUAL_USB_JOYPAD 0x3013
+#define USB_DEVICE_ID_GREENASIA_DUAL_SS_JOYPAD 0x1006
+#define USB_DEVICE_ID_GREENASIA_DUAL_PS_JOYPAD 0x3010

 #define USB_VENDOR_ID_GRETAGMACBETH 0x0971
 #define USB_DEVICE_ID_GRETAGMACBETH_HUEY 0x2005
diff -git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -50,6 +50,8 @@ static const struct hid_blacklist {
  { USB_VENDOR_ID_EMS, USB_DEVICE_ID_EMS_TRIO_LINKER_PLUS_II,
HID_QUIRK_MULTI_INPUT },
  { USB_VENDOR_ID_ETURBOTOUCH, USB_DEVICE_ID_ETURBOTOUCH,
HID_QUIRK_MULTI_INPUT },
  { USB_VENDOR_ID_GREENASIA, USB_DEVICE_ID_GREENASIA_DUAL_USB_JOYPAD,
HID_QUIRK_MULTI_INPUT },
+ { USB_VENDOR_ID_GREENASIA, USB_DEVICE_ID_GREENASIA_DUAL_SS_JOYPAD,
HID_QUIRK_MULTI_INPUT },
+ { USB_VENDOR_ID_GREENASIA, USB_DEVICE_ID_GREENASIA_DUAL_PS_JOYPAD,
HID_QUIRK_MULTI_INPUT },
  { USB_VENDOR_ID_PANTHERLORD,
USB_DEVICE_ID_PANTHERLORD_TWIN_USB_JOYSTICK, HID_QUIRK_MULTI_INPUT |
HID_QUIRK_SKIP_OUTPUT_REPORTS },
  { USB_VENDOR_ID_PLAYDOTCOM, USB_DEVICE_ID_PLAYDOTCOM_EMS_USBII,
HID_QUIRK_MULTI_INPUT },
  { USB_VENDOR_ID_TOUCHPACK, USB_DEVICE_ID_TOUCHPACK_RTS,
HID_QUIRK_MULTI_INPUT },
--
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