RE: [PATCH v2 2/7] usb: phy: dsps: adding usbphy driver for am33xx platform

[B, Ravi]

 +
 +  res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "phy_wkup");
 +  phy->phy_wkup = ioremap(res->start, resource_size(res));

>>> devm_ioremap?

>> The phy_wakeup register is common across two instances of phy, 
>> devm_ioremap_resource() will fail to map for twice for same register space.

>   I've already told you the register can't be shared between devices like 
> this.
>  BTW, you haven't replied to my request concerning your /proc/iomem 
> contents... 

I have missed that specific mail. The /proc/iomem does show this common 
register. As you suggest to create a third device for this shared register? I 
agree it can be done. 
Initially I thought this should be part of control module, but do we have 
control module frame work for every SoC(am335x)?
Every SoC has many such shared register to handle control/status logic for Soc 
specific IP(s)? 
If we create separate device node for each such registers, this will end up in 
adding more files to kernel. 

We should create single control module node for each SoC,

cm: control_module@44e1 {
compatible = "ti,dsps-usbphy";
reg = 0x44e10648 0x4
 
   0x44e10XXX 0x4
>
reg-names = "phy_wkup", "mmc_control", , 
;
id = <0>;
};
Have common control module APIs to control these registers, can be used by 
other driver modules. 

--
Ravi B
--
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/7] usb: phy: dsps: adding usbphy driver for am33xx platform

[B, Ravi]

Typo.. corrected
"The /proc/iomem does not show this common register"

-Original Message-
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] 
On Behalf Of B, Ravi
Sent: Wednesday, June 12, 2013 12:51 PM
To: Sergei Shtylyov
Cc: ABRAHAM, KISHON VIJAY; linux-usb@vger.kernel.org; 
linux-ker...@vger.kernel.org; Balbi, Felipe
Subject: RE: [PATCH v2 2/7] usb: phy: dsps: adding usbphy driver for am33xx 
platform

 +
 +  res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "phy_wkup");
 +  phy->phy_wkup = ioremap(res->start, resource_size(res));

>>> devm_ioremap?

>> The phy_wakeup register is common across two instances of phy, 
>> devm_ioremap_resource() will fail to map for twice for same register space.

>   I've already told you the register can't be shared between devices like 
> this.
>  BTW, you haven't replied to my request concerning your /proc/iomem 
> contents... 

I have missed that specific mail. The /proc/iomem does not show this common 
register. As you suggest to create a third device for this shared register? I 
agree it can be done. 
Initially I thought this should be part of control module, but do we have 
control module frame work for every SoC(am335x)?
Every SoC has many such shared register to handle control/status logic for Soc 
specific IP(s)? 
If we create separate device node for each such registers, this will end up in 
adding more files to kernel. 

We should create single control module node for each SoC,

cm: control_module@44e1 {
compatible = "ti,dsps-usbphy";
reg = 0x44e10648 0x4
 
   0x44e10XXX 0x4
>
reg-names = "phy_wkup", "mmc_control", , 
;
id = <0>;
};
Have common control module APIs to control these registers, can be used by 
other driver modules. 

--
Ravi B
--
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
--
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: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context

[Thomas Gleixner]

On Wed, 12 Jun 2013, Ming Lei wrote:
> On Wed, Jun 12, 2013 at 3:10 AM, Alan Stern  wrote:
> >> Also the tasklet running in CPU0 can handle the work which should
> >> have been done by the same tasket scheduled in CPU1,  so we can
> >> avoid busy-waitting in CPU1 which may be introduced by tasklet_schedule()
> >> in CPU1.
> >
> > Or you could have a separate tasklet for each host controller.
> 
> Yes, but I will compare tasklet with interrupt threaded handler first.

Yes, please. I read through the thread and I really recommend that you
get rid of the tasklet. tasklets are a complete disaster by design and
we really should make efforts to get rid of the last users instead of
trying to work around their semantical shortcomings.

Thanks,

tglx
--
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: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context

[Oliver Neukum]

On Tuesday 11 June 2013 15:10:03 Alan Stern wrote:
> In order to prevent this from happening, you would have to change the
> spin_lock() call in the completion handler to spin_lock_irqsave().  
> Furthermore, you will have to audit every USB driver to make sure that
> all the completion handlers get fixed.

Yes. However, it can be done mechanically. And we know only
the handlers for complete need to be fixed.

Regards
Oliver

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

[PATCH v2 2/3] usb: dwc3: omap: Intialize the register offset values for OMAP5 and AM437x

[George Cherian]

This patch Initializes the register offset values depending
on the X_MAJOR of USBOTGSS_REVISION register. Also adds register
offset defines and new debug register defines.

X_MAJOR is 2 for both OMAP5 and AM437x. But both have different glue register
layout. Differentiate AM437x using dt compatible.
Register offsets are cached in dwc3_omap struct for reg reads and writes.

Signed-off-by: George Cherian 
---
 drivers/usb/dwc3/dwc3-omap.c | 57 
 1 file changed, 57 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index a354b4c..f204d18 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -61,21 +61,38 @@
 #define USBOTGSS_REVISION  0x
 #define USBOTGSS_SYSCONFIG 0x0010
 #define USBOTGSS_IRQ_EOI   0x0020
+#define USBOTGSS_EOI_OFFSET0x0008
 #define USBOTGSS_IRQSTATUS_RAW_0   0x0024
 #define USBOTGSS_IRQSTATUS_0   0x0028
 #define USBOTGSS_IRQENABLE_SET_0   0x002c
 #define USBOTGSS_IRQENABLE_CLR_0   0x0030
+#define USBOTGSS_IRQ0_OFFSET   0x0004
 #define USBOTGSS_IRQSTATUS_RAW_1   0x0034
 #define USBOTGSS_IRQSTATUS_1   0x0038
 #define USBOTGSS_IRQENABLE_SET_1   0x003c
 #define USBOTGSS_IRQENABLE_CLR_1   0x0040
+#define USBOTGSS_IRQSTATUS_EOI_MISC0x0030
+#define USBOTGSS_IRQSTATUS_RAW_MISC0x0034
+#define USBOTGSS_IRQSTATUS_MISC0x0038
+#define USBOTGSS_IRQENABLE_SET_MISC0x003c
+#define USBOTGSS_IRQENABLE_CLR_MISC0x0040
+#define USBOTGSS_IRQMISC_OFFSET0x03fc
 #define USBOTGSS_UTMI_OTG_CTRL 0x0080
 #define USBOTGSS_UTMI_OTG_STATUS   0x0084
+#define USBOTGSS_UTMI_OTG_OFFSET   0x0480
+#define USBOTGSS_TXFIFO_DEPTH  0x0508
+#define USBOTGSS_RXFIFO_DEPTH  0x050c
 #define USBOTGSS_MMRAM_OFFSET  0x0100
 #define USBOTGSS_FLADJ 0x0104
 #define USBOTGSS_DEBUG_CFG 0x0108
 #define USBOTGSS_DEBUG_DATA0x010c
+#define USBOTGSS_DEV_EBC_EN0x0110
+#define USBOTGSS_DEBUG_OFFSET  0x0600
 
+/* REVISION REGISTER */
+#define USBOTGSS_REVISION_XMAJOR(reg)  ((reg >> 8) & 0x7)
+#define USBOTGSS_REVISION_XMAJOR1  1
+#define USBOTGSS_REVISION_XMAJOR2  2
 /* SYSCONFIG REGISTER */
 #define USBOTGSS_SYSCONFIG_DMADISABLE  (1 << 16)
 
@@ -300,6 +317,7 @@ static int dwc3_omap_probe(struct platform_device *pdev)
int irq;
 
int utmi_mode = 0;
+   int x_major;
 
u32 reg;
 
@@ -356,6 +374,42 @@ static int dwc3_omap_probe(struct platform_device *pdev)
return ret;
}
 
+   reg = dwc3_omap_readl(omap->base, USBOTGSS_REVISION);
+   omap->revision = reg;
+   x_major = USBOTGSS_REVISION_XMAJOR(reg);
+
+   /* Differentiate between OMAP5,AM437x and others*/
+   switch (x_major) {
+   case USBOTGSS_REVISION_XMAJOR1:
+   case USBOTGSS_REVISION_XMAJOR2:
+   omap->irq_eoi_offset = 0;
+   omap->irq0_offset = 0;
+   omap->irqmisc_offset = 0;
+   omap->utmi_otg_offset = 0;
+   omap->debug_offset = 0;
+   break;
+   default:
+   /* Default to the latest revision */
+   omap->irq_eoi_offset = USBOTGSS_EOI_OFFSET;
+   omap->irq0_offset = USBOTGSS_IRQ0_OFFSET;
+   omap->irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
+   omap->utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
+   omap->debug_offset = USBOTGSS_DEBUG_OFFSET;
+   break;
+   }
+
+   /* For OMAP5(ES2.0) and AM437x x_major is 2 even though there are
+* changes in wrapper registers, Using dt compatible for aegis
+*/
+
+   if (of_device_is_compatible(node, "ti,am437x-dwc3")) {
+   omap->irq_eoi_offset = USBOTGSS_EOI_OFFSET;
+   omap->irq0_offset = USBOTGSS_IRQ0_OFFSET;
+   omap->irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
+   omap->utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
+   omap->debug_offset = USBOTGSS_DEBUG_OFFSET;
+   }
+
reg = dwc3_omap_readl(omap->base, USBOTGSS_UTMI_OTG_STATUS);
 
of_property_read_u32(node, "utmi-mode", &utmi_mode);
@@ -412,6 +466,9 @@ static const struct of_device_id of_dwc3_match[] = {
{
.compatible =   "ti,dwc3"
},
+   {
+   .compatible =   "ti,am437x-dwc3"
+   },
{ },
 };
 MODULE_DEVICE_TABLE(of, of_dwc3_match);
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-us

[PATCH v2 3/3] usb: dwc3: omap: Adds dwc3_omap_readl/writel wrappers

[George Cherian]

This patch adds wrappers to dwc3_omap_readl/writel calls to accomodate
both OMAP5 and AM437x reg maps (It uses the cached register offsets).
Also renames OMAP5 IRQ1 as IRQMISC and IRQ1 bits as IRQMISC bits.

Signed-off-by: George Cherian 
---
 drivers/usb/dwc3/dwc3-omap.c | 173 +--
 1 file changed, 116 insertions(+), 57 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index f204d18..4f565d7 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -67,10 +67,18 @@
 #define USBOTGSS_IRQENABLE_SET_0   0x002c
 #define USBOTGSS_IRQENABLE_CLR_0   0x0030
 #define USBOTGSS_IRQ0_OFFSET   0x0004
-#define USBOTGSS_IRQSTATUS_RAW_1   0x0034
-#define USBOTGSS_IRQSTATUS_1   0x0038
-#define USBOTGSS_IRQENABLE_SET_1   0x003c
-#define USBOTGSS_IRQENABLE_CLR_1   0x0040
+#define USBOTGSS_IRQSTATUS_RAW_1   0x0030
+#define USBOTGSS_IRQSTATUS_1   0x0034
+#define USBOTGSS_IRQENABLE_SET_1   0x0038
+#define USBOTGSS_IRQENABLE_CLR_1   0x003c
+#define USBOTGSS_IRQSTATUS_RAW_2   0x0040
+#define USBOTGSS_IRQSTATUS_2   0x0044
+#define USBOTGSS_IRQENABLE_SET_2   0x0048
+#define USBOTGSS_IRQENABLE_CLR_2   0x004c
+#define USBOTGSS_IRQSTATUS_RAW_3   0x0050
+#define USBOTGSS_IRQSTATUS_3   0x0054
+#define USBOTGSS_IRQENABLE_SET_3   0x0058
+#define USBOTGSS_IRQENABLE_CLR_3   0x005c
 #define USBOTGSS_IRQSTATUS_EOI_MISC0x0030
 #define USBOTGSS_IRQSTATUS_RAW_MISC0x0034
 #define USBOTGSS_IRQSTATUS_MISC0x0038
@@ -102,17 +110,17 @@
 /* IRQS0 BITS */
 #define USBOTGSS_IRQO_COREIRQ_ST   (1 << 0)
 
-/* IRQ1 BITS */
-#define USBOTGSS_IRQ1_DMADISABLECLR(1 << 17)
-#define USBOTGSS_IRQ1_OEVT (1 << 16)
-#define USBOTGSS_IRQ1_DRVVBUS_RISE (1 << 13)
-#define USBOTGSS_IRQ1_CHRGVBUS_RISE(1 << 12)
-#define USBOTGSS_IRQ1_DISCHRGVBUS_RISE (1 << 11)
-#define USBOTGSS_IRQ1_IDPULLUP_RISE(1 << 8)
-#define USBOTGSS_IRQ1_DRVVBUS_FALL (1 << 5)
-#define USBOTGSS_IRQ1_CHRGVBUS_FALL(1 << 4)
-#define USBOTGSS_IRQ1_DISCHRGVBUS_FALL (1 << 3)
-#define USBOTGSS_IRQ1_IDPULLUP_FALL(1 << 0)
+/* IRQMISC BITS */
+#define USBOTGSS_IRQMISC_DMADISABLECLR (1 << 17)
+#define USBOTGSS_IRQMISC_OEVT  (1 << 16)
+#define USBOTGSS_IRQMISC_DRVVBUS_RISE  (1 << 13)
+#define USBOTGSS_IRQMISC_CHRGVBUS_RISE (1 << 12)
+#define USBOTGSS_IRQMISC_DISCHRGVBUS_RISE  (1 << 11)
+#define USBOTGSS_IRQMISC_IDPULLUP_RISE (1 << 8)
+#define USBOTGSS_IRQMISC_DRVVBUS_FALL  (1 << 5)
+#define USBOTGSS_IRQMISC_CHRGVBUS_FALL (1 << 4)
+#define USBOTGSS_IRQMISC_DISCHRGVBUS_FALL  (1 << 3)
+#define USBOTGSS_IRQMISC_IDPULLUP_FALL (1 << 0)
 
 /* UTMI_OTG_CTRL REGISTER */
 #define USBOTGSS_UTMI_OTG_CTRL_DRVVBUS (1 << 5)
@@ -161,6 +169,58 @@ static inline void dwc3_omap_writel(void __iomem *base, 
u32 offset, u32 value)
writel(value, base + offset);
 }
 
+static u32 dwc3_omap_read_utmi_status(struct dwc3_omap *omap)
+{
+   return dwc3_omap_readl(omap->base, USBOTGSS_UTMI_OTG_STATUS +
+   omap->utmi_otg_offset);
+}
+
+static void dwc3_omap_write_utmi_status(struct dwc3_omap *omap, u32 value)
+{
+   dwc3_omap_writel(omap->base, USBOTGSS_UTMI_OTG_STATUS +
+   omap->utmi_otg_offset, value);
+
+}
+
+static u32 dwc3_omap_read_irq0_status(struct dwc3_omap *omap)
+{
+   return dwc3_omap_readl(omap->base, USBOTGSS_IRQSTATUS_0 -
+   omap->irq0_offset);
+}
+
+static void dwc3_omap_write_irq0_status(struct dwc3_omap *omap, u32 value)
+{
+   dwc3_omap_writel(omap->base, USBOTGSS_IRQSTATUS_0 -
+   omap->irq0_offset, value);
+
+}
+
+static u32 dwc3_omap_read_irqmisc_status(struct dwc3_omap *omap)
+{
+   return dwc3_omap_readl(omap->base, USBOTGSS_IRQSTATUS_MISC +
+   omap->irqmisc_offset);
+}
+
+static void dwc3_omap_write_irqmisc_status(struct dwc3_omap *omap, u32 value)
+{
+   dwc3_omap_writel(omap->base, USBOTGSS_IRQSTATUS_MISC +
+   omap->irqmisc_offset, value);
+
+}
+
+static void dwc3_omap_write_irqmisc_set(struct dwc3_omap *omap, u32 value)
+{
+   dwc3_omap_writel(omap->base, USBOTGSS_IRQENABLE_SET_MISC +
+   omap->irqmisc_offset, value);
+
+}
+
+static void dwc3_omap_write_irq0_set(struct dwc3_omap *omap, u32 value)
+{
+   dwc3_omap_writel(omap->base, USBOTGSS_IRQENABLE_SET_0 -
+ 

[PATCH v2 1/3] usb: dwc3: omap: Adding am437x specific register map changes

[George Cherian]

AM437x and OMAP5 dwc3 subsytem have different register map.
Major differences are as follows.

OMAP5 has one main interrupt and one misc interrupt
Aegis has four main interrupts and one misc interrupt.

Miscellanous Interrupt offsets are changed.
UTMI OTG Control and Status Registers offsets are changed.
DEBUG Configuration and Status Registers are changed.

The main intend of the patch is to re-use the same wrapper driver
for both OMAP5 and AM437x, by using the x_major in revision
register and adjusting the offsets.

This patch adds the register map offsets and adds offset variables
in struct dwc3_omap to cache the offsets

Signed-off-by: George Cherian 
---
 drivers/usb/dwc3/dwc3-omap.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 34638b9..a354b4c 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -122,6 +122,12 @@ struct dwc3_omap {
void __iomem*base;
 
u32 utmi_otg_status;
+   u32 utmi_otg_offset;
+   u32 irqmisc_offset;
+   u32 irq_eoi_offset;
+   u32 debug_offset;
+   u32 irq0_offset;
+   u32 revision;
 
u32 dma_status:1;
 };
-- 
1.8.1.4

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

[PATCH v2 0/3] Adding AM437x support to dwc3-omap glue

[George Cherian]

Initial patch set to add support for dwc3 in am437x platform.
This patch series addresses the regiter map differences between
OMAP5 and AM437x, to re-use the same driver.

AM437x and OMAP5 dwc3 subsytem have different register map.
Major differences are as follows.

OMAP5 has one main interrupt and one misc interrupt
Aegis has four main interrupts and one misc interrupt.

Miscellanous Interrupt offsets are changed.
UTMI OTG Control and Status Registers offsets are changed.
DEBUG Configuration and Status Registers are changed.

The main intend of the patch is to re-use the same wrapper driver
for both OMAP5 and AM437x, by using the x_major in revision
register and adjusting the offsets.

changes from v1:
- Added compatible for AM437X since x_major is same for OMAP5 and AM437x
- Added proper wrappers to dwc3_omap_readl/writel 


George Cherian (3):
  usb: dwc3: omap: Adding am437x specific register map changes
  usb: dwc3: omap: Intialize the register offset values for OMAP5 and
AM437x
  usb: dwc3: omap: Adds dwc3_omap_readl/writel wrappers

 drivers/usb/dwc3/dwc3-omap.c | 234 ---
 1 file changed, 178 insertions(+), 56 deletions(-)

-- 
1.8.1.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: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context

[Ming Lei]

On Wed, Jun 12, 2013 at 5:11 PM, Oliver Neukum  wrote:
> On Tuesday 11 June 2013 15:10:03 Alan Stern wrote:
>> In order to prevent this from happening, you would have to change the
>> spin_lock() call in the completion handler to spin_lock_irqsave().
>> Furthermore, you will have to audit every USB driver to make sure that
>> all the completion handlers get fixed.
>
> Yes. However, it can be done mechanically. And we know only
> the handlers for complete need to be fixed.

I am wondering if the change is needed since timer function is still
run in softirq context instead of hard irq.

Looks Alan concerned that one USB interface driver may have another
hard interrupt handler involved. Is there such kind of USB driver/device
in tree?

Thanks,
--
Ming
--
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: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context

[Oliver Neukum]

On Wednesday 12 June 2013 18:11:34 Ming Lei wrote:
> On Wed, Jun 12, 2013 at 5:11 PM, Oliver Neukum  wrote:
> > On Tuesday 11 June 2013 15:10:03 Alan Stern wrote:
> >> In order to prevent this from happening, you would have to change the
> >> spin_lock() call in the completion handler to spin_lock_irqsave().
> >> Furthermore, you will have to audit every USB driver to make sure that
> >> all the completion handlers get fixed.
> >
> > Yes. However, it can be done mechanically. And we know only
> > the handlers for complete need to be fixed.
> 
> I am wondering if the change is needed since timer function is still
> run in softirq context instead of hard irq.
> 
> Looks Alan concerned that one USB interface driver may have another
> hard interrupt handler involved. Is there such kind of USB driver/device
> in tree?

No. Suppose a USB network driver.
The complete() handler is written on the assumption that interrupts are off.
So it takes a spinlock from the network subsystem. It does so with spin_lock()

Other network drivers also take the lock. And they may take it from an IRQ 
handler.
If such an IRQ interrupts the tasklet complete() is running in, the CPU will 
deadlock.

The danger is not interrupt handlers in the same driver but IRQ handlers of 
_other_
drivers (PCI, ...) a lock is shared with.

You need to go through all USB drivers and change every spin_lock() that goes
for a lock that is exported to a spin_lock_irqsave()

Regards
Oliver

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

Re: MUSB multiplatform work?

[Vinod Koul]

On Thu, May 30, 2013 at 11:19:33PM +0200, Linus Walleij wrote:
> On Thu, May 30, 2013 at 10:31 PM, Tony Lindgren  wrote:
> 
> > There are many devices where the device FIFO is memory mapped to the
> > GPMC bus on omaps, like TUSB, OneNAND, smc911x etc. I believe the
> > only reason why these have not been converted to the dmaengine is
> > the fact that dmaengine cannot configure the DMA hardware to do
> > autoincrement and loop over the device FIFO.
> 
> OK that seems like something pretty generic that we could just add
> to the struct dma_slave_config actually, something like:
> 
> u32 src_fifoloop;
> u32 dst_fifoloop;
Yes for genric but not for loop. For most of our cases we are considering the
FIFO address as a constant. Typically DMA controllers have this ability to
perform incremental/decremental/constant FIFO address.

What would make sense to have is:

enum dmaengine_slave_addr_mode {
DMAENGINE_SLAVE_ADDR_CONSTANT = 0,
DMAENGINE_SLAVE_ADDR_INCREMANT,
DMAENGINE_SLAVE_ADDR_DECREMENT,
};

and add these to struct dma_slave_config:
enum dmaengine_slave_addr_mode src_mode;
enum dmaengine_slave_addr_mode dstn_mode;

For loopover we can have:
u32 loop_counter;

on 0 means no loop, and valid value tells when to loopover (offset).

will this help for all of the above controllers and their conversion?
 
> Given in # of words on the src/dst address simply, left as zero
> for hitting a constant address over and over again.
> 
> We'd need both to make space for device->device transfers.
> 
> If this is all that is needed to convert them do DMAengine
> I'd surely ACK it (FWIW).

--
~Vinod
--
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: serial/ftdi_sio byte loss / performance regression

[Johan Hovold]

> > a37025b USB: ftdi_sio: fix chars_in_buffer overhead
> > c413364 USB: ftdi_sio: clean up get_modem_status
> > dcf0105 USB: serial: add generic wait_until_sent implementation
> > 
> > These three are also needed in 3.9 (and also 3.8).
> 
> I have these three. 3.8-stable is dead as far as I'm concerned, so I
> can't do anything about it :)

Yeah, I know. I just put it in parenthesis for reference. Feels like
every kernel version is being picked up by someone these days. :)

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: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context

[Ming Lei]

On Wed, Jun 12, 2013 at 6:19 PM, Oliver Neukum  wrote:
> On Wednesday 12 June 2013 18:11:34 Ming Lei wrote:
>> On Wed, Jun 12, 2013 at 5:11 PM, Oliver Neukum  wrote:
>> > On Tuesday 11 June 2013 15:10:03 Alan Stern wrote:
>> >> In order to prevent this from happening, you would have to change the
>> >> spin_lock() call in the completion handler to spin_lock_irqsave().
>> >> Furthermore, you will have to audit every USB driver to make sure that
>> >> all the completion handlers get fixed.
>> >
>> > Yes. However, it can be done mechanically. And we know only
>> > the handlers for complete need to be fixed.
>>
>> I am wondering if the change is needed since timer function is still
>> run in softirq context instead of hard irq.
>>
>> Looks Alan concerned that one USB interface driver may have another
>> hard interrupt handler involved. Is there such kind of USB driver/device
>> in tree?
>
> No. Suppose a USB network driver.
> The complete() handler is written on the assumption that interrupts are off.
> So it takes a spinlock from the network subsystem. It does so with spin_lock()

Looks I misses the case, but IMO, it might not be very common, generally
subsystem provides API for drivers to do something(handle rx/report tx) inside
complete(), and seldom exports subsystem-wide lock directly to drivers.
API has no context info, and should have called spin_lock_irqrestore().

>
> Other network drivers also take the lock. And they may take it from an IRQ 
> handler.
> If such an IRQ interrupts the tasklet complete() is running in, the CPU will 
> deadlock.

Looks no usbnet drivers hold subsystem(network) locks in its complete().
Both the locks held are per device/per skb list. In usbnet_bh(), there
is one, eg.
netif_rx(), which is a API and disables local IRQ.

>
> The danger is not interrupt handlers in the same driver but IRQ handlers of 
> _other_
> drivers (PCI, ...) a lock is shared with.

Right, so generally drivers which spin_lock(subsystem lock) in complete()
might be affected.

>
> You need to go through all USB drivers and change every spin_lock() that goes
> for a lock that is exported to a spin_lock_irqsave()

Yes, that is the safest way.

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

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

> The usbmon trace shows lots of errors.  All those -75 (EOVERFLOW)
> status codes mean that the gadget sent a packet that was too large,
> i.e., more than 512 bytes.  This happened in all the READ(10) commands
> except the last one -- none of them succeeded in transferring any data.
>
> After the last READ(10) command was sent, the usbmon trace shows that
> the host's USB port got disabled.  Maybe because of the too-long
> packets.  Whatever the reason, that's why the ESHUTDOWN error occurred.
>
> The gadget's log does indeed show that the last READ(10) was received
> twice.  The second time is a bug in the UDC driver.  No command was
> sent by the host, so the driver should not have reported that a command
> was received.
>
> Alan Stern
>

I did another usbmon capture from the moment usb cable is plugged into
the Ubuntu x100e laptop. This time the usbmon does not have -75 error.
When the SCSI_READ_10 command request for 4096 bytes of data, and the
data is returned by the gadget, usbmon simply shows -108 error. The
gadget driver log and usbmon trace are attached.

The FIFO size in gadget bulk out endpoint 1 is 512 bytes, so i break
the 4096 bytes of data into 8 chunks of 512 bytes, before returning
them to Ubuntu. I guess it would not be the root cause, won't it?

thanks,
victor
# dmesg -c
g_file_storage gadget: disconnect or port reset
handle_exception begin
handle_exception wait until
handle_exception old_state 5
g_file_storage gadget: in handle_exception loop
g_file_storage gadget: in fsg->running loop
g_file_storage gadget: disconnect or port reset
handle_exception begin
handle_exception wait until
handle_exception old_state 5
g_file_storage gadget: in handle_exception loop
g_file_storage gadget: in fsg->running loop
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 40 00
g_file_storage gadget: get device descriptor
ept0 in queue len 0x12, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 18:
: 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02
0010: 00 01
g_file_storage gadget: disconnect or port reset
handle_exception begin
handle_exception wait until
handle_exception old_state 5
g_file_storage gadget: in handle_exception loop
g_file_storage gadget: in fsg->running loop
USB_RECIP_DEVICE
fa is 0x2
exit A
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 12 00
g_file_storage gadget: get device descriptor
ept0 in queue len 0x12, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 18:
: 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02
0010: 00 01
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 06 00 00 0a 00
g_file_storage gadget: get device qualifier
ept0 in queue len 0xa, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 10:
: 0a 06 00 02 00 00 00 40 01 00
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 02 00 00 09 00
g_file_storage gadget: get configuration descriptor
ept0 in queue len 0x9, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 9:
: 09 02 20 00 01 01 04 c0 01
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 02 00 00 20 00
g_file_storage gadget: get configuration descriptor
ept0 in queue len 0x20, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 32:
: 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 08 06
0010: 50 05 07 05 81 02 00 02 00 07 05 01 02 00 02 01
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 03 00 00 ff 00
g_file_storage gadget: get string descriptor
ept0 in queue len 0x4, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 4:
: 04 03 09 04
g_file_storage gadget: ep0-setup, length 8:
: 80 06 02 03 09 04 ff 00
g_file_storage gadget: get string descriptor
ept0 in queue len 0x36, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 54:
: 36 03 46 00 69 00 6c 00 65 00 2d 00 62 00 61 00
0010: 63 00 6b 00 65 00 64 00 20 00 53 00 74 00 6f 00
0020: 72 00 61 00 67 00 65 00 20 00 47 00 61 00 64 00
0030: 67 00 65 00 74 00
g_file_storage gadget: ep0-setup, length 8:
: 80 06 01 03 09 04 ff 00
g_file_storage gadget: get string descriptor
ept0 in queue len 0x3a, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 58:
: 3a 03 4c 00 69 00 6e 00 75 00 78 00 20 00 33 00
0010: 2e 00 34 00 2e 00 34 00 2b 00 20 00 77 00 69 00
0020: 74 00 68 00 20 00 6b 00 61 00 67 00 65 00 6e 00
0030: 32 00 5f 00 75 00 73 00 62 00
g_file_storage gadget: ep0-setup, length 8:
: 00 09 01 00 00 00 00 00
g_file_storage gadget: set configuration
handle_exception begin
handle_exception wait until
handle_exception old_state 4
g_file_storage gadget: set interface 0
g_file_storage gadget: high-speed config #1
g_file_storage gadget: ep0-setup, length 8:
: 80 06 04 03 09 04 ff 00
g_file_storage gadget: get string descriptor
ept0 in queue len 0x1a, buffer 0xc12

Re: MUSB multiplatform work?

[Jassi Brar]

On 12 June 2013 15:35, Vinod Koul  wrote:
> On Thu, May 30, 2013 at 11:19:33PM +0200, Linus Walleij wrote:
>> On Thu, May 30, 2013 at 10:31 PM, Tony Lindgren  wrote:
>>
>> > There are many devices where the device FIFO is memory mapped to the
>> > GPMC bus on omaps, like TUSB, OneNAND, smc911x etc. I believe the
>> > only reason why these have not been converted to the dmaengine is
>> > the fact that dmaengine cannot configure the DMA hardware to do
>> > autoincrement and loop over the device FIFO.
>>
>> OK that seems like something pretty generic that we could just add
>> to the struct dma_slave_config actually, something like:
>>
>> u32 src_fifoloop;
>> u32 dst_fifoloop;
> Yes for genric but not for loop. For most of our cases we are considering the
> FIFO address as a constant. Typically DMA controllers have this ability to
> perform incremental/decremental/constant FIFO address.
>
> What would make sense to have is:
>
> enum dmaengine_slave_addr_mode {
> DMAENGINE_SLAVE_ADDR_CONSTANT = 0,
> DMAENGINE_SLAVE_ADDR_INCREMANT,
> DMAENGINE_SLAVE_ADDR_DECREMENT,
> };
>
> and add these to struct dma_slave_config:
> enum dmaengine_slave_addr_mode src_mode;
> enum dmaengine_slave_addr_mode dstn_mode;
>
> For loopover we can have:
> u32 loop_counter;
>
> on 0 means no loop, and valid value tells when to loopover (offset).
>
> will this help for all of the above controllers and their conversion?
>
IIRC,  TI's Sundaram Raju proposed a TI specific api to DMAEngine for
this very purpose, which was generalized into
device_prep_interleaved_dma().  Which I think should already be enough
to serve the purpose. Is it not?

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

Re: [PATCH 1/3] usb: chipidea: add CSR SiRFSoC ci13xxx usb driver

[Andy Shevchenko]

On Sun, Jun 9, 2013 at 6:25 AM, Barry Song <21cn...@gmail.com> wrote:
> CSR SiRF SoCs licensed chipidea ci13xxx USB IP, this patch
> makes the chipidea drivers support CSR SiRF SoCS.
>
> It also changes the Kconfig, only compile MSM and IMX if related
> drivers are enabled. Otherwise, we always need to enable all
> clients of chipidea drivers.

> +   /* 5. set device dma mask */
> +   if (!pdev->dev.dma_mask) {
> +   pdev->dev.dma_mask = devm_kzalloc(&pdev->dev,
> + sizeof(*pdev->dev.dma_mask), 
> GFP_KERNEL);
> +   if (!pdev->dev.dma_mask) {
> +   dev_err(&pdev->dev, "Failed to alloc dma_mask!\n");
> +   ret = -ENOMEM;
> +   goto err;
> +   }
> +   *pdev->dev.dma_mask = DMA_BIT_MASK(32);
> +   dma_set_coherent_mask(&pdev->dev, *pdev->dev.dma_mask);

Perhaps you could avoid this allocation if you apply coherent mask
first and its address will be used as dma_mask value.

> +   }

> +err:
> +   clk_disable_unprepare(data->clk);
> +   return ret;

Please, check, but if I remember correctly devm_clk* is doing this for
you on release stage.

> +static int ci13xxx_sirf_remove(struct platform_device *pdev)
> +{
> +   struct ci13xxx_sirf_data *data = platform_get_drvdata(pdev);
> +
> +   pm_runtime_disable(&pdev->dev);
> +   ci13xxx_remove_device(data->ci_pdev);
> +
> +   clk_disable_unprepare(data->clk);

Ditto.

--
With Best Regards,
Andy Shevchenko
--
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: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context

[Alan Stern]

On Wed, 12 Jun 2013, Ming Lei wrote:

> If not, I am wondering why one USB driver need register another hard
> interrupt handler? Could you share such examples? I understand the
> case only exists with timer handler as discussed with Oliver, don't I?

Here's another possibility.  A USB driver has a private lock, and it
acquires this lock in its completion handler.  But it also acquires
this lock in other routines, and those other routines may be called by
other drivers or subsystems in interrupt context.

> > The drivers _do_ need to be changed, as explained above.  And that
> > explanation was only one failure scenario.  There may be others.
> 
> OK, I'd like to know what the others are? :-)

Me too.  :-)

> >> And finally, USB HCDs themselves will benefit from the change, won't they?
> >
> > How will they benefit?  Merely from not releasing their private locks?
> 
> The interrupt of one HCD will be responded lately since another HCD's
> interrupt handler takes very long time. With the change, the problem can
> be avoided.

For reasonably sophisticated host controllers like EHCI, the delay in
responding to an interrupt doesn't matter much.  But for simpler host
controllers (for example, those using PIO instead of DMA) it matters
more, so those other HCDs will benefit more from the conversion.

> >> Compared with "usb-storage" task's schedule latency, the tasklet
> >> schedule delay should be lower at most of situations since the tasklet
> >> is scheduled inside irq handler.
> >
> > True.  But the two latencies add.
> 
> I think it should be one tasklet latency added, but what is the other one?

I meant that the latency in tasklet scheduling has to be added to the 
latency in scheduling the usb-storage thread.

> > Or you could have a separate tasklet for each host controller.
> 
> Yes, but I will compare tasklet with interrupt threaded handler first.

Switching to a threaded interrupt handler offers more possibilities.  
Instead of moving just the givebacks to the thread, we could put almost 
all the processing there.  (At least, we can for ehci-hcd.  Other HCDs 
may not be able to do this.)

At this point we are talking about multiple changes:

Moving the givebacks to a tasklet or threaded handler.

Changing the USB completion handlers so that they can be called 
with interrupts enabled.

Allowing the tasklet/thread to run with interrupts enabled.

Moving more of the HCD processing into the tasklet/thread.

Maybe other things too.  In principle, the first and second items can 
be done simultaneously.

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 05/10] USB: EHCI: make ehci-atmel a separate driver

[Jean-Christophe PLAGNIOL-VILLARD]

On 23:04 Thu 07 Feb , manjunath.gou...@linaro.org wrote:
> From: Manjunath Goudar 
> 
> Separate the Atmel host controller driver from ehci-hcd host code
> into its own driver module.
> 
> Signed-off-by: Manjunath Goudar 
> Cc: Alan Stern 
> Cc: Greg KH 
> Cc: Grant Likely 
> Cc: Rob Herring 
> Cc: Andrew Victor 
> Cc: Nicolas Ferre 
> Cc: Jean-Christophe Plagniol-Villard 
> Cc: linux-usb@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
Acked-by: Jean-Christophe PLAGNIOL-VILLARD 

Best Regards,
J.
> ---
>  drivers/usb/host/Kconfig  |7 
>  drivers/usb/host/Makefile |1 +
>  drivers/usb/host/ehci-atmel.c |   78 
> ++---
>  drivers/usb/host/ehci-hcd.c   |6 +---
>  4 files changed, 51 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 3689b7b..5a13f9d 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -176,6 +176,13 @@ config USB_EHCI_HCD_ORION
>  ---help---
>Enables support for the on-chip EHCI controller on
>Morvell Orion chips.
> +config USB_EHCI_HCD_AT91
> +tristate  "Support for Atmel on-chip EHCI USB controller"
> +depends on USB_EHCI_HCD && ARCH_AT91
> +default y
> +---help---
> +  Enables support for the on-chip EHCI controller on
> +  Atmel chips.
>  
>  config USB_EHCI_MSM
>   bool "Support for MSM on-chip EHCI USB controller"
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index 23b07dd..96b4839 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -31,6 +31,7 @@ obj-$(CONFIG_USB_EHCI_HCD_OMAP) += ehci-omap.o
>  obj-$(CONFIG_USB_EHCI_HCD_SPEAR)+= ehci-spear.o
>  obj-$(CONFIG_USB_EHCI_HCD_ORION)+= ehci-orion.o
>  obj-$(CONFIG_USB_OXU210HP_HCD)   += oxu210hp-hcd.o
> +obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
>  obj-$(CONFIG_USB_ISP116X_HCD)+= isp116x-hcd.o
>  obj-$(CONFIG_USB_ISP1362_HCD)+= isp1362-hcd.o
>  obj-$(CONFIG_USB_OHCI_HCD)   += ohci-hcd.o
> diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
> index 27639487..2f06711 100644
> --- a/drivers/usb/host/ehci-atmel.c
> +++ b/drivers/usb/host/ehci-atmel.c
> @@ -15,6 +15,19 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "ehci.h"
> +
> +#define DRIVER_DESC "EHCI atmel driver"
> +
> +static const char hcd_name[] = "ehci-atmel";
> +static struct hc_driver __read_mostly ehci_atmel_hc_driver;
>  
>  /* interface and function clocks */
>  static struct clk *iclk, *fclk;
> @@ -60,41 +73,6 @@ static int ehci_atmel_setup(struct usb_hcd *hcd)
>   return ehci_setup(hcd);
>  }
>  
> -static const struct hc_driver ehci_atmel_hc_driver = {
> - .description= hcd_name,
> - .product_desc   = "Atmel EHCI UHP HS",
> - .hcd_priv_size  = sizeof(struct ehci_hcd),
> -
> - /* generic hardware linkage */
> - .irq= ehci_irq,
> - .flags  = HCD_MEMORY | HCD_USB2,
> -
> - /* basic lifecycle operations */
> - .reset  = ehci_atmel_setup,
> - .start  = ehci_run,
> - .stop   = ehci_stop,
> - .shutdown   = ehci_shutdown,
> -
> - /* managing i/o requests and associated device resources */
> - .urb_enqueue= ehci_urb_enqueue,
> - .urb_dequeue= ehci_urb_dequeue,
> - .endpoint_disable   = ehci_endpoint_disable,
> - .endpoint_reset = ehci_endpoint_reset,
> -
> - /* scheduling support */
> - .get_frame_number   = ehci_get_frame,
> -
> - /* root hub support */
> - .hub_status_data= ehci_hub_status_data,
> - .hub_control= ehci_hub_control,
> - .bus_suspend= ehci_bus_suspend,
> - .bus_resume = ehci_bus_resume,
> - .relinquish_port= ehci_relinquish_port,
> - .port_handed_over   = ehci_port_handed_over,
> -
> - .clear_tt_buffer_complete   = ehci_clear_tt_buffer_complete,
> -};
> -
>  static u64 at91_ehci_dma_mask = DMA_BIT_MASK(32);
>  
>  static int ehci_atmel_drv_probe(struct platform_device *pdev)
> @@ -210,7 +188,35 @@ static struct platform_driver ehci_atmel_driver = {
>   .remove = ehci_atmel_drv_remove,
>   .shutdown   = usb_hcd_platform_shutdown,
>   .driver = {
> - .name   = "atmel-ehci",
> + .name   = hcd_name,
>   .of_match_table = of_match_ptr(atmel_ehci_dt_ids),
>   },
>  };
> +
> +static const struct ehci_driver_overrides atmel_overrides __initdata = {
> + .reset = ehci_atmel_setup,
> +};
> +
> +static int __init ehci_atmel_init(void)
> +{
> + if (usb_disabled())
> + return -ENODEV;
> +
> + pr_info("%s: " DRIVER_DESC "\n", hcd_name);
> + ehci_

Re: [PATCH V3 2/7] usb: phy: add MODULE_LICENSE to phy-tegra-usb.c

[Felipe Balbi]

On Wed, Jun 05, 2013 at 02:03:04PM -0600, Stephen Warren wrote:
> From: Stephen Warren 
> 
> When this file is built as a module, it needs a MODULE_LICENSE in order
> to access many exported symbols.
> 
> Signed-off-by: Stephen Warren 
> Acked-by: Arnd Bergmann 

Acked-by: Felipe Balbi 

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH V3 1/7] usb: phy: export ulpi_viewport_access_ops

[Felipe Balbi]

On Wed, Jun 05, 2013 at 02:03:03PM -0600, Stephen Warren wrote:
> From: Manjunath Goudar 
> 
> In order to build a ULPI PHY driver as a module, this symbol needs to
> be exported.
> 
> Signed-off-by: Manjunath Goudar 
> [swarren, reworked Manjunath's patches to split them more logically]
> Signed-off-by: Stephen Warren 
> Acked-by: Arnd Bergmann 

This should go straight through Greg:

Acked-by: Felipe Balbi 

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC PATCH 32/50] usb: gadget: at91_udc: prepare clk before calling enable

[Felipe Balbi]

On Fri, Jun 07, 2013 at 08:08:18PM +0200, Boris BREZILLON wrote:
> Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
> avoid common clk framework warnings.
> 
> Signed-off-by: Boris BREZILLON 

Acked-by: Felipe Balbi 

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context

[Oliver Neukum]

On Wednesday 12 June 2013 10:35:44 Alan Stern wrote:
> On Wed, 12 Jun 2013, Ming Lei wrote:
> 
> > If not, I am wondering why one USB driver need register another hard
> > interrupt handler? Could you share such examples? I understand the
> > case only exists with timer handler as discussed with Oliver, don't I?
> 
> Here's another possibility.  A USB driver has a private lock, and it
> acquires this lock in its completion handler.  But it also acquires
> this lock in other routines, and those other routines may be called by
> other drivers or subsystems in interrupt context.

That is fatal. But again mechanically using _irqsave in complete()
does the job. No other place can be affected.

Regards
Oliver

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

Re: [PATCH] usb/gadget: Add options to build only functions modules

[Felipe Balbi]

On Mon, Apr 29, 2013 at 12:39:56PM +0200, Andrzej Pietrasiewicz wrote:
> A USB "gadget" can be set up entirely through configfs.
> This patch adds options to build the USB functions' modules
> without building "old" gadget modules, e.g. build
> usb_f_acm.ko or usb_f_ecm.ko, but not g_cdc.ko.
> 
> Please see:
> 
> http://www.spinics.net/lists/linux-usb/msg83460.html
> http://www.spinics.net/lists/linux-usb/msg85065.html
> http://www.spinics.net/lists/linux-usb/msg85156.html
> 
> for what functions are already available through configfs;
> so far the equivalents of g_serial, g_ncm and g_cdc can be set up
> through configfs. Please note, that the actual gadget composition
> can consist of any functions available, not just those available
> in a given "old" g_xx.ko gadget. That is, one can take
> some functions found in g_serial, some in g_ncm and some in g_cdc,
> e.g. such a gadget can consist of acm, generic serial, obex and ecm, 
> functions,
> while the g_serial consists of acm, generic serial, obex, the g_ncm
> consists of ncm and g_cdc consists of acm and ecm. The concept
> is illustrated in the table below, taking into account the currently
> available configfs support:
> 
> ---
>| gadget   |
>|---
> function   | g_serial |  g_ncm   |  g_cdc   | set up through configfs |
> ---
> acm| *|  | *|o|
> generic serial | *|  |  |o|
> obex   | *|  |  |o|
> ncm|  | *|  |o|
> ecm|  |  | *|o|
>|  |  |  | |
> 
>.   .  .  .  . .
>.   .  .  .  . .
>.   .  .  .  . .
> 
><< more functions to come >>
> 
>.   .  .  .  . .
>.   .  .  .  . .
>.   .  .  .  . .
> ---
> "*" - built-in, mandatory, no other functions possible
> "o" - option
> 
> So one can create, using only mkdir/echo/ln from shell, a gadget which 
> provides
> e.g. acm, generic serial, obex and ecm without adding and compiling a new
> g_serial_with_ecm.c.
> 
> A documentation file is added to Documentation/usb.
> 
> Function's attributes are described in
> 
> Documentation/ABI/*/configfs-usb-gadget*
> 
> The latter might need adjusting the "KernelVersion" and "Date" tags.
> 
> Signed-off-by: Andrzej Pietrasiewicz 
> Signed-off-by: Kyungmin Park 

Doesn't apply and there are trailing whitespaces in a few places. This
will be delayed for v3.12, sorry.

-- 
balbi


signature.asc
Description: Digital signature

Re: Linux USB file storage gadget with new UDC

[Alan Stern]

On Wed, 12 Jun 2013, victor yeo wrote:

> I did another usbmon capture from the moment usb cable is plugged into
> the Ubuntu x100e laptop. This time the usbmon does not have -75 error.
> When the SCSI_READ_10 command request for 4096 bytes of data, and the
> data is returned by the gadget, usbmon simply shows -108 error. The
> gadget driver log and usbmon trace are attached.

Again, the -108 indicates that the host controller disabled the port.  
The usbmon trace confirms this.  I think the most common reason for 
disabling a port in this way is that the device tried to transmit a 
packet across a microframe boundary.

> The FIFO size in gadget bulk out endpoint 1 is 512 bytes, so i break
> the 4096 bytes of data into 8 chunks of 512 bytes, before returning
> them to Ubuntu. I guess it would not be the root cause, won't it?

It's hard to say without looking at the signals on the wire.  Are you
certain the hardware really is sending 512 bytes for each chunk?  
That's why you need to use a bus analyzer -- to see what's actually
going on.

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 2/3] USB: OMAP: add omap-otg

[Felipe Balbi]

Hi,

On Mon, Jun 10, 2013 at 01:40:05AM +0300, Aaro Koskinen wrote:
> +void omap_otg_set_mode(enum omap_otg_mode mode)
> +{
> + if (!otg_dev) {
> + WARN(1, "%s: controller not present\n", __func__);
> + return;
> + }
> + mutex_lock(&otg_dev->serialize);
> + switch (mode) {
> + case OMAP_OTG_MODE_DEVICE:
> + /*
> +  * Set B-session valid.
> +  */
> + omap_otg_ctrl(OMAP_OTG_ID | OMAP_OTG_BSESSVLD);
> + break;
> + case OMAP_OTG_MODE_HOST:
> + /*
> +  * Set A-session valid.
> +  */
> + omap_otg_ctrl(OMAP_OTG_ASESSVLD);
> + break;
> + case OMAP_OTG_MODE_DISCONNECT:
> + /*
> +  * Set B-session end to indicate no VBUS.
> +  */
> + omap_otg_ctrl(OMAP_OTG_ID | OMAP_OTG_BSESSEND);
> + break;
> + default:
> + WARN(1, "%s: unknown mode: %d\n", __func__, mode);
> + }
> + mutex_unlock(&otg_dev->serialize);
> +}
> +EXPORT_SYMBOL_GPL(omap_otg_set_mode);

looks like this should provide a extcon interface for its users.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH 04/10] USB: OHCI: Properly handle ohci-ep93xx suspend

[Manjunath Goudar]

Suspend scenario in case of ohci-ep93xx glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_hcd_ep93xx_drv_suspend() will ensure proper
handling of suspend scenario.

Signed-off-by: Manjunath Goudar 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/host/ohci-ep93xx.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index 8704e9f..7c77f61 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -174,13 +174,17 @@ static int ohci_hcd_ep93xx_drv_suspend(struct 
platform_device *pdev, pm_message_
 {
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+   bool do_wakeup = device_may_wakeup(&pdev->dev);
+   int ret;
+
+   ret = ohci_suspend(hcd, do_wakeup);
 
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
ohci->next_statechange = jiffies;
 
ep93xx_stop_hc(&pdev->dev);
-   return 0;
+   return ret;
 }
 
 static int ohci_hcd_ep93xx_drv_resume(struct platform_device *pdev)
-- 
1.7.9.5

--
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 05/10] USB: OHCI: Properly handle ohci-exynos suspend

[Manjunath Goudar]

Suspend scenario in case of ohci-exynos glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in exynos_ohci_suspend() will ensure proper
handling of suspend scenario.

Signed-off-by: Manjunath Goudar 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/host/ohci-exynos.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 6ff830c..6ad38ee 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -203,6 +203,7 @@ static int exynos_ohci_suspend(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct platform_device *pdev = to_platform_device(dev);
+   bool do_wakeup = device_may_wakeup(dev);
unsigned long flags;
int rc = 0;
 
@@ -226,6 +227,8 @@ static int exynos_ohci_suspend(struct device *dev)
 
exynos_ohci_phy_disable(pdev);
 
+   rc = ohci_suspend(hcd, do_wakeup);
+
clk_disable_unprepare(exynos_ohci->clk);
 
 fail:
-- 
1.7.9.5

--
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 02/10] USB: OHCI: Properly handle ohci-s3c2410 suspend

[Manjunath Goudar]

Suspend scenario in case of ohci-s3c2410 glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_hcd_s3c2410_drv_suspend() will ensure
proper handling of suspend scenario.

Signed-off-by: Manjunath Goudar 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/host/ohci-s3c2410.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index 8018bb1..2ffa693 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -430,6 +430,7 @@ static int ohci_hcd_s3c2410_drv_suspend(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
unsigned long flags;
int rc = 0;
+   bool do_wakeup = device_may_wakeup(dev);
 
/*
 * Root hub was already suspended. Disable irq emission and
@@ -445,6 +446,8 @@ static int ohci_hcd_s3c2410_drv_suspend(struct device *dev)
 
clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
 
+   rc = ohci_suspend(hcd, do_wakeup);
+
s3c2410_stop_hc(pdev);
 bail:
spin_unlock_irqrestore(&ohci->lock, flags);
-- 
1.7.9.5

--
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 03/10] USB: OHCI: Properly handle ohci-da8xx suspend

[Manjunath Goudar]

Suspend scenario in case of ohci-da8xx glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_da8xx_suspend() will ensure proper
handling of suspend scenario.

Signed-off-by: Manjunath Goudar 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/host/ohci-da8xx.c |   13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 6aaa9c9..3b1d9bd 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -406,19 +406,24 @@ static int ohci_hcd_da8xx_drv_remove(struct 
platform_device *dev)
 }
 
 #ifdef CONFIG_PM
-static int ohci_da8xx_suspend(struct platform_device *dev, pm_message_t 
message)
+static int ohci_da8xx_suspend(struct platform_device *pdev,
+   pm_message_t message)
 {
-   struct usb_hcd  *hcd= platform_get_drvdata(dev);
+   struct usb_hcd  *hcd= platform_get_drvdata(pdev);
struct ohci_hcd *ohci   = hcd_to_ohci(hcd);
+   bool do_wakeup = device_may_wakeup(&pdev->dev);
+   int ret;
 
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
ohci->next_statechange = jiffies;
 
+   ret = ohci_suspend(hcd, do_wakeup);
+
ohci_da8xx_clock(0);
hcd->state = HC_STATE_SUSPENDED;
-   dev->dev.power.power_state = PMSG_SUSPEND;
-   return 0;
+   pdev->dev.power.power_state = PMSG_SUSPEND;
+   return ret;
 }
 
 static int ohci_da8xx_resume(struct platform_device *dev)
-- 
1.7.9.5

--
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 00/10] USB: OHCI:Properly handle ohci_suspend()routine in bus glue

[Manjunath Goudar]

Suspend scenario in case of ohci bus glue was not properly handled as 
it was not suspending generic part of ohci controller. Calling 
explicitly the ohci_suspend()routine will ensure proper handling 
of suspend scenario.
 
Manjunath Goudar (10):
  USB: OHCI: Properly handle ohci-at91 suspend
  USB: OHCI: Properly handle ohci-s3c2410 suspend
  USB: OHCI: Properly handle ohci-da8xx suspend
  USB: OHCI: Properly handle ohci-ep93xx suspend
  USB: OHCI: Properly handle ohci-exynos suspend
  USB: OHCI: Properly handle ohci-omap suspend
  USB: OHCI: Properly handle ohci-platform suspend
  USB: OHCI: Properly handle ohci-pxa27x suspend
  USB: OHCI: Properly handle ohci-sm501 suspend
  USB: OHCI: Properly handle ohci-spear suspend

 drivers/usb/host/ohci-at91.c |8 ++--
 drivers/usb/host/ohci-da8xx.c|   13 +
 drivers/usb/host/ohci-ep93xx.c   |6 +-
 drivers/usb/host/ohci-exynos.c   |3 +++
 drivers/usb/host/ohci-omap.c |   11 ---
 drivers/usb/host/ohci-platform.c |6 +-
 drivers/usb/host/ohci-pxa27x.c   |6 +-
 drivers/usb/host/ohci-s3c2410.c  |3 +++
 drivers/usb/host/ohci-sm501.c|9 +++--
 drivers/usb/host/ohci-spear.c|   10 +++---
 10 files changed, 58 insertions(+), 17 deletions(-)

-- 
1.7.9.5

--
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 01/10] USB: OHCI: Properly handle ohci-at91 suspend

[Manjunath Goudar]

Suspend scenario in case of ohci-at91 glue was not properly
handled as it was not suspending generic part of ohci controller.
Calling explicitly the ohci_suspend()routine in ohci_hcd_at91_drv_suspend()
will ensure proper handling of suspend scenario.

Signed-off-by: Manjunath Goudar 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/host/ohci-at91.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index fb2f127..28400a7 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -619,8 +619,12 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev, 
pm_message_t mesg)
 {
struct usb_hcd  *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+   bool do_wakeup = device_may_wakeup(&pdev->dev);
+   int ret;
 
-   if (device_may_wakeup(&pdev->dev))
+   ret = ohci_suspend(hcd, do_wakeup);
+
+   if (do_wakeup)
enable_irq_wake(hcd->irq);
 
/*
@@ -637,7 +641,7 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev, 
pm_message_t mesg)
at91_stop_clock();
}
 
-   return 0;
+   return ret;
 }
 
 static int ohci_hcd_at91_drv_resume(struct platform_device *pdev)
-- 
1.7.9.5

--
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 06/10] USB: OHCI: Properly handle ohci-omap suspend

[Manjunath Goudar]

Suspend scenario in case of ohci-omap glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_omap_suspend() will ensure proper
handling of suspend scenario.

Signed-off-by: Manjunath Goudar 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/host/ohci-omap.c |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index b900dba..a638a14 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -423,16 +423,21 @@ static int ohci_hcd_omap_drv_remove(struct 
platform_device *dev)
 
 #ifdef CONFIG_PM
 
-static int ohci_omap_suspend(struct platform_device *dev, pm_message_t message)
+static int ohci_omap_suspend(struct platform_device *pdev, pm_message_t 
message)
 {
-   struct ohci_hcd *ohci = hcd_to_ohci(platform_get_drvdata(dev));
+   struct usb_hcd  *hcd = platform_get_drvdata(pdev);
+   struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+   bool do_wakeup = device_may_wakeup(&pdev->dev);
+   int ret;
 
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
ohci->next_statechange = jiffies;
 
+   ret = ohci_suspend(hcd, do_wakeup);
+
omap_ohci_clock_power(0);
-   return 0;
+   return ret;
 }
 
 static int ohci_omap_resume(struct platform_device *dev)
-- 
1.7.9.5

--
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 08/10] USB: OHCI: Properly handle ohci-pxa27x suspend

[Manjunath Goudar]

Suspend scenario in case of ohci-pxa27x glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_hcd_pxa27x_drv_suspend() will ensure proper
handling of suspend scenario.

Signed-off-by: Manjunath Goudar 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/host/ohci-pxa27x.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index 3a9c01d..9dbfeb8 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -564,13 +564,17 @@ static int ohci_hcd_pxa27x_drv_suspend(struct device *dev)
 {
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct pxa27x_ohci *ohci = to_pxa27x_ohci(hcd);
+   bool do_wakeup = device_may_wakeup(dev);
+   int ret;
 
if (time_before(jiffies, ohci->ohci.next_statechange))
msleep(5);
ohci->ohci.next_statechange = jiffies;
 
+   ret = ohci_suspend(hcd, do_wakeup);
+
pxa27x_stop_hc(ohci, dev);
-   return 0;
+   return ret;
 }
 
 static int ohci_hcd_pxa27x_drv_resume(struct device *dev)
-- 
1.7.9.5

--
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 10/10] USB: OHCI: Properly handle ohci-spear suspend

[Manjunath Goudar]

Suspend scenario in case of ohci-spear glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in spear_ohci_hcd_drv_suspend() will ensure proper
handling of suspend scenario.

Signed-off-by: Manjunath Goudar 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/host/ohci-spear.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ohci-spear.c b/drivers/usb/host/ohci-spear.c
index 31ff3fc..5a843f0 100644
--- a/drivers/usb/host/ohci-spear.c
+++ b/drivers/usb/host/ohci-spear.c
@@ -130,20 +130,24 @@ static int spear_ohci_hcd_drv_remove(struct 
platform_device *pdev)
 }
 
 #if defined(CONFIG_PM)
-static int spear_ohci_hcd_drv_suspend(struct platform_device *dev,
+static int spear_ohci_hcd_drv_suspend(struct platform_device *pdev,
pm_message_t message)
 {
-   struct usb_hcd *hcd = platform_get_drvdata(dev);
+   struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct spear_ohci *sohci_p = to_spear_ohci(hcd);
+   bool do_wakeup = device_may_wakeup(&pdev->dev);
+   int ret;
 
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
ohci->next_statechange = jiffies;
 
+   ret = ohci_suspend(hcd, do_wakeup);
+
clk_disable_unprepare(sohci_p->clk);
 
-   return 0;
+   return ret;
 }
 
 static int spear_ohci_hcd_drv_resume(struct platform_device *dev)
-- 
1.7.9.5

--
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 07/10] USB: OHCI: Properly handle ohci-platform suspend

[Manjunath Goudar]

Suspend scenario in case of ohci-platform glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_platform_suspend() will ensure proper
handling of suspend scenario.

Signed-off-by: Manjunath Goudar 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/host/ohci-platform.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index bc30475..ad8cb3b 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -142,11 +142,15 @@ static int ohci_platform_suspend(struct device *dev)
struct usb_ohci_pdata *pdata = dev->platform_data;
struct platform_device *pdev =
container_of(dev, struct platform_device, dev);
+   bool do_wakeup = device_may_wakeup(dev);
+   int ret;
+
+   ret = ohci_suspend(hcd, do_wakeup);
 
if (pdata->power_suspend)
pdata->power_suspend(pdev);
 
-   return 0;
+   return ret;
 }
 
 static int ohci_platform_resume(struct device *dev)
-- 
1.7.9.5

--
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 09/10] USB: OHCI: Properly handle ohci-sm501 suspend

[Manjunath Goudar]

Suspend scenario in case of ohci-sm501 glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_sm501_suspend() will ensure proper
handling of suspend scenario.

Signed-off-by: Manjunath Goudar 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/host/ohci-sm501.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ohci-sm501.c b/drivers/usb/host/ohci-sm501.c
index d479d5d..f4f2da0 100644
--- a/drivers/usb/host/ohci-sm501.c
+++ b/drivers/usb/host/ohci-sm501.c
@@ -216,14 +216,19 @@ static int ohci_hcd_sm501_drv_remove(struct 
platform_device *pdev)
 static int ohci_sm501_suspend(struct platform_device *pdev, pm_message_t msg)
 {
struct device *dev = &pdev->dev;
-   struct ohci_hcd *ohci = hcd_to_ohci(platform_get_drvdata(pdev));
+   struct usb_hcd  *hcd = platform_get_drvdata(pdev);
+   struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+   bool do_wakeup = device_may_wakeup(dev);
+   int ret;
 
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
ohci->next_statechange = jiffies;
 
+   ret = ohci_suspend(hcd, do_wakeup);
+
sm501_unit_power(dev->parent, SM501_GATE_USB_HOST, 0);
-   return 0;
+   return ret;
 }
 
 static int ohci_sm501_resume(struct platform_device *pdev)
-- 
1.7.9.5

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

[PATCH] usb: dwc3: fix typo in comment of dwc3_ep

[Huang Rui]

Change intervall into interval.

Signed-off-by: Huang Rui 
---
 drivers/usb/dwc3/core.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index b69d322..0fc54cc 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -415,7 +415,7 @@ struct dwc3_event_buffer {
  * @number: endpoint number (1 - 15)
  * @type: set to bmAttributes & USB_ENDPOINT_XFERTYPE_MASK
  * @resource_index: Resource transfer index
- * @interval: the intervall on which the ISOC transfer is started
+ * @interval: the interval on which the ISOC transfer is started
  * @name: a human readable name e.g. ep1out-bulk
  * @direction: true for TX, false for RX
  * @stream_capable: true when streams are enabled
-- 
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 03/10] USB: OHCI: Properly handle ohci-da8xx suspend

[Sergei Shtylyov]

Hello.

On 12-06-2013 19:28, Manjunath Goudar wrote:


Suspend scenario in case of ohci-da8xx glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_da8xx_suspend() will ensure proper
handling of suspend scenario.



Signed-off-by: Manjunath Goudar 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
Cc: linux-usb@vger.kernel.org
---
  drivers/usb/host/ohci-da8xx.c |   13 +
  1 file changed, 9 insertions(+), 4 deletions(-)



diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 6aaa9c9..3b1d9bd 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -406,19 +406,24 @@ static int ohci_hcd_da8xx_drv_remove(struct 
platform_device *dev)
  }

  #ifdef CONFIG_PM
-static int ohci_da8xx_suspend(struct platform_device *dev, pm_message_t 
message)
+static int ohci_da8xx_suspend(struct platform_device *pdev,
+   pm_message_t message)
  {
-   struct usb_hcd  *hcd= platform_get_drvdata(dev);
+   struct usb_hcd  *hcd= platform_get_drvdata(pdev);
struct ohci_hcd *ohci   = hcd_to_ohci(hcd);
+   bool do_wakeup = device_may_wakeup(&pdev->dev);


Could you align = with other intializers above?


+   int ret;



WBR, Sergei

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

[PATCH V2 0/6] USB: OHCI: more bus glues as separate modules

[Manjunath Goudar]

These patches are for separating the SOC On-Chip ohci host controller
from ohci-hcd host code into its own driver module.
This work is part of enabling multi-platform kernels on ARM.

V2:
  In patch 5/6 and 6/6:
  -Set non-standard fields in hc_driver manually, rather than
   relying on an expanded struct ohci_driver_overrides.
  -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than
   relying on ohci_hub_control and hub_status_data being exported.
  -ohci_setup() has been removed because it is called in .reset member
   of the ohci_hc_driver structure.
 
  In patch 1/6 to 4/6
  -ohci_setup() has been removed because it is called in .reset member
   of the ohci_hc_driver structure.

Manjunath Goudar (6):
  USB: OHCI: make ohci-exynos a separate driver
  USB: OHCI: make ohci-omap a separate driver
  USB: OHCI: make ohci-omap3 a separate driver
  USB: OHCI: make ohci-spear a separate driver
  USB: OHCI: make ohci-at91 a separate driver
  USB: OHCI: make ohci-s3c2410 a separate driver

 drivers/usb/host/Kconfig|   30 ++-
 drivers/usb/host/Makefile   |6 ++
 drivers/usb/host/ohci-at91.c|  148 +++---
 drivers/usb/host/ohci-exynos.c  |  167 ---
 drivers/usb/host/ohci-hcd.c |  108 -
 drivers/usb/host/ohci-omap.c|  156 
 drivers/usb/host/ohci-omap3.c   |  120 ++--
 drivers/usb/host/ohci-s3c2410.c |  129 ++
 drivers/usb/host/ohci-spear.c   |  140 +---
 9 files changed, 370 insertions(+), 634 deletions(-)

-- 
1.7.9.5

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

[PATCH V2 3/6] USB: OHCI: make ohci-omap3 a separate driver

[Manjunath Goudar]

Separate the  TI OHCI OMAP3 host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.

V2:
 -ohci_setup() removed because it is called in .reset member
  of the ohci_hc_driver structure.
 -The improper multi-line commenting style written in proper way.
  ('*' characters aligned in vertically).

Signed-off-by: Manjunath Goudar 
Cc: Anand Gadiyar 
Cc: Felipe Balbi 
Cc: Arnd Bergmann 
Cc: Greg KH 
Cc: Alan Stern 
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/host/Kconfig  |2 +-
 drivers/usb/host/Makefile |1 +
 drivers/usb/host/ohci-hcd.c   |   18 ---
 drivers/usb/host/ohci-omap3.c |  120 ++---
 4 files changed, 42 insertions(+), 99 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 7a87c72..db20e43 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -383,7 +383,7 @@ config USB_OHCI_HCD_OMAP1
  Enables support for the OHCI controller on OMAP1/2 chips.
 
 config USB_OHCI_HCD_OMAP3
-   bool "OHCI support for OMAP3 and later chips"
+   tristate "OHCI support for OMAP3 and later chips"
depends on (ARCH_OMAP3 || ARCH_OMAP4)
default y
---help---
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 52f2c44..9f2f5f3 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_USB_OHCI_HCD_PCI)+= ohci-pci.o
 obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)+= ohci-platform.o
 obj-$(CONFIG_USB_OHCI_EXYNOS)  += ohci-exynos.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP1)   += ohci-omap.o
+obj-$(CONFIG_USB_OHCI_HCD_OMAP3)   += ohci-omap3.o
 
 obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 1abc1e7..cad51d2 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1182,11 +1182,6 @@ MODULE_LICENSE ("GPL");
 #define S3C2410_PLATFORM_DRIVERohci_hcd_s3c2410_driver
 #endif
 
-#ifdef CONFIG_USB_OHCI_HCD_OMAP3
-#include "ohci-omap3.c"
-#define OMAP3_PLATFORM_DRIVER  ohci_hcd_omap3_driver
-#endif
-
 #if defined(CONFIG_PXA27x) || defined(CONFIG_PXA3xx)
 #include "ohci-pxa27x.c"
 #define PLATFORM_DRIVERohci_hcd_pxa27x_driver
@@ -1284,12 +1279,6 @@ static int __init ohci_hcd_mod_init(void)
goto error_platform;
 #endif
 
-#ifdef OMAP3_PLATFORM_DRIVER
-   retval = platform_driver_register(&OMAP3_PLATFORM_DRIVER);
-   if (retval < 0)
-   goto error_omap3_platform;
-#endif
-
 #ifdef OF_PLATFORM_DRIVER
retval = platform_driver_register(&OF_PLATFORM_DRIVER);
if (retval < 0)
@@ -1393,10 +1382,6 @@ static int __init ohci_hcd_mod_init(void)
platform_driver_unregister(&OF_PLATFORM_DRIVER);
  error_of_platform:
 #endif
-#ifdef OMAP3_PLATFORM_DRIVER
-   platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
- error_omap3_platform:
-#endif
 #ifdef PLATFORM_DRIVER
platform_driver_unregister(&PLATFORM_DRIVER);
  error_platform:
@@ -1448,9 +1433,6 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef OF_PLATFORM_DRIVER
platform_driver_unregister(&OF_PLATFORM_DRIVER);
 #endif
-#ifdef OMAP3_PLATFORM_DRIVER
-   platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
-#endif
 #ifdef PLATFORM_DRIVER
platform_driver_unregister(&PLATFORM_DRIVER);
 #endif
diff --git a/drivers/usb/host/ohci-omap3.c b/drivers/usb/host/ohci-omap3.c
index 8f71357..b7c75ab 100644
--- a/drivers/usb/host/ohci-omap3.c
+++ b/drivers/usb/host/ohci-omap3.c
@@ -29,90 +29,22 @@
  * - add kernel-doc
  */
 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
-#include 
-#include 
-
-/*-*/
-
-static int ohci_omap3_init(struct usb_hcd *hcd)
-{
-   dev_dbg(hcd->self.controller, "starting OHCI controller\n");
-
-   return ohci_init(hcd_to_ohci(hcd));
-}
-
-/*-*/
-
-static int ohci_omap3_start(struct usb_hcd *hcd)
-{
-   struct ohci_hcd *ohci = hcd_to_ohci(hcd);
-   int ret;
-
-   /*
-* RemoteWakeupConnected has to be set explicitly before
-* calling ohci_run. The reset value of RWC is 0.
-*/
-   ohci->hc_control = OHCI_CTRL_RWC;
-   writel(OHCI_CTRL_RWC, &ohci->regs->control);
+#include 
+#include 
 
-   ret = ohci_run(ohci);
+#include "ohci.h"
 
-   if (ret < 0) {
-   dev_err(hcd->self.controller, "can't start\n");
-   ohci_stop(hcd);
-   }
+#define DRIVER_DESC "OHCI OMAP3 driver"
 
-   return ret;
-}
-
-/*-*/
-
-static const struct hc_driver ohci_omap3_hc_driver = {
-   .descrip

[PATCH V2 2/6] USB: OHCI: make ohci-omap a separate driver

[Manjunath Goudar]

Separate the  TI OHCI OMAP1/2 host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.

V2:
 -omap_ohci_clock_power(0) called in usb_hcd_omap_remove().
 -Removed ohci_setup() call from usb_hcd_omap_probe() and ohci_omap_reset().
 -host_enabled and host_initialized variables aren't used for anything
  thats what removed.

Signed-off-by: Manjunath Goudar 
Cc: Felipe Balbi 
Cc: Arnd Bergmann 
Cc: Greg KH 
Cc: Alan Stern 
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/host/Kconfig |2 +-
 drivers/usb/host/Makefile|1 +
 drivers/usb/host/ohci-hcd.c  |   18 -
 drivers/usb/host/ohci-omap.c |  156 +-
 4 files changed, 51 insertions(+), 126 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 75456f2..7a87c72 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -376,7 +376,7 @@ config USB_OHCI_HCD
 if USB_OHCI_HCD
 
 config USB_OHCI_HCD_OMAP1
-   bool "OHCI support for OMAP1/2 chips"
+   tristate "OHCI support for OMAP1/2 chips"
depends on ARCH_OMAP1
default y
---help---
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index bf4a4b2..52f2c44 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_USB_OHCI_HCD)+= ohci-hcd.o
 obj-$(CONFIG_USB_OHCI_HCD_PCI) += ohci-pci.o
 obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)+= ohci-platform.o
 obj-$(CONFIG_USB_OHCI_EXYNOS)  += ohci-exynos.o
+obj-$(CONFIG_USB_OHCI_HCD_OMAP1)   += ohci-omap.o
 
 obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 2980bb6..1abc1e7 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1182,11 +1182,6 @@ MODULE_LICENSE ("GPL");
 #define S3C2410_PLATFORM_DRIVERohci_hcd_s3c2410_driver
 #endif
 
-#ifdef CONFIG_USB_OHCI_HCD_OMAP1
-#include "ohci-omap.c"
-#define OMAP1_PLATFORM_DRIVER  ohci_hcd_omap_driver
-#endif
-
 #ifdef CONFIG_USB_OHCI_HCD_OMAP3
 #include "ohci-omap3.c"
 #define OMAP3_PLATFORM_DRIVER  ohci_hcd_omap3_driver
@@ -1289,12 +1284,6 @@ static int __init ohci_hcd_mod_init(void)
goto error_platform;
 #endif
 
-#ifdef OMAP1_PLATFORM_DRIVER
-   retval = platform_driver_register(&OMAP1_PLATFORM_DRIVER);
-   if (retval < 0)
-   goto error_omap1_platform;
-#endif
-
 #ifdef OMAP3_PLATFORM_DRIVER
retval = platform_driver_register(&OMAP3_PLATFORM_DRIVER);
if (retval < 0)
@@ -1408,10 +1397,6 @@ static int __init ohci_hcd_mod_init(void)
platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
  error_omap3_platform:
 #endif
-#ifdef OMAP1_PLATFORM_DRIVER
-   platform_driver_unregister(&OMAP1_PLATFORM_DRIVER);
- error_omap1_platform:
-#endif
 #ifdef PLATFORM_DRIVER
platform_driver_unregister(&PLATFORM_DRIVER);
  error_platform:
@@ -1466,9 +1451,6 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef OMAP3_PLATFORM_DRIVER
platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
 #endif
-#ifdef OMAP1_PLATFORM_DRIVER
-   platform_driver_unregister(&OMAP1_PLATFORM_DRIVER);
-#endif
 #ifdef PLATFORM_DRIVER
platform_driver_unregister(&PLATFORM_DRIVER);
 #endif
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index 8747fa6..b900dba 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -14,12 +14,21 @@
  * This file is licenced under the GPL.
  */
 
-#include 
-#include 
-#include 
 #include 
+#include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ohci.h"
 
 #include 
 #include 
@@ -42,10 +51,7 @@
 #define OMAP1510_LB_MMU_RAM_H  0xfffec234
 #define OMAP1510_LB_MMU_RAM_L  0xfffec238
 
-
-#ifndef CONFIG_ARCH_OMAP
-#error "This file is OMAP bus glue.  CONFIG_OMAP must be defined."
-#endif
+#define DRIVER_DESC "OHCI OMAP driver"
 
 #ifdef CONFIG_TPS65010
 #include 
@@ -68,8 +74,9 @@ extern int ocpi_enable(void);
 
 static struct clk *usb_host_ck;
 static struct clk *usb_dc_ck;
-static int host_enabled;
-static int host_initialized;
+
+static const char hcd_name[] = "ohci-omap";
+static struct hc_driver __read_mostly ohci_omap_hc_driver;
 
 static void omap_ohci_clock_power(int on)
 {
@@ -188,21 +195,21 @@ static void start_hnp(struct ohci_hcd *ohci)
 
 /*-*/
 
-static int ohci_omap_init(struct usb_hcd *hcd)
+static int ohci_omap_reset(struct usb_hcd *hcd)
 {
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct omap_usb_config  *config = hcd->self.controller->platform_data;
int need_transceiver = (config->otg != 0);
-   int ret

[PATCH V2 6/6] USB: OHCI: make ohci-s3c2410 a separate driver

[Manjunath Goudar]

Separate the Samsung OHCI S3C host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.

V2:
 -Set non-standard fields in ohci_s3c2410_hc_driver manually, rather than
  relying on an expanded struct ohci_driver_overrides.
 -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than
  relying on ohci_hub_control and hub_status_data being exported.
 -ohci_setup() has been removed because it is called in .reset member
  of the ohci_hc_driver structure.

Signed-off-by: Manjunath Goudar 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/host/Kconfig|8 +++
 drivers/usb/host/Makefile   |1 +
 drivers/usb/host/ohci-hcd.c |   18 --
 drivers/usb/host/ohci-s3c2410.c |  129 ++-
 4 files changed, 67 insertions(+), 89 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index e4dc9ab..0b7b0f7 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -390,6 +390,14 @@ config USB_OHCI_HCD_SPEAR
   Enables support for the on-chip OHCI controller on
   ST SPEAr chips.
 
+config USB_OHCI_HCD_S3C
+tristate "Support for S3C on-chip OHCI USB controller"
+depends on USB_OHCI_HCD && (ARCH_S3C24XX) || (ARCH_S3C64XX)
+default y
+---help---
+  Enables support for the on-chip OHCI controller on
+  S3C chips.
+
 config USB_OHCI_HCD_AT91
 tristate  "Support for Atmel on-chip OHCI USB controller"
 depends on USB_OHCI_HCD && ARCH_AT91
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index f3e02c0..9fa4b3e 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_USB_OHCI_HCD_OMAP1)  += ohci-omap.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP3)   += ohci-omap3.o
 obj-$(CONFIG_USB_OHCI_HCD_SPEAR)   += ohci-spear.o
 obj-$(CONFIG_USB_OHCI_HCD_AT91)+= ohci-at91.o
+obj-$(CONFIG_USB_OHCI_HCD_S3C) += ohci-s3c2410.o
 
 obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index b48c892..b69a49e 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1177,11 +1177,6 @@ MODULE_LICENSE ("GPL");
 #define SA_DRIVER  ohci_hcd_sa_driver
 #endif
 
-#if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S3C64XX)
-#include "ohci-s3c2410.c"
-#define S3C2410_PLATFORM_DRIVERohci_hcd_s3c2410_driver
-#endif
-
 #if defined(CONFIG_PXA27x) || defined(CONFIG_PXA3xx)
 #include "ohci-pxa27x.c"
 #define PLATFORM_DRIVERohci_hcd_pxa27x_driver
@@ -1293,12 +1288,6 @@ static int __init ohci_hcd_mod_init(void)
goto error_tmio;
 #endif
 
-#ifdef S3C2410_PLATFORM_DRIVER
-   retval = platform_driver_register(&S3C2410_PLATFORM_DRIVER);
-   if (retval < 0)
-   goto error_s3c2410;
-#endif
-
 #ifdef EP93XX_PLATFORM_DRIVER
retval = platform_driver_register(&EP93XX_PLATFORM_DRIVER);
if (retval < 0)
@@ -1332,10 +1321,6 @@ static int __init ohci_hcd_mod_init(void)
platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
  error_ep93xx:
 #endif
-#ifdef S3C2410_PLATFORM_DRIVER
-   platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
- error_s3c2410:
-#endif
 #ifdef TMIO_OHCI_DRIVER
platform_driver_unregister(&TMIO_OHCI_DRIVER);
  error_tmio:
@@ -1382,9 +1367,6 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef EP93XX_PLATFORM_DRIVER
platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
 #endif
-#ifdef S3C2410_PLATFORM_DRIVER
-   platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
-#endif
 #ifdef TMIO_OHCI_DRIVER
platform_driver_unregister(&TMIO_OHCI_DRIVER);
 #endif
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index e125770..8018bb1 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -19,17 +19,34 @@
  * This file is licenced under the GPL.
 */
 
-#include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
+
+#include "ohci.h"
+
 
 #define valid_port(idx) ((idx) == 1 || (idx) == 2)
 
 /* clock device associated with the hcd */
 
+
+#define DRIVER_DESC "OHCI S3C driver"
+
+static const char hcd_name[] = "ohci-s3c";
+
 static struct clk *clk;
 static struct clk *usb_clk;
 
+static int (*orig_ohci_hub_control)(struct usb_hcd  *hcd, u16 typeReq, u16 
wValue,
+u16 wIndex, char *buf, u16 wLength);
+static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
+
 /* forward definitions */
 
 static void s3c2410_hcd_oc(struct s3c2410_hcd_info *info, int port_oc);
@@ -93,7 +110,7 @@ ohci_s3c2410_hub_status_data(struct usb_hcd *hcd, ch

[PATCH V2 4/6] USB: OHCI: make ohci-spear a separate driver

[Manjunath Goudar]

Separate the ST OHCI SPEAr host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.

V2:
 -ohci_setup() removed because it is called in .reset member
  of the ohci_hc_driver structure.
 -debugging stuff isn't needed any more that's what removed.

Signed-off-by: Manjunath Goudar 
Cc: Viresh Kumar 
Cc: Arnd Bergmann 
Cc: Greg KH 
Cc: Alan Stern 
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/host/Kconfig  |8 +++
 drivers/usb/host/Makefile |1 +
 drivers/usb/host/ohci-hcd.c   |   18 --
 drivers/usb/host/ohci-spear.c |  140 +
 4 files changed, 65 insertions(+), 102 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index db20e43..46c2f42 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -382,6 +382,14 @@ config USB_OHCI_HCD_OMAP1
---help---
  Enables support for the OHCI controller on OMAP1/2 chips.
 
+config USB_OHCI_HCD_SPEAR
+tristate "Support for ST SPEAr on-chip OHCI USB controller"
+depends on USB_OHCI_HCD && PLAT_SPEAR
+default y
+---help---
+  Enables support for the on-chip OHCI controller on
+  ST SPEAr chips.
+
 config USB_OHCI_HCD_OMAP3
tristate "OHCI support for OMAP3 and later chips"
depends on (ARCH_OMAP3 || ARCH_OMAP4)
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 9f2f5f3..26cb6b3 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)   += ohci-platform.o
 obj-$(CONFIG_USB_OHCI_EXYNOS)  += ohci-exynos.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP1)   += ohci-omap.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP3)   += ohci-omap3.o
+obj-$(CONFIG_USB_OHCI_HCD_SPEAR)   += ohci-spear.o
 
 obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index cad51d2..34ec156 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1212,11 +1212,6 @@ MODULE_LICENSE ("GPL");
 #define OF_PLATFORM_DRIVER ohci_hcd_ppc_of_driver
 #endif
 
-#ifdef CONFIG_PLAT_SPEAR
-#include "ohci-spear.c"
-#define SPEAR_PLATFORM_DRIVER  spear_ohci_hcd_driver
-#endif
-
 #ifdef CONFIG_PPC_PS3
 #include "ohci-ps3.c"
 #define PS3_SYSTEM_BUS_DRIVER  ps3_ohci_driver
@@ -1333,19 +1328,9 @@ static int __init ohci_hcd_mod_init(void)
goto error_davinci;
 #endif
 
-#ifdef SPEAR_PLATFORM_DRIVER
-   retval = platform_driver_register(&SPEAR_PLATFORM_DRIVER);
-   if (retval < 0)
-   goto error_spear;
-#endif
-
return retval;
 
/* Error path */
-#ifdef SPEAR_PLATFORM_DRIVER
-   platform_driver_unregister(&SPEAR_PLATFORM_DRIVER);
- error_spear:
-#endif
 #ifdef DAVINCI_PLATFORM_DRIVER
platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
  error_davinci:
@@ -1403,9 +1388,6 @@ module_init(ohci_hcd_mod_init);
 
 static void __exit ohci_hcd_mod_exit(void)
 {
-#ifdef SPEAR_PLATFORM_DRIVER
-   platform_driver_unregister(&SPEAR_PLATFORM_DRIVER);
-#endif
 #ifdef DAVINCI_PLATFORM_DRIVER
platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
 #endif
diff --git a/drivers/usb/host/ohci-spear.c b/drivers/usb/host/ohci-spear.c
index cc9dd9e..31ff3fc 100644
--- a/drivers/usb/host/ohci-spear.c
+++ b/drivers/usb/host/ohci-spear.c
@@ -11,92 +11,37 @@
 * warranty of any kind, whether express or implied.
 */
 
-#include 
-#include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ohci.h"
 
+#define DRIVER_DESC "OHCI SPEAr driver"
+
+static const char hcd_name[] = "SPEAr-ohci";
 struct spear_ohci {
-   struct ohci_hcd ohci;
struct clk *clk;
 };
 
-#define to_spear_ohci(hcd) (struct spear_ohci *)hcd_to_ohci(hcd)
-
-static void spear_start_ohci(struct spear_ohci *ohci)
-{
-   clk_prepare_enable(ohci->clk);
-}
-
-static void spear_stop_ohci(struct spear_ohci *ohci)
-{
-   clk_disable_unprepare(ohci->clk);
-}
-
-static int ohci_spear_start(struct usb_hcd *hcd)
-{
-   struct ohci_hcd *ohci = hcd_to_ohci(hcd);
-   int ret;
-
-   ret = ohci_init(ohci);
-   if (ret < 0)
-   return ret;
-   ohci->regs = hcd->regs;
-
-   ret = ohci_run(ohci);
-   if (ret < 0) {
-   dev_err(hcd->self.controller, "can't start\n");
-   ohci_stop(hcd);
-   return ret;
-   }
-
-   create_debug_files(ohci);
-
-#ifdef DEBUG
-   ohci_dump(ohci, 1);
-#endif
-   return 0;
-}
-
-static const struct hc_driver ohci_spear_hc_driver = {
-   .description= hcd_name,
-   .product_desc   = "SPEAr OHCI",
-   .hcd_priv_size  = sizeof(struct spear_ohci),
-
-   /* generic hardware linka

[PATCH V2 5/6] USB: OHCI: make ohci-at91 a separate driver

[Manjunath Goudar]

Separate the  TI OHCI Atmel host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.

V2:
 -Set non-standard fields in ohci_at91_hc_driver manually, rather than
  relying on an expanded struct ohci_driver_overrides.
 -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than
  relying on ohci_hub_control and hub_status_data being exported.
 -ohci_setup() has been removed because it is called in .reset member
  of the ohci_hc_driver structure.

Signed-off-by: Manjunath Goudar 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/host/Kconfig |8 +++
 drivers/usb/host/Makefile|1 +
 drivers/usb/host/ohci-at91.c |  148 +++---
 drivers/usb/host/ohci-hcd.c  |   18 -
 4 files changed, 74 insertions(+), 101 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 46c2f42..e4dc9ab 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -390,6 +390,14 @@ config USB_OHCI_HCD_SPEAR
   Enables support for the on-chip OHCI controller on
   ST SPEAr chips.
 
+config USB_OHCI_HCD_AT91
+tristate  "Support for Atmel on-chip OHCI USB controller"
+depends on USB_OHCI_HCD && ARCH_AT91
+default y
+---help---
+  Enables support for the on-chip OHCI controller on
+  Atmel chips.
+
 config USB_OHCI_HCD_OMAP3
tristate "OHCI support for OMAP3 and later chips"
depends on (ARCH_OMAP3 || ARCH_OMAP4)
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 26cb6b3..f3e02c0 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_USB_OHCI_EXYNOS) += ohci-exynos.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP1)   += ohci-omap.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP3)   += ohci-omap3.o
 obj-$(CONFIG_USB_OHCI_HCD_SPEAR)   += ohci-spear.o
+obj-$(CONFIG_USB_OHCI_HCD_AT91)+= ohci-at91.o
 
 obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 2ee1496..fb2f127 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -13,27 +13,41 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
+#include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
 
 #include 
 
-#ifndef CONFIG_ARCH_AT91
-#error "CONFIG_ARCH_AT91 must be defined."
-#endif
+
+#include "ohci.h"
 
 #define valid_port(index)  ((index) >= 0 && (index) < AT91_MAX_USBH_PORTS)
 #define at91_for_each_port(index)  \
for ((index) = 0; (index) < AT91_MAX_USBH_PORTS; (index)++)
 
 /* interface and function clocks; sometimes also an AHB clock */
+
+#define DRIVER_DESC "OHCI Atmel driver"
+
+static const char hcd_name[] = "ohci-atmel";
+
+static struct hc_driver __read_mostly ohci_at91_hc_driver;
 static struct clk *iclk, *fclk, *hclk;
 static int clocked;
+static int (*orig_ohci_hub_control)(struct usb_hcd  *hcd, u16 typeReq, u16 
wValue,
+   u16 wIndex, char *buf, u16 wLength);
+static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
 
 extern int usb_disabled(void);
 
@@ -111,6 +125,8 @@ static void usb_hcd_at91_remove (struct usb_hcd *, struct 
platform_device *);
 static int usb_hcd_at91_probe(const struct hc_driver *driver,
struct platform_device *pdev)
 {
+   struct at91_usbh_data   *board;
+   struct ohci_hcd *ohci;
int retval;
struct usb_hcd *hcd = NULL;
 
@@ -163,8 +179,11 @@ static int usb_hcd_at91_probe(const struct hc_driver 
*driver,
goto err5;
}
 
+   board = hcd->self.controller->platform_data;
+   ohci = hcd_to_ohci(hcd);
+   ohci->num_ports = board->ports;
at91_start_hc(pdev);
-   ohci_hcd_init(hcd_to_ohci(hcd));
+   ohci_setup(hcd);
 
retval = usb_add_hcd(hcd, pdev->resource[1].start, IRQF_SHARED);
if (retval == 0)
@@ -221,36 +240,6 @@ static void usb_hcd_at91_remove(struct usb_hcd *hcd,
 }
 
 /*-*/
-
-static int
-ohci_at91_reset (struct usb_hcd *hcd)
-{
-   struct at91_usbh_data   *board = hcd->self.controller->platform_data;
-   struct ohci_hcd *ohci = hcd_to_ohci (hcd);
-   int ret;
-
-   if ((ret = ohci_init(ohci)) < 0)
-   return ret;
-
-   ohci->num_ports = board->ports;
-   return 0;
-}
-
-static int
-ohci_at91_start (struct usb_hcd *hcd)
-{
-   struct ohci_hcd *ohci = hcd_to_ohci (hcd);
-   int ret;
-
-   if ((ret = ohci_run(ohci)) < 0) {
-   dev_err(hcd->self.controller, "can't start %s\n",
-   

[PATCH V2 1/6] USB: OHCI: make ohci-exynos a separate driver

[Manjunath Goudar]

Separate the  Samsung OHCI EXYNOS host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.

V2:
 -exynos_ohci_hcd structure assignment error fixed.
 -Removed multiple usb_create_hcd() from prob funtion.
 -platform_set_drvdata() called before exynos_ohci_phy_enable().
 -ohci_setup() removed because it is called in .reset member
  of the ohci_hc_driver structure

Signed-off-by: Manjunath Goudar 
Cc: Arnd Bergmann 
Cc: Jingoo Han 
Cc: Kukjin Kim 
Cc: Greg KH 
Cc: Alan Stern 
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/host/Kconfig   |2 +-
 drivers/usb/host/Makefile  |1 +
 drivers/usb/host/ohci-exynos.c |  167 +---
 drivers/usb/host/ohci-hcd.c|   18 -
 4 files changed, 71 insertions(+), 117 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index f35f71e..75456f2 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -463,7 +463,7 @@ config USB_OHCI_SH
  If you use the PCI OHCI controller, this option is not necessary.
 
 config USB_OHCI_EXYNOS
-   boolean "OHCI support for Samsung EXYNOS SoC Series"
+   tristate "OHCI support for Samsung EXYNOS SoC Series"
depends on ARCH_EXYNOS
help
 Enable support for the Samsung Exynos SOC's on-chip OHCI controller.
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index d1a34e0..bf4a4b2 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_USB_ISP1362_HCD) += isp1362-hcd.o
 obj-$(CONFIG_USB_OHCI_HCD) += ohci-hcd.o
 obj-$(CONFIG_USB_OHCI_HCD_PCI) += ohci-pci.o
 obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)+= ohci-platform.o
+obj-$(CONFIG_USB_OHCI_EXYNOS)  += ohci-exynos.o
 
 obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index b0b542c..6ff830c 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -12,24 +12,39 @@
  */
 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+
+#include "ohci.h"
+
+#define DRIVER_DESC "OHCI exynos driver"
+
+static const char hcd_name[] = "ohci-exynos";
+static struct hc_driver __read_mostly exynos_ohci_hc_driver;
+
+#define to_exynos_ohci(hcd) (struct exynos_ohci_hcd *)(hcd_to_ohci(hcd)->priv)
 
 struct exynos_ohci_hcd {
-   struct device *dev;
-   struct usb_hcd *hcd;
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
struct exynos4_ohci_platdata *pdata;
 };
 
-static void exynos_ohci_phy_enable(struct exynos_ohci_hcd *exynos_ohci)
+static void exynos_ohci_phy_enable(struct platform_device *pdev)
 {
-   struct platform_device *pdev = to_platform_device(exynos_ohci->dev);
+   struct usb_hcd *hcd = platform_get_drvdata(pdev);
+   struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
 
if (exynos_ohci->phy)
usb_phy_init(exynos_ohci->phy);
@@ -37,9 +52,10 @@ static void exynos_ohci_phy_enable(struct exynos_ohci_hcd 
*exynos_ohci)
exynos_ohci->pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
 }
 
-static void exynos_ohci_phy_disable(struct exynos_ohci_hcd *exynos_ohci)
+static void exynos_ohci_phy_disable(struct platform_device *pdev)
 {
-   struct platform_device *pdev = to_platform_device(exynos_ohci->dev);
+   struct usb_hcd *hcd = platform_get_drvdata(pdev);
+   struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
 
if (exynos_ohci->phy)
usb_phy_shutdown(exynos_ohci->phy);
@@ -47,63 +63,11 @@ static void exynos_ohci_phy_disable(struct exynos_ohci_hcd 
*exynos_ohci)
exynos_ohci->pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
 }
 
-static int ohci_exynos_reset(struct usb_hcd *hcd)
-{
-   return ohci_init(hcd_to_ohci(hcd));
-}
-
-static int ohci_exynos_start(struct usb_hcd *hcd)
-{
-   struct ohci_hcd *ohci = hcd_to_ohci(hcd);
-   int ret;
-
-   ohci_dbg(ohci, "ohci_exynos_start, ohci:%p", ohci);
-
-   ret = ohci_run(ohci);
-   if (ret < 0) {
-   dev_err(hcd->self.controller, "can't start %s\n",
-   hcd->self.bus_name);
-   ohci_stop(hcd);
-   return ret;
-   }
-
-   return 0;
-}
-
-static const struct hc_driver exynos_ohci_hc_driver = {
-   .description= hcd_name,
-   .product_desc   = "EXYNOS OHCI Host Controller",
-   .hcd_priv_size  = sizeof(struct ohci_hcd),
-
-   .irq= ohci_irq,
-   .flags  = HCD_MEMORY|HCD_USB11,
-
-   .reset  = ohci_exynos_reset,
-   .start  = ohci_exynos_start,
-   .stop  

Re: [PATCH 02/10] USB: OHCI: Properly handle ohci-s3c2410 suspend

[Sergei Shtylyov]

Hello.

On 12-06-2013 19:28, Manjunath Goudar wrote:


Suspend scenario in case of ohci-s3c2410 glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_hcd_s3c2410_drv_suspend() will ensure
proper handling of suspend scenario.



Signed-off-by: Manjunath Goudar 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
Cc: linux-usb@vger.kernel.org
---
  drivers/usb/host/ohci-s3c2410.c |3 +++
  1 file changed, 3 insertions(+)



diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index 8018bb1..2ffa693 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -430,6 +430,7 @@ static int ohci_hcd_s3c2410_drv_suspend(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
unsigned long flags;
int rc = 0;
+   bool do_wakeup = device_may_wakeup(dev);

/*
 * Root hub was already suspended. Disable irq emission and
@@ -445,6 +446,8 @@ static int ohci_hcd_s3c2410_drv_suspend(struct device *dev)

clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);

+   rc = ohci_suspend(hcd, do_wakeup);
+


   Why not call ohci_suspend with device_may_wakeup(&pdev->dev) result 
directly, saving on a local variable only used once? Same comment about 
the following patches...


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: [PATCH 01/10] USB: OHCI: Properly handle ohci-at91 suspend

[Alan Stern]

On Wed, 12 Jun 2013, Manjunath Goudar wrote:

> Suspend scenario in case of ohci-at91 glue was not properly
> handled as it was not suspending generic part of ohci controller.
> Calling explicitly the ohci_suspend()routine in ohci_hcd_at91_drv_suspend()
> will ensure proper handling of suspend scenario.

> diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
> index fb2f127..28400a7 100644
> --- a/drivers/usb/host/ohci-at91.c
> +++ b/drivers/usb/host/ohci-at91.c
> @@ -619,8 +619,12 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev, 
> pm_message_t mesg)
>  {
>   struct usb_hcd  *hcd = platform_get_drvdata(pdev);
>   struct ohci_hcd *ohci = hcd_to_ohci(hcd);
> + bool do_wakeup = device_may_wakeup(&pdev->dev);
> + int ret;
>  
> - if (device_may_wakeup(&pdev->dev))
> + ret = ohci_suspend(hcd, do_wakeup);
> +
> + if (do_wakeup)
>   enable_irq_wake(hcd->irq);
>  
>   /*
> @@ -637,7 +641,7 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev, 
> pm_message_t mesg)
>   at91_stop_clock();
>   }
>  
> - return 0;
> + return ret;

If ohci_suspend() fails, we should return right away.  Don't execute 
the enable_irq_wake() and all the other stuff.

Alan Stern

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

Re: [PATCH V3 1/7] usb: phy: export ulpi_viewport_access_ops

[Stephen Warren]

On 06/12/2013 09:06 AM, Felipe Balbi wrote:
> On Wed, Jun 05, 2013 at 02:03:03PM -0600, Stephen Warren wrote:
>> From: Manjunath Goudar 
>> 
>> In order to build a ULPI PHY driver as a module, this symbol
>> needs to be exported.
>> 
>> Signed-off-by: Manjunath Goudar  
>> [swarren, reworked Manjunath's patches to split them more
>> logically] Signed-off-by: Stephen Warren  
>> Acked-by: Arnd Bergmann 
> 
> This should go straight through Greg:

All the patches in this series build on top of each-other, so I think
need to be applied in the same branch. Applying this patch in branch A
but the others in branch B will cause the build to fail in branch B if
the driver is built as a module, since ulpi_viewport_access_ops isn't
exported, right?

And this series is also based on top of all the Tegra driver changes
in your PHY branch, so I believe that is the correct place to apply this.
--
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

[RFC PATCH 0/1] Intel xhci: rework EHCI/xHCI port switching

[Mathias Nyman]

Hi

This is a proposal for simplifying the EHCI/xHCI portswitching

It's a lot simpler than before. There's now only one funtion for enabling xhci 
ports,
and we only once walk through pci devices to find Intel EHCI and xHCI 
controllers

In pci-quirks we set a flag if both intel xHCI and EHCI controllers are found,
and then call the usb_enable_intel_xhci_ports() function.
EHCI and xHCI resume functions call the same usb_enable_intel_xhci_ports(), 
without
walking the pci devices.

On the downside this uses global variables, one xhci pointer and one boolean 
flag.
The xhci pointer is set only once in pci-quirk and it's assumed that xHCI 
device is not removed,
so there's a possibility this pointer can go stale. 
Also we can only handle one Intel xHCI host in the system.

I'll gladly rework this to remove the global varaibles, but I could use some 
input on what would be
the right way to do it. I can only come up with two options:

1. walk the pci devices every time in ECHI and xHCI resume functions and search 
for a "companion"
controller.

or

2. Save a pointer to a "companion" xHCI controller somewhere in EHCI 
structures, and vice versa.
(or somehow re-use the hs_companion pointer in struct usb_bus). 
Those pointers can only be set after hcd's are initialized, so we need to walk 
the pci devices once in
pci-quirks, and once later when creating the hcd's to set the pointers

Mathias Nyman (1):
  Intel xhci: refactor EHCI/xHCI port switching

 drivers/usb/host/ehci-pci.c   |   15 +--
 drivers/usb/host/pci-quirks.c |   55 ++--
 drivers/usb/host/pci-quirks.h |3 +-
 drivers/usb/host/xhci-pci.c   |5 ++-
 4 files changed, 30 insertions(+), 48 deletions(-)

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

[RFC PATCH 1/1] Intel xhci: refactor EHCI/xHCI port switching

[Mathias Nyman]

Make the Linux xHCI driver automatically try to switchover the EHCI ports to
xHCI when an Intel xHCI host is detected, and it also finds an Intel EHCI host.

This means we will no longer have to add Intel xHCI hosts to a quirks list when
the PCI device IDs change.  Simply continuing to add new Intel xHCI PCI device
IDs to the quirks list is not sustainable.

Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/ehci-pci.c   |   15 +--
 drivers/usb/host/pci-quirks.c |   55 ++--
 drivers/usb/host/pci-quirks.h |3 +-
 drivers/usb/host/xhci-pci.c   |5 ++-
 4 files changed, 30 insertions(+), 48 deletions(-)

diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 595d210..7dd09ea 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -325,19 +325,6 @@ static bool usb_is_intel_switchable_ehci(struct pci_dev 
*pdev)
 pdev->device == 0x9C26);
 }
 
-static void ehci_enable_xhci_companion(void)
-{
-   struct pci_dev  *companion = NULL;
-
-   /* The xHCI and EHCI controllers are not on the same PCI slot */
-   for_each_pci_dev(companion) {
-   if (!usb_is_intel_switchable_xhci(companion))
-   continue;
-   usb_enable_xhci_ports(companion);
-   return;
-   }
-}
-
 static int ehci_pci_resume(struct usb_hcd *hcd, bool hibernated)
 {
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
@@ -360,7 +347,7 @@ static int ehci_pci_resume(struct usb_hcd *hcd, bool 
hibernated)
 * port was already switched over.
 */
if (usb_is_intel_switchable_ehci(pdev))
-   ehci_enable_xhci_companion();
+   usb_enable_intel_xhci_ports();
 
if (ehci_resume(hcd, hibernated) != 0)
(void) ehci_pci_reinit(ehci, pdev);
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index b9848e4..bbc4e98 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -89,6 +89,11 @@ static struct amd_chipset_info {
int probe_result;
 } amd_chipset;
 
+static struct intel_chipset_info {
+   struct pci_dev  *xhci_dev;
+   bool switchable_ports;
+} intel_chipset;
+
 static DEFINE_SPINLOCK(amd_lock);
 
 void sb800_prefetch(struct device *dev, int on)
@@ -735,32 +740,6 @@ static int handshake(void __iomem *ptr, u32 mask, u32 done,
return -ETIMEDOUT;
 }
 
-#define PCI_DEVICE_ID_INTEL_LYNX_POINT_XHCI0x8C31
-#define PCI_DEVICE_ID_INTEL_LYNX_POINT_LP_XHCI 0x9C31
-
-bool usb_is_intel_ppt_switchable_xhci(struct pci_dev *pdev)
-{
-   return pdev->class == PCI_CLASS_SERIAL_USB_XHCI &&
-   pdev->vendor == PCI_VENDOR_ID_INTEL &&
-   pdev->device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI;
-}
-
-/* The Intel Lynx Point chipset also has switchable ports. */
-bool usb_is_intel_lpt_switchable_xhci(struct pci_dev *pdev)
-{
-   return pdev->class == PCI_CLASS_SERIAL_USB_XHCI &&
-   pdev->vendor == PCI_VENDOR_ID_INTEL &&
-   (pdev->device == PCI_DEVICE_ID_INTEL_LYNX_POINT_XHCI ||
-pdev->device == PCI_DEVICE_ID_INTEL_LYNX_POINT_LP_XHCI);
-}
-
-bool usb_is_intel_switchable_xhci(struct pci_dev *pdev)
-{
-   return usb_is_intel_ppt_switchable_xhci(pdev) ||
-   usb_is_intel_lpt_switchable_xhci(pdev);
-}
-EXPORT_SYMBOL_GPL(usb_is_intel_switchable_xhci);
-
 /*
  * Intel's Panther Point chipset has two host controllers (EHCI and xHCI) that
  * share some number of ports.  These ports can be switched between either
@@ -779,10 +758,16 @@ EXPORT_SYMBOL_GPL(usb_is_intel_switchable_xhci);
  * terminations before switching the USB 2.0 wires over, so that USB 3.0
  * devices connect at SuperSpeed, rather than at USB 2.0 speeds.
  */
-void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
+void usb_enable_intel_xhci_ports(void)
 {
+   struct pci_dev *xhci_pdev;
u32 ports_available;
 
+   if (!intel_chipset.switchable_ports || !intel_chipset.xhci_dev)
+   return;
+
+   xhci_pdev = intel_chipset.xhci_dev;
+
/* Don't switchover the ports if the user hasn't compiled the xHCI
 * driver.  Otherwise they will see "dead" USB ports that don't power
 * the devices.
@@ -840,7 +825,7 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
dev_dbg(&xhci_pdev->dev, "USB 2.0 ports that are now switched over "
"to xHCI: 0x%x\n", ports_available);
 }
-EXPORT_SYMBOL_GPL(usb_enable_xhci_ports);
+EXPORT_SYMBOL_GPL(usb_enable_intel_xhci_ports);
 
 void usb_disable_xhci_ports(struct pci_dev *xhci_pdev)
 {
@@ -921,8 +906,18 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
writel(val, base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET);
 
 hc_init:
-   if (usb_is_intel_switchable_xhci(pdev))
-   usb_enable_xhci_ports(pdev);
+   if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
+ 

[GIT PULL] USB patches for v3.11 merge window

[Felipe Balbi]

Hi Greg,

Here's my pull request for v3.11 merge window. It's rather
large. Let me know if you want any changes.

cheers

The following changes since commit e4aa937ec75df0eea0bee03bffa3303ad36c986b:

  Linux 3.10-rc3 (2013-05-26 16:00:47 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v3.11

for you to fetch changes up to b4b1ceec0c3e87065787e7da4c8c3fd7549660b8:

  usb: dwc3: omap: Adds dwc3_omap_readl/writel wrappers (2013-06-12 18:11:51 
+0300)


usb: patches for v3.11 merge window

All function drivers are now converted to our new configfs-based
binding. Eventually this will help us getting rid of in-kernel
gadget drivers and only keep function drivers in the kernel.

MUSB was taught that it needs to be built for host-only and
device-only modes too. We had this support long ago but it
involved a ridiculous amount of ifdefs. Now we have a much
cleaner approach.

Samsung Exynos4 platform now implements HSIC support.

We're introducing support for AB8540 and AB9540 PHYs.

MUSB module reinsertion now works as expected, before we were
getting -EBUSY being returned by the resource checks done on
driver core.

DWC3 now has minimum support for TI's AM437x series of SoCs.

OMAP5 USB3 PHY learned one extra DPLL configuration values because
that PHY is reused in TI's DRA7xx devices.

Users can now select a PHY without enabling the PHY layer first.

We're introducing support for Faraday fotg210 UDCs.

Last, but not least, the usual set of non-critical fixes and cleanups
ranging from usage of platform_{get,set}_drvdata to lock improvements.

Signed-of-by: Felipe Balbi 


Alexey Khoroshilov (1):
  usb: gadget: r8a66597-udc: do not unlock unheld spinlock in 
r8a66597_sudmac_irq()

Andrzej Pietrasiewicz (40):
  usb: gadget: u_ether: convert into module
  usb: gadget: rndis: convert into module
  usb: gadget: u_ether: construct with default values and add 
setters/getters
  usb: gadget: f_ncm: convert to new function interface with backward 
compatibility
  usb: gadget: ncm: convert to new function interface
  usb: gadget: f_ncm: remove compatibility layer
  usb: gadget: f_ncm: use usb_gstrings_attach
  usb: gadget: f_ncm: add configfs support
  usb: gadget: add helpers for configfs support for USB Ethernet
  usb: gadget: f_ecm: convert to new function interface with backward 
compatibility
  usb: gadget: cdc2: convert to new interface of f_ecm
  usb: gadget: f_ecm: use usb_gstrings_attach
  usb: gadget: f_ecm: add configfs support
  usb: gadget: f_obex: use usb_gstrings_attach
  usb: gadget: nokia: convert to new interface of f_obex
  usb: gadget: f_obex: remove compatibility layer
  usb: gadget: phonet: move global dev variable to its user
  usb: gadget: f_phonet: convert to new function interface with backward 
compatibility
  usb: gadget: nokia: convert to new interface of f_phonet
  usb: gadget: f_phonet: remove compatibility layer
  usb: gadget: nokia: convert to new interface of f_ecm
  usb: gadget: f_phonet: add configfs support
  usb: gadget: u_ether: allow getting binary-form host address
  usb: gadget: ether: convert to new interface of f_ecm
  usb: gadget: f_eem: convert to new function interface with backward 
compatibility
  usb: gadget: ether: convert to new interface of f_eem
  usb: gadget: f_eem: remove compatibility layer
  usb: gadget: f_eem: use usb_gstrings_attach
  usb: gadget: f_eem: add configfs support
  usb: gadget: multi: Remove unused include
  usb: gadget: f_subset: convert to new function interface with backward 
compatibility
  usb: gadget: ether: convert to new interface of f_subset
  usb: gadget: f_subset: use usb_gstrings_attach
  usb: gadget: f_subset: add configfs support
  usb: gadget: f_rndis: convert to new function interface with backward 
compatibility
  usb: gadget: ether: convert to new interface of f_rndis
  usb: gadget: rndis: init & exit rndis at module load/unload
  usb: gadget: f_rndis: use usb_gstrings_attach
  usb: gadget: f_rndis: add configfs support
  usb: gadget: f_mass_storage: fix default product name

Daniel Mack (11):
  usb: gadget: drop unused USB_GADGET_MUSB_HDRC
  usb: musb: move function declarations to musb_{host,gadget}.h
  usb: musb: factor some host-specific functions
  usb: musb: gadget: remove hcd initialization
  usb: musb: move musb_start to musb_virthub.c
  usb: musb: factor out hcd initalization
  usb: musb: add Kconfig options for HOST, GAGDET or DUAL_ROLE modes
  usb: musb: add musb_host_setup() and musb_host_cleanup()
  usb: musb: re-introduce musb->port_mode
  usb: musb: use musb->port_mode
  usb: musb: eliminate musb_to_hcd

Dongjin Kim (1

Re: [PATCH 01/10] USB: OHCI: Properly handle ohci-at91 suspend

[Alan Stern]

On Wed, 12 Jun 2013, Alan Stern wrote:

> On Wed, 12 Jun 2013, Manjunath Goudar wrote:
> 
> > Suspend scenario in case of ohci-at91 glue was not properly
> > handled as it was not suspending generic part of ohci controller.
> > Calling explicitly the ohci_suspend()routine in ohci_hcd_at91_drv_suspend()
> > will ensure proper handling of suspend scenario.
> 
> > diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
> > index fb2f127..28400a7 100644
> > --- a/drivers/usb/host/ohci-at91.c
> > +++ b/drivers/usb/host/ohci-at91.c
> > @@ -619,8 +619,12 @@ ohci_hcd_at91_drv_suspend(struct platform_device 
> > *pdev, pm_message_t mesg)
> >  {
> > struct usb_hcd  *hcd = platform_get_drvdata(pdev);
> > struct ohci_hcd *ohci = hcd_to_ohci(hcd);
> > +   bool do_wakeup = device_may_wakeup(&pdev->dev);
> > +   int ret;
> >  
> > -   if (device_may_wakeup(&pdev->dev))
> > +   ret = ohci_suspend(hcd, do_wakeup);
> > +
> > +   if (do_wakeup)
> > enable_irq_wake(hcd->irq);
> >  
> > /*
> > @@ -637,7 +641,7 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev, 
> > pm_message_t mesg)
> > at91_stop_clock();
> > }
> >  
> > -   return 0;
> > +   return ret;
> 
> If ohci_suspend() fails, we should return right away.  Don't execute 
> the enable_irq_wake() and all the other stuff.

Actually, the situation is more complicated.  In order to handle races
with remote wakeup, the logic we need is more like this:


Index: usb-3.10/drivers/usb/host/ohci-at91.c
===
--- usb-3.10.orig/drivers/usb/host/ohci-at91.c
+++ usb-3.10/drivers/usb/host/ohci-at91.c
@@ -674,8 +674,18 @@ ohci_hcd_at91_drv_suspend(struct platfor
 {
struct usb_hcd  *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+   booldo_wakeup = device_may_wakeup(&pdev->dev);
+   int ret;
 
-   if (device_may_wakeup(&pdev->dev))
+   ret = ohci_suspend(hcd, do_wakeup);
+   if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+   ohci_resume(hcd, false);
+   ret = -EBUSY;
+   }
+   if (ret)
+   return ret;
+
+   if (do_wakeup)
enable_irq_wake(hcd->irq);
 
/*
@@ -692,7 +702,7 @@ ohci_hcd_at91_drv_suspend(struct platfor
at91_stop_clock();
}
 
-   return 0;
+   return ret;
 }
 
 static int ohci_hcd_at91_drv_resume(struct platform_device *pdev)

The same is true for all the other drivers.

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: [RFC PATCH 1/1] Intel xhci: refactor EHCI/xHCI port switching

[Greg KH]

On Wed, Jun 12, 2013 at 07:11:23PM +0300, Mathias Nyman wrote:
> Make the Linux xHCI driver automatically try to switchover the EHCI ports to
> xHCI when an Intel xHCI host is detected, and it also finds an Intel EHCI 
> host.
> 
> This means we will no longer have to add Intel xHCI hosts to a quirks list 
> when
> the PCI device IDs change.  Simply continuing to add new Intel xHCI PCI device
> IDs to the quirks list is not sustainable.

So you are saying that all future Intel devices will work this way?  For
some reason I thought we originally proposed this, but it was rejected
by Sarah as she said this might not be true.  Has this changed?

thanks,

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

Re: [PATCH V3 1/7] usb: phy: export ulpi_viewport_access_ops

[Felipe Balbi]

On Wed, Jun 12, 2013 at 10:11:27AM -0600, Stephen Warren wrote:
> On 06/12/2013 09:06 AM, Felipe Balbi wrote:
> > On Wed, Jun 05, 2013 at 02:03:03PM -0600, Stephen Warren wrote:
> >> From: Manjunath Goudar 
> >> 
> >> In order to build a ULPI PHY driver as a module, this symbol
> >> needs to be exported.
> >> 
> >> Signed-off-by: Manjunath Goudar  
> >> [swarren, reworked Manjunath's patches to split them more
> >> logically] Signed-off-by: Stephen Warren  
> >> Acked-by: Arnd Bergmann 
> > 
> > This should go straight through Greg:
> 
> All the patches in this series build on top of each-other, so I think
> need to be applied in the same branch. Applying this patch in branch A
> but the others in branch B will cause the build to fail in branch B if
> the driver is built as a module, since ulpi_viewport_access_ops isn't
> exported, right?
> 
> And this series is also based on top of all the Tegra driver changes
> in your PHY branch, so I believe that is the correct place to apply this.

Isn't it the same thing as Greg taking these patches after applying my
pull request ? There's way too much outside of my domain here without
proper Acks for me to pick it up anyway.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH V3 1/7] usb: phy: export ulpi_viewport_access_ops

[Stephen Warren]

On 06/12/2013 10:38 AM, Felipe Balbi wrote:
> On Wed, Jun 12, 2013 at 10:11:27AM -0600, Stephen Warren wrote:
>> On 06/12/2013 09:06 AM, Felipe Balbi wrote:
>>> On Wed, Jun 05, 2013 at 02:03:03PM -0600, Stephen Warren
>>> wrote:
 From: Manjunath Goudar 
 
 In order to build a ULPI PHY driver as a module, this symbol 
 needs to be exported.
 
 Signed-off-by: Manjunath Goudar 
  [swarren, reworked Manjunath's patches to split them more 
 logically] Signed-off-by: Stephen Warren 
  Acked-by: Arnd Bergmann 
>>> 
>>> This should go straight through Greg:
>> 
>> All the patches in this series build on top of each-other, so I
>> think need to be applied in the same branch. Applying this patch
>> in branch A but the others in branch B will cause the build to
>> fail in branch B if the driver is built as a module, since
>> ulpi_viewport_access_ops isn't exported, right?
>> 
>> And this series is also based on top of all the Tegra driver
>> changes in your PHY branch, so I believe that is the correct
>> place to apply this.
> 
> Isn't it the same thing as Greg taking these patches after applying
> my pull request ? There's way too much outside of my domain here
> without proper Acks for me to pick it up anyway.

Yes.

I wasn't aware that you'd sent a pull request to Greg already though.
If you have, then it's fine for Greg to apply this series after the
PHY branch is pulled.

(I think Alan did Ack all the EHCI patches though, so either way is
probably fine...)
--
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/7] usb: phy: export ulpi_viewport_access_ops

[Felipe Balbi]

Hi,

On Wed, Jun 12, 2013 at 10:51:05AM -0600, Stephen Warren wrote:
> On 06/12/2013 10:38 AM, Felipe Balbi wrote:
> > On Wed, Jun 12, 2013 at 10:11:27AM -0600, Stephen Warren wrote:
> >> On 06/12/2013 09:06 AM, Felipe Balbi wrote:
> >>> On Wed, Jun 05, 2013 at 02:03:03PM -0600, Stephen Warren
> >>> wrote:
>  From: Manjunath Goudar 
>  
>  In order to build a ULPI PHY driver as a module, this symbol 
>  needs to be exported.
>  
>  Signed-off-by: Manjunath Goudar 
>   [swarren, reworked Manjunath's patches to split them more 
>  logically] Signed-off-by: Stephen Warren 
>   Acked-by: Arnd Bergmann 
> >>> 
> >>> This should go straight through Greg:
> >> 
> >> All the patches in this series build on top of each-other, so I
> >> think need to be applied in the same branch. Applying this patch
> >> in branch A but the others in branch B will cause the build to
> >> fail in branch B if the driver is built as a module, since
> >> ulpi_viewport_access_ops isn't exported, right?
> >> 
> >> And this series is also based on top of all the Tegra driver
> >> changes in your PHY branch, so I believe that is the correct
> >> place to apply this.
> > 
> > Isn't it the same thing as Greg taking these patches after applying
> > my pull request ? There's way too much outside of my domain here
> > without proper Acks for me to pick it up anyway.
> 
> Yes.
> 
> I wasn't aware that you'd sent a pull request to Greg already though.
> If you have, then it's fine for Greg to apply this series after the
> PHY branch is pulled.
> 
> (I think Alan did Ack all the EHCI patches though, so either way is
> probably fine...)

Indeed, just saw his replies to the two patches which were missing his
Acks. My bad

-- 
balbi


signature.asc
Description: Digital signature

Re: DWC3: Event Interrupt Mask issue

[Felipe Balbi]

Hi,

On Fri, Jun 07, 2013 at 03:50:17PM +0800, Huang Rui wrote:
> Hi Felipe,
> 
> I was reading dwc3 codes and found that during the process of
> configuring event buffer (dwc3_event_buffers_setup), it only write the
> size of the buffer and doesn't write interrupt mask bit into GEVNTSIZ
> register like below,
> 
> dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(n),
> evt->length & 0x);
> 
> But in spec, it suggests that write this bit to prevent the interrupt
> from being generated in an event buffer configuration. So need we set

where does it say that ? I just re-read details about that bit and all
it says is that it can be used to mask the interrupt, but events will
still be queued. Maybe I'm missing some part. Which revision of the
databook are you reading ?

Anyway, we don't really need that bit right now because linux will only
enable the IRQ line after request_*irq() has been called and we're
setting up our event buffers before calling that.

OTOH, we could use that bit as means to get rid of IRQF_ONESHOT from
DWC3 driver.

Can you test a patch for me ? I don't have access to HW right now. I
assume the patch below works fine, does it ?

(it's not final yet, I will still break it down into proper patches)

8<--- cut here 


diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c35d49d..be74df6 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -236,7 +236,7 @@ static int dwc3_event_buffers_setup(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_GEVNTADRHI(n),
upper_32_bits(evt->dma));
dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(n),
-   evt->length & 0x);
+   DWC3_GEVNTSIZ_SIZE(evt->length));
dwc3_writel(dwc->regs, DWC3_GEVNTCOUNT(n), 0);
}
 
@@ -255,7 +255,8 @@ static void dwc3_event_buffers_cleanup(struct dwc3 *dwc)
 
dwc3_writel(dwc->regs, DWC3_GEVNTADRLO(n), 0);
dwc3_writel(dwc->regs, DWC3_GEVNTADRHI(n), 0);
-   dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(n), 0);
+   dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(n), DWC3_GEVNTSIZ_INTMASK
+   | DWC3_GEVNTSIZ_SIZE(0));
dwc3_writel(dwc->regs, DWC3_GEVNTCOUNT(n), 0);
}
 }
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index b69d322..d2ceb82 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -194,6 +194,10 @@
 #define DWC3_GTXFIFOSIZ_TXFDEF(n)  ((n) & 0x)
 #define DWC3_GTXFIFOSIZ_TXFSTADDR(n)   ((n) & 0x)
 
+/* Global Event Size Registers */
+#define DWC3_GEVNTSIZ_INTMASK  (1 << 31)
+#define DWC3_GEVNTSIZ_SIZE(n)  ((n) & 0x)
+
 /* Global HWPARAMS1 Register */
 #define DWC3_GHWPARAMS1_EN_PWROPT(n)   (((n) & (3 << 24)) >> 24)
 #define DWC3_GHWPARAMS1_EN_PWROPT_NO   0
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 2b6e7e0..dc7ee3d 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1567,7 +1567,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
 
irq = platform_get_irq(to_platform_device(dwc->dev), 0);
ret = request_threaded_irq(irq, dwc3_interrupt, dwc3_thread_interrupt,
-   IRQF_SHARED | IRQF_ONESHOT, "dwc3", dwc);
+   IRQF_SHARED, "dwc3", dwc);
if (ret) {
dev_err(dwc->dev, "failed to request irq #%d --> %d\n",
irq, ret);
@@ -2491,6 +2491,7 @@ static irqreturn_t dwc3_thread_interrupt(int irq, void 
*_dwc)
struct dwc3 *dwc = _dwc;
unsigned long flags;
irqreturn_t ret = IRQ_NONE;
+   u32 reg;
int i;
 
spin_lock_irqsave(&dwc->lock, flags);
@@ -2530,6 +2531,11 @@ static irqreturn_t dwc3_thread_interrupt(int irq, void 
*_dwc)
evt->count = 0;
evt->flags &= ~DWC3_EVENT_PENDING;
ret = IRQ_HANDLED;
+
+   /* Unask interrupt */
+   reg = dwc3_readl(dwc->regs, DWC3_GEVNTSIZ(i));
+   reg &= ~DWC3_GEVNTSIZ_INTMASK;
+   dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(i), reg);
}
 
spin_unlock_irqrestore(&dwc->lock, flags);
@@ -2541,6 +2547,7 @@ static irqreturn_t dwc3_process_event_buf(struct dwc3 
*dwc, u32 buf)
 {
struct dwc3_event_buffer *evt;
u32 count;
+   u32 reg;
 
evt = dwc->ev_buffs[buf];
 
@@ -2552,6 +2559,11 @@ static irqreturn_t dwc3_process_event_buf(struct dwc3 
*dwc, u32 buf)
evt->count = count;
evt->flags |= DWC3_EVENT_PENDING;
 
+   /* Mask interrupt */
+   reg = dwc3_readl(dwc->regs, DWC3_GEVNTSIZ(buf));
+   reg |= DWC3_GEVNTSIZ_INTMASK;
+   dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(buf), reg);
+
return IRQ_WAKE_THREAD;
 }
 

-- 
balbi


signature.asc
Description: Digital signatu

USB communication stops working after 0x7FFFFFFF milliseconds

[Kerry Calvert]

We are running the 2.6.28-15 kernel under Ubuntu 9.04 (I know... we are 
migrating now). We see the USB communication between the kernel driver and the 
USB device stop after what appears to be 0x7 microseconds, and suspect 
it is a logic problem with an unsigned long rolling over. We cannot find the 
source for this kernel, but in looking at the linux USB driver code in later 
versions of the kernel and the firmware in our USB device, we are not using 
timers or incremental counters such that this would be the root cause.

We monitored the USB bus when this failure occured with a software monitor tool 
and saw that URBs submitted at the linux driver level were being put out on the 
bus, but no response was received from the USB device.  The USB device is a TI 
CC part, hosted on a controller board attached to the system on a PCI slot.

We are doing additional tests with the same board hosted on a cradle board that 
connects to a standard USB 2.0 port on the linux computer with a USB cable to 
see if the problem replicates that way. With the cradle board configuration, we 
saw a USB communication failure monitored with a Beagle board USB monitor where 
traffic was being exchanged bidirectionally on the bus between the linux driver 
and the CC hosted driver, but the data was not making it to our kernel 
module that sends/receives URBS.  We saw this failure when we disconnected the 
USB cable and reconnected it.  Normally this works, it is not a hard failure, 
but we do intermittently see communication stop when this procedure is done.

I am not sure what part on the linux computer is providing USB host controller 
services, but we are using the standard USB driver distributed in the kernel.

We have ported our application and drivers to the 3.9.2 version of the kernel, 
hosted under Ubuntu 12.4.  Unfortunately, this takes 25 days to reach the fail 
point so we can analyze the results.  

Anyone seen this problem or have ideas about what could cause the USB comm to 
stop consistently at this benchmark time.  Is the unplug/reconnect failure a 
completely separate issue, or is it indicative of some handling problem that 
also manifests itself in the 0x7fff microsecond communication halt?  As I 
indicated earlier, I do not see incremental timer or time calculations being 
done in the driver sources, so this communication halt that has been 100% 
predictable certainly seems timer or some increment calculation related, but I 
just do not see it in the code.--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] USB patches for v3.11 merge window

[Greg KH]

On Wed, Jun 12, 2013 at 07:12:23PM +0300, Felipe Balbi wrote:
> Hi Greg,
> 
> Here's my pull request for v3.11 merge window. It's rather
> large. Let me know if you want any changes.
> 
> cheers
> 
> The following changes since commit e4aa937ec75df0eea0bee03bffa3303ad36c986b:
> 
>   Linux 3.10-rc3 (2013-05-26 16:00:47 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/usb-for-v3.11
> 
> for you to fetch changes up to b4b1ceec0c3e87065787e7da4c8c3fd7549660b8:
> 
>   usb: dwc3: omap: Adds dwc3_omap_readl/writel wrappers (2013-06-12 18:11:51 
> +0300)
> 
> 
> usb: patches for v3.11 merge window
> 
> All function drivers are now converted to our new configfs-based
> binding. Eventually this will help us getting rid of in-kernel
> gadget drivers and only keep function drivers in the kernel.
> 
> MUSB was taught that it needs to be built for host-only and
> device-only modes too. We had this support long ago but it
> involved a ridiculous amount of ifdefs. Now we have a much
> cleaner approach.
> 
> Samsung Exynos4 platform now implements HSIC support.
> 
> We're introducing support for AB8540 and AB9540 PHYs.
> 
> MUSB module reinsertion now works as expected, before we were
> getting -EBUSY being returned by the resource checks done on
> driver core.
> 
> DWC3 now has minimum support for TI's AM437x series of SoCs.
> 
> OMAP5 USB3 PHY learned one extra DPLL configuration values because
> that PHY is reused in TI's DRA7xx devices.
> 
> Users can now select a PHY without enabling the PHY layer first.
> 
> We're introducing support for Faraday fotg210 UDCs.
> 
> Last, but not least, the usual set of non-critical fixes and cleanups
> ranging from usage of platform_{get,set}_drvdata to lock improvements.
> 
> Signed-of-by: Felipe Balbi 
> 
> 
> Alexey Khoroshilov (1):
>   usb: gadget: r8a66597-udc: do not unlock unheld spinlock in 
> r8a66597_sudmac_irq()
> 
> Andrzej Pietrasiewicz (40):
>   usb: gadget: u_ether: convert into module
>   usb: gadget: rndis: convert into module
>   usb: gadget: u_ether: construct with default values and add 
> setters/getters
>   usb: gadget: f_ncm: convert to new function interface with backward 
> compatibility
>   usb: gadget: ncm: convert to new function interface
>   usb: gadget: f_ncm: remove compatibility layer
>   usb: gadget: f_ncm: use usb_gstrings_attach
>   usb: gadget: f_ncm: add configfs support
>   usb: gadget: add helpers for configfs support for USB Ethernet
>   usb: gadget: f_ecm: convert to new function interface with backward 
> compatibility
>   usb: gadget: cdc2: convert to new interface of f_ecm
>   usb: gadget: f_ecm: use usb_gstrings_attach
>   usb: gadget: f_ecm: add configfs support
>   usb: gadget: f_obex: use usb_gstrings_attach
>   usb: gadget: nokia: convert to new interface of f_obex
>   usb: gadget: f_obex: remove compatibility layer
>   usb: gadget: phonet: move global dev variable to its user
>   usb: gadget: f_phonet: convert to new function interface with backward 
> compatibility
>   usb: gadget: nokia: convert to new interface of f_phonet
>   usb: gadget: f_phonet: remove compatibility layer
>   usb: gadget: nokia: convert to new interface of f_ecm
>   usb: gadget: f_phonet: add configfs support
>   usb: gadget: u_ether: allow getting binary-form host address
>   usb: gadget: ether: convert to new interface of f_ecm
>   usb: gadget: f_eem: convert to new function interface with backward 
> compatibility
>   usb: gadget: ether: convert to new interface of f_eem
>   usb: gadget: f_eem: remove compatibility layer
>   usb: gadget: f_eem: use usb_gstrings_attach
>   usb: gadget: f_eem: add configfs support
>   usb: gadget: multi: Remove unused include
>   usb: gadget: f_subset: convert to new function interface with backward 
> compatibility
>   usb: gadget: ether: convert to new interface of f_subset
>   usb: gadget: f_subset: use usb_gstrings_attach
>   usb: gadget: f_subset: add configfs support
>   usb: gadget: f_rndis: convert to new function interface with backward 
> compatibility
>   usb: gadget: ether: convert to new interface of f_rndis
>   usb: gadget: rndis: init & exit rndis at module load/unload
>   usb: gadget: f_rndis: use usb_gstrings_attach
>   usb: gadget: f_rndis: add configfs support
>   usb: gadget: f_mass_storage: fix default product name
> 
> Daniel Mack (11):
>   usb: gadget: drop unused USB_GADGET_MUSB_HDRC
>   usb: musb: move function declarations to musb_{host,gadget}.h
>   usb: musb: factor some host-specific functions
>   usb: musb: gadget: remove hcd initialization
>   usb: musb: move musb_start to musb_virthub.c
>   usb: musb: factor 

Re: [xhci] null pointer dereference on ring_doorbell_for_active_rings

[Oleksij Rempel]

Am 11.06.2013 19:34, schrieb Sarah Sharp:

On Mon, Jun 10, 2013 at 08:55:56AM +0200, Oleksij Rempel wrote:

Hello all,

i'm working on usb_autosuspend for ath9k_htc and triggered this
oops. Currently i do not know if real bug is in ath9k_htc or in
xhci. Same adapter with same kernel and my patches work fine on ehci
host... so may be it is xhci.


Which kernel version is this oops on?  I suspect it's an xHCI issue.

Please turn on CONFIG_USB_XHCI_HCD_DEBUGGING and CONFIG_USB_DEBUG and
send me dmesg, from the beginning of connecting the device to when it is
suspended and then resumed.  That will be a lot of output, so feel free
to compress it.


i learned how to use kdump :) complete log is in attachment
--
Regards,
Oleksij


crash_log.bz2
Description: application/bzip

Re: [GIT PULL] USB patches for v3.11 merge window

[Felipe Balbi]

Hi,

On Wed, Jun 12, 2013 at 01:17:42PM -0700, Greg KH wrote:
> On Wed, Jun 12, 2013 at 07:12:23PM +0300, Felipe Balbi wrote:
> > Hi Greg,
> > 
> > Here's my pull request for v3.11 merge window. It's rather
> > large. Let me know if you want any changes.
> > 
> > cheers
> > 
> > The following changes since commit e4aa937ec75df0eea0bee03bffa3303ad36c986b:
> > 
> >   Linux 3.10-rc3 (2013-05-26 16:00:47 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> > tags/usb-for-v3.11
> > 
> > for you to fetch changes up to b4b1ceec0c3e87065787e7da4c8c3fd7549660b8:
> > 
> >   usb: dwc3: omap: Adds dwc3_omap_readl/writel wrappers (2013-06-12 
> > 18:11:51 +0300)
> > 
> > 
> > usb: patches for v3.11 merge window
> > 
> > All function drivers are now converted to our new configfs-based
> > binding. Eventually this will help us getting rid of in-kernel
> > gadget drivers and only keep function drivers in the kernel.
> > 
> > MUSB was taught that it needs to be built for host-only and
> > device-only modes too. We had this support long ago but it
> > involved a ridiculous amount of ifdefs. Now we have a much
> > cleaner approach.
> > 
> > Samsung Exynos4 platform now implements HSIC support.
> > 
> > We're introducing support for AB8540 and AB9540 PHYs.
> > 
> > MUSB module reinsertion now works as expected, before we were
> > getting -EBUSY being returned by the resource checks done on
> > driver core.
> > 
> > DWC3 now has minimum support for TI's AM437x series of SoCs.
> > 
> > OMAP5 USB3 PHY learned one extra DPLL configuration values because
> > that PHY is reused in TI's DRA7xx devices.
> > 
> > Users can now select a PHY without enabling the PHY layer first.
> > 
> > We're introducing support for Faraday fotg210 UDCs.
> > 
> > Last, but not least, the usual set of non-critical fixes and cleanups
> > ranging from usage of platform_{get,set}_drvdata to lock improvements.
> > 
> > Signed-of-by: Felipe Balbi 
> > 
> > 
> > Alexey Khoroshilov (1):
> >   usb: gadget: r8a66597-udc: do not unlock unheld spinlock in 
> > r8a66597_sudmac_irq()
> > 
> > Andrzej Pietrasiewicz (40):
> >   usb: gadget: u_ether: convert into module
> >   usb: gadget: rndis: convert into module
> >   usb: gadget: u_ether: construct with default values and add 
> > setters/getters
> >   usb: gadget: f_ncm: convert to new function interface with backward 
> > compatibility
> >   usb: gadget: ncm: convert to new function interface
> >   usb: gadget: f_ncm: remove compatibility layer
> >   usb: gadget: f_ncm: use usb_gstrings_attach
> >   usb: gadget: f_ncm: add configfs support
> >   usb: gadget: add helpers for configfs support for USB Ethernet
> >   usb: gadget: f_ecm: convert to new function interface with backward 
> > compatibility
> >   usb: gadget: cdc2: convert to new interface of f_ecm
> >   usb: gadget: f_ecm: use usb_gstrings_attach
> >   usb: gadget: f_ecm: add configfs support
> >   usb: gadget: f_obex: use usb_gstrings_attach
> >   usb: gadget: nokia: convert to new interface of f_obex
> >   usb: gadget: f_obex: remove compatibility layer
> >   usb: gadget: phonet: move global dev variable to its user
> >   usb: gadget: f_phonet: convert to new function interface with 
> > backward compatibility
> >   usb: gadget: nokia: convert to new interface of f_phonet
> >   usb: gadget: f_phonet: remove compatibility layer
> >   usb: gadget: nokia: convert to new interface of f_ecm
> >   usb: gadget: f_phonet: add configfs support
> >   usb: gadget: u_ether: allow getting binary-form host address
> >   usb: gadget: ether: convert to new interface of f_ecm
> >   usb: gadget: f_eem: convert to new function interface with backward 
> > compatibility
> >   usb: gadget: ether: convert to new interface of f_eem
> >   usb: gadget: f_eem: remove compatibility layer
> >   usb: gadget: f_eem: use usb_gstrings_attach
> >   usb: gadget: f_eem: add configfs support
> >   usb: gadget: multi: Remove unused include
> >   usb: gadget: f_subset: convert to new function interface with 
> > backward compatibility
> >   usb: gadget: ether: convert to new interface of f_subset
> >   usb: gadget: f_subset: use usb_gstrings_attach
> >   usb: gadget: f_subset: add configfs support
> >   usb: gadget: f_rndis: convert to new function interface with backward 
> > compatibility
> >   usb: gadget: ether: convert to new interface of f_rndis
> >   usb: gadget: rndis: init & exit rndis at module load/unload
> >   usb: gadget: f_rndis: use usb_gstrings_attach
> >   usb: gadget: f_rndis: add configfs support
> >   usb: gadget: f_mass_storage: fix default product name
> > 
> > Daniel Mack (11):
> >   usb: gadget: drop

Re: [GIT PULL] USB patches for v3.11 merge window

[Felipe Balbi]

Hi,

On Wed, Jun 12, 2013 at 11:56:19PM +0300, Felipe Balbi wrote:
> > But, I get a build error with your tree pulled in, at the link point in
> > time:
> > 
> > ERROR: "usb_add_phy" [drivers/usb/phy/phy-samsung-usb3.ko] undefined!
> > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-samsung-usb3.ko] undefined!
> > ERROR: "usb_add_phy" [drivers/usb/phy/phy-samsung-usb2.ko] undefined!
> > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-samsung-usb2.ko] undefined!
> > ERROR: "usb_add_phy" [drivers/usb/phy/phy-rcar-usb.ko] undefined!
> > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-rcar-usb.ko] undefined!
> > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-omap-usb3.ko] undefined!
> > ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-omap-usb3.ko] undefined!
> > ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-nop.ko] undefined!
> > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-nop.ko] undefined!
> > ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-isp1301.ko] undefined!
> > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-isp1301.ko] undefined!
> > ERROR: "usb_add_phy" [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined!
> > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined!
> > ERROR: "usb_get_phy" [drivers/usb/musb/ux500.ko] undefined!
> > ERROR: "usb_put_phy" [drivers/usb/musb/ux500.ko] undefined!
> > ERROR: "usb_put_phy" [drivers/usb/gadget/pxa27x_udc.ko] undefined!
> > ERROR: "usb_get_phy" [drivers/usb/gadget/pxa27x_udc.ko] undefined!
> > ERROR: "devm_usb_get_phy" [drivers/usb/gadget/mv_udc.ko] undefined!
> > ERROR: "devm_usb_get_phy" [drivers/usb/dwc3/dwc3.ko] undefined!
> > ERROR: "devm_usb_get_phy_by_phandle" [drivers/usb/dwc3/dwc3.ko] undefined!
> > ERROR: "usb_get_phy" [drivers/usb/chipidea/ci_hdrc.ko] undefined!
> > ERROR: "usb_put_phy" [drivers/usb/chipidea/ci_hdrc.ko] undefined!
> > ERROR: "usb_get_phy" [drivers/power/isp1704_charger.ko] undefined!
> > ERROR: "usb_put_phy" [drivers/power/isp1704_charger.ko] undefined!
> > 
> > Any ideas?
> 
> hmm... I think it was Roger's patches changing the way PHY layer is
> enabled, do you mind if I drop that for now ? I would have to rebase,
> but I guess it's a necessary evil at this point.

I took the silence as a yes and pushed a new tag with Roger's patches
removed. I have also removed one musb patch which wasn't necessary after
all.

Here's an updated pull request, which I have compiled on ARM and x86
and didn't see the linking problem mentioned above:

The following changes since commit e4aa937ec75df0eea0bee03bffa3303ad36c986b:

  Linux 3.10-rc3 (2013-05-26 16:00:47 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v3.11

for you to fetch changes up to b1fd6cb5ee2f97a553d1c4b8a88914bd970daf37:

  usb: dwc3: omap: Adds dwc3_omap_readl/writel wrappers (2013-06-12 23:57:13 
+0300)


usb: patches for v3.11 merge window

All function drivers are now converted to our new configfs-based
binding. Eventually this will help us getting rid of in-kernel
gadget drivers and only keep function drivers in the kernel.

MUSB was taught that it needs to be built for host-only and
device-only modes too. We had this support long ago but it
involved a ridiculous amount of ifdefs. Now we have a much
cleaner approach.

Samsung Exynos4 platform now implements HSIC support.

We're introducing support for AB8540 and AB9540 PHYs.

MUSB module reinsertion now works as expected, before we were
getting -EBUSY being returned by the resource checks done on
driver core.

DWC3 now has minimum support for TI's AM437x series of SoCs.

OMAP5 USB3 PHY learned one extra DPLL configuration values because
that PHY is reused in TI's DRA7xx devices.

We're introducing support for Faraday fotg210 UDCs.

Last, but not least, the usual set of non-critical fixes and cleanups
ranging from usage of platform_{get,set}_drvdata to lock improvements.

Signed-of-by: Felipe Balbi 


Alexey Khoroshilov (1):
  usb: gadget: r8a66597-udc: do not unlock unheld spinlock in 
r8a66597_sudmac_irq()

Andrzej Pietrasiewicz (40):
  usb: gadget: u_ether: convert into module
  usb: gadget: rndis: convert into module
  usb: gadget: u_ether: construct with default values and add 
setters/getters
  usb: gadget: f_ncm: convert to new function interface with backward 
compatibility
  usb: gadget: ncm: convert to new function interface
  usb: gadget: f_ncm: remove compatibility layer
  usb: gadget: f_ncm: use usb_gstrings_attach
  usb: gadget: f_ncm: add configfs support
  usb: gadget: add helpers for configfs support for USB Ethernet
  usb: gadget: f_ecm: convert to new function interface with backward 
compatibility
  usb: gadget: cdc2: convert to new interface of f_ecm
  usb: gadget: f_ecm: use usb_gstrings_attach
  usb: gadget: f_ecm: add configfs support
  usb: gadget:

Re: [GIT PULL] USB patches for v3.11 merge window

[Greg KH]

On Thu, Jun 13, 2013 at 12:19:02AM +0300, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Jun 12, 2013 at 11:56:19PM +0300, Felipe Balbi wrote:
> > > But, I get a build error with your tree pulled in, at the link point in
> > > time:
> > > 
> > > ERROR: "usb_add_phy" [drivers/usb/phy/phy-samsung-usb3.ko] undefined!
> > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-samsung-usb3.ko] undefined!
> > > ERROR: "usb_add_phy" [drivers/usb/phy/phy-samsung-usb2.ko] undefined!
> > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-samsung-usb2.ko] undefined!
> > > ERROR: "usb_add_phy" [drivers/usb/phy/phy-rcar-usb.ko] undefined!
> > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-rcar-usb.ko] undefined!
> > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-omap-usb3.ko] undefined!
> > > ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-omap-usb3.ko] undefined!
> > > ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-nop.ko] undefined!
> > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-nop.ko] undefined!
> > > ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-isp1301.ko] undefined!
> > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-isp1301.ko] undefined!
> > > ERROR: "usb_add_phy" [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined!
> > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined!
> > > ERROR: "usb_get_phy" [drivers/usb/musb/ux500.ko] undefined!
> > > ERROR: "usb_put_phy" [drivers/usb/musb/ux500.ko] undefined!
> > > ERROR: "usb_put_phy" [drivers/usb/gadget/pxa27x_udc.ko] undefined!
> > > ERROR: "usb_get_phy" [drivers/usb/gadget/pxa27x_udc.ko] undefined!
> > > ERROR: "devm_usb_get_phy" [drivers/usb/gadget/mv_udc.ko] undefined!
> > > ERROR: "devm_usb_get_phy" [drivers/usb/dwc3/dwc3.ko] undefined!
> > > ERROR: "devm_usb_get_phy_by_phandle" [drivers/usb/dwc3/dwc3.ko] undefined!
> > > ERROR: "usb_get_phy" [drivers/usb/chipidea/ci_hdrc.ko] undefined!
> > > ERROR: "usb_put_phy" [drivers/usb/chipidea/ci_hdrc.ko] undefined!
> > > ERROR: "usb_get_phy" [drivers/power/isp1704_charger.ko] undefined!
> > > ERROR: "usb_put_phy" [drivers/power/isp1704_charger.ko] undefined!
> > > 
> > > Any ideas?
> > 
> > hmm... I think it was Roger's patches changing the way PHY layer is
> > enabled, do you mind if I drop that for now ? I would have to rebase,
> > but I guess it's a necessary evil at this point.
> 
> I took the silence as a yes and pushed a new tag with Roger's patches
> removed. I have also removed one musb patch which wasn't necessary after
> all.

Sorry for the silence, I went to lunch :)

> Here's an updated pull request, which I have compiled on ARM and x86
> and didn't see the linking problem mentioned above:

Ok, thanks, I'll try it out now...

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

Re: USB communication stops working after 0x7FFFFFFF milliseconds

[Greg KH]

On Wed, Jun 12, 2013 at 06:51:00PM +, Kerry Calvert wrote:
> 
> We are running the 2.6.28-15 kernel under Ubuntu 9.04 (I know... we
> are migrating now).

Then you really need to get support from Ubuntu, there's nothing we can
do here about such an old and obsolete, and really unknown kernel tree,
sorry.

Given that I know machines are out there running successfully for longer
than that many milliseconds, with USB, just fine (my build server is one
such example), I'd point to either the changes that Canonical made to
that kernel version, or your specific drivers you have for your
hardware.

Good luck,

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

Re: [RFC PATCH 1/1] Intel xhci: refactor EHCI/xHCI port switching

[Sarah Sharp]

On Wed, Jun 12, 2013 at 09:32:58AM -0700, Greg KH wrote:
> On Wed, Jun 12, 2013 at 07:11:23PM +0300, Mathias Nyman wrote:
> > Make the Linux xHCI driver automatically try to switchover the EHCI ports to
> > xHCI when an Intel xHCI host is detected, and it also finds an Intel EHCI 
> > host.
> > 
> > This means we will no longer have to add Intel xHCI hosts to a quirks list 
> > when
> > the PCI device IDs change.  Simply continuing to add new Intel xHCI PCI 
> > device
> > IDs to the quirks list is not sustainable.
> 
> So you are saying that all future Intel devices will work this way?  For
> some reason I thought we originally proposed this, but it was rejected
> by Sarah as she said this might not be true.  Has this changed?

For the long-term roadmap, eventually Intel will drop the EHCI host
controller and only use xHCI.

Originally, I thought this would happen within one Intel chipset
generation.  However, it looks like the EHCI host is still being used
for Haswell, Haswell-ULT, and its shrink, Broadwell.  Those chipsets are
being re-used in other Intel products, but branded with a different PCI
ID, and that means another explosion of PCI IDs to add to the quirk.

It's just not sustainable to continue to add PCI IDs, so I asked Mathias
to look into reworking the code.

Sarah Sharp
--
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: [RFC v2] xhci: fix dma mask setup in xhci.c

[Sarah Sharp]

On Fri, Jun 07, 2013 at 11:37:53PM +0300, Felipe Balbi wrote:
> Hi,
> 
> On Fri, Jun 07, 2013 at 10:19:23AM -0700, Sarah Sharp wrote:
> > Adding Felipe.
> > 
> > Xenia, Felipe is the USB "gadget" maintainer, and also added code for
> > non-PCI xHCI hosts.  Felipe, Xenia is my summer intern through the FOSS
> > Outreach Program for Women: http://kernelnewbies.org/OPWIntro
> 
> Hey, cool Sarah :-)
> 
> Welcome Xenia :-)

Ah, slight correction, my intern wants to be called Ksenia.  Xenia is
her legal name, but everyone calls her Ksenia. :)

> > On Fri, Jun 07, 2013 at 03:00:47PM +0300, Mathias Nyman wrote:
> > > Andy explained his concern in more detail to me irl.
> > > 
> > > The beef is that the dma_mask is a pointer while dma_coherent_mask
> > > is a u64 value in struct device, and dma_set_mask() fails if
> > > dev->dma_mask doesn't point anywhere.
> > > 
> > > This is not a problem for PCI enumerated devices because PCI probe
> > > sets a default 32bit mask and makes the dma_mask of all new PCI
> > > devices point to this value.
> > > 
> > > For non-pci enumerated devices the device dma_mask may be NULL and
> > > dma_set_mask() may fail even if dma is supported on the host
> > > machine.
> > > 
> > > for example ehci-platform.c solves this by adding:
> > > 
> > > if (!dev->dev.dma_mask)
> > > dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
> > > if (!dev->dev.coherent_dma_mask)
> > > dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> > 
> > So it sounds like xhci_plat_setup() in xhci-plat.c needs to do something
> > similar before it calls xhci_gen_setup().  Felipe, do you agree?
> 
> (now, after reading the whole thing...)
> 
> I'll agree with that :)
> 
> > It's funny that the code worked before.  Perhaps setting the dma_mask
> > pointer should be a separate patch for stable?
> 
> sounds like a good plan to me :-)

Great!  Ok, Ksenia, can you create those two patches?  The first patch
in the series should add setting the dma_mask pointer to
xhci_plat_setup().  The second patch will be the same as this patch.
Let me know via IRC if you have any questions.

Sarah Sharp
--
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: [RFC PATCH 1/1] Intel xhci: refactor EHCI/xHCI port switching

[Greg KH]

On Wed, Jun 12, 2013 at 03:01:50PM -0700, Sarah Sharp wrote:
> On Wed, Jun 12, 2013 at 09:32:58AM -0700, Greg KH wrote:
> > On Wed, Jun 12, 2013 at 07:11:23PM +0300, Mathias Nyman wrote:
> > > Make the Linux xHCI driver automatically try to switchover the EHCI ports 
> > > to
> > > xHCI when an Intel xHCI host is detected, and it also finds an Intel EHCI 
> > > host.
> > > 
> > > This means we will no longer have to add Intel xHCI hosts to a quirks 
> > > list when
> > > the PCI device IDs change.  Simply continuing to add new Intel xHCI PCI 
> > > device
> > > IDs to the quirks list is not sustainable.
> > 
> > So you are saying that all future Intel devices will work this way?  For
> > some reason I thought we originally proposed this, but it was rejected
> > by Sarah as she said this might not be true.  Has this changed?
> 
> For the long-term roadmap, eventually Intel will drop the EHCI host
> controller and only use xHCI.
> 
> Originally, I thought this would happen within one Intel chipset
> generation.  However, it looks like the EHCI host is still being used
> for Haswell, Haswell-ULT, and its shrink, Broadwell.  Those chipsets are
> being re-used in other Intel products, but branded with a different PCI
> ID, and that means another explosion of PCI IDs to add to the quirk.
> 
> It's just not sustainable to continue to add PCI IDs, so I asked Mathias
> to look into reworking the code.

Thanks for the explaination, if you are ok with this, I have no
objections.  Feel free to queue it up in your next round of patches if
you want to.

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

Re: [GIT PULL] USB patches for v3.11 merge window

[Greg KH]

On Wed, Jun 12, 2013 at 02:31:17PM -0700, Greg KH wrote:
> On Thu, Jun 13, 2013 at 12:19:02AM +0300, Felipe Balbi wrote:
> > Hi,
> > 
> > On Wed, Jun 12, 2013 at 11:56:19PM +0300, Felipe Balbi wrote:
> > > > But, I get a build error with your tree pulled in, at the link point in
> > > > time:
> > > > 
> > > > ERROR: "usb_add_phy" [drivers/usb/phy/phy-samsung-usb3.ko] undefined!
> > > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-samsung-usb3.ko] undefined!
> > > > ERROR: "usb_add_phy" [drivers/usb/phy/phy-samsung-usb2.ko] undefined!
> > > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-samsung-usb2.ko] undefined!
> > > > ERROR: "usb_add_phy" [drivers/usb/phy/phy-rcar-usb.ko] undefined!
> > > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-rcar-usb.ko] undefined!
> > > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-omap-usb3.ko] undefined!
> > > > ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-omap-usb3.ko] undefined!
> > > > ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-nop.ko] undefined!
> > > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-nop.ko] undefined!
> > > > ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-isp1301.ko] undefined!
> > > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-isp1301.ko] undefined!
> > > > ERROR: "usb_add_phy" [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined!
> > > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-gpio-vbus-usb.ko] 
> > > > undefined!
> > > > ERROR: "usb_get_phy" [drivers/usb/musb/ux500.ko] undefined!
> > > > ERROR: "usb_put_phy" [drivers/usb/musb/ux500.ko] undefined!
> > > > ERROR: "usb_put_phy" [drivers/usb/gadget/pxa27x_udc.ko] undefined!
> > > > ERROR: "usb_get_phy" [drivers/usb/gadget/pxa27x_udc.ko] undefined!
> > > > ERROR: "devm_usb_get_phy" [drivers/usb/gadget/mv_udc.ko] undefined!
> > > > ERROR: "devm_usb_get_phy" [drivers/usb/dwc3/dwc3.ko] undefined!
> > > > ERROR: "devm_usb_get_phy_by_phandle" [drivers/usb/dwc3/dwc3.ko] 
> > > > undefined!
> > > > ERROR: "usb_get_phy" [drivers/usb/chipidea/ci_hdrc.ko] undefined!
> > > > ERROR: "usb_put_phy" [drivers/usb/chipidea/ci_hdrc.ko] undefined!
> > > > ERROR: "usb_get_phy" [drivers/power/isp1704_charger.ko] undefined!
> > > > ERROR: "usb_put_phy" [drivers/power/isp1704_charger.ko] undefined!
> > > > 
> > > > Any ideas?
> > > 
> > > hmm... I think it was Roger's patches changing the way PHY layer is
> > > enabled, do you mind if I drop that for now ? I would have to rebase,
> > > but I guess it's a necessary evil at this point.
> > 
> > I took the silence as a yes and pushed a new tag with Roger's patches
> > removed. I have also removed one musb patch which wasn't necessary after
> > all.
> 
> Sorry for the silence, I went to lunch :)
> 
> > Here's an updated pull request, which I have compiled on ARM and x86
> > and didn't see the linking problem mentioned above:
> 
> Ok, thanks, I'll try it out now...

That worked, now pulled and pushed out, thanks.

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

Re: [RFC v2] xhci: fix dma mask setup in xhci.c

[Xenia Ragiadakou]

On 06/13/2013 01:29 AM, Sarah Sharp wrote:

On Fri, Jun 07, 2013 at 11:37:53PM +0300, Felipe Balbi wrote:

Hi,

On Fri, Jun 07, 2013 at 10:19:23AM -0700, Sarah Sharp wrote:

Adding Felipe.

Xenia, Felipe is the USB "gadget" maintainer, and also added code for
non-PCI xHCI hosts.  Felipe, Xenia is my summer intern through the FOSS
Outreach Program for Women: http://kernelnewbies.org/OPWIntro

Hey, cool Sarah :-)

Welcome Xenia :-)

Ah, slight correction, my intern wants to be called Ksenia.  Xenia is
her legal name, but everyone calls her Ksenia. :)


On Fri, Jun 07, 2013 at 03:00:47PM +0300, Mathias Nyman wrote:

Andy explained his concern in more detail to me irl.

The beef is that the dma_mask is a pointer while dma_coherent_mask
is a u64 value in struct device, and dma_set_mask() fails if
dev->dma_mask doesn't point anywhere.

This is not a problem for PCI enumerated devices because PCI probe
sets a default 32bit mask and makes the dma_mask of all new PCI
devices point to this value.

For non-pci enumerated devices the device dma_mask may be NULL and
dma_set_mask() may fail even if dma is supported on the host
machine.

for example ehci-platform.c solves this by adding:

if (!dev->dev.dma_mask)
 dev->dev.dma_mask =&dev->dev.coherent_dma_mask;
if (!dev->dev.coherent_dma_mask)
 dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);

So it sounds like xhci_plat_setup() in xhci-plat.c needs to do something
similar before it calls xhci_gen_setup().  Felipe, do you agree?

(now, after reading the whole thing...)

I'll agree with that :)


It's funny that the code worked before.  Perhaps setting the dma_mask
pointer should be a separate patch for stable?

sounds like a good plan to me :-)

Great!  Ok, Ksenia, can you create those two patches?  The first patch
in the series should add setting the dma_mask pointer to
xhci_plat_setup().  The second patch will be the same as this patch.
Let me know via IRC if you have any questions.

Sarah Sharp


Yes, of course.

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

Crash in xhci_hcd for 3.10-rc5 (old 3.5.0 bug)

[Jérôme Poulin]

In reference to this email: http://www.spinics.net/lists/linux-usb/msg78711.html

I have exactly the same stack dump with different words, null pointer
dereference.

Plugging a USB3 external disk and using ddrescue will cause this stack dump:
http://postimg.org/image/70fi6f39n/

Hand typed panic follows:
Null pointer dereference at 0x
CPU: 1, PID: 0, Comm: swapper/1
RIP: xhci_stream_id_to_ring

Call Trace:
handle_set_deq_completion.isra
? handle_stopped_cmd_ring
handle_cmd_completion
xhci_handle_event
xhci_irq
xhci_msi_irq
handle_irq_event_percpu
handle_irq_event
handle_edge_irq
handle_irq
do_IRQ
common_interrupt

cpuidle_enter_state
cpuidle_enter_state
cpuidle_idle_call
arch_cpu_idle
cpu_idle_loop
cpu_startup_entry
start_secondary

CR2: 0x28
--
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: Crash in xhci_hcd for 3.10-rc5 (old 3.5.0 bug)

[Greg KH]

On Wed, Jun 12, 2013 at 08:47:30PM -0400, Jérôme Poulin wrote:
> In reference to this email: 
> http://www.spinics.net/lists/linux-usb/msg78711.html
> 
> I have exactly the same stack dump with different words, null pointer
> dereference.
> 
> Plugging a USB3 external disk and using ddrescue will cause this stack dump:
> http://postimg.org/image/70fi6f39n/

This is using the uas driver, right?  That's known to be broken right
now, can you fallback to "old" usb-storage support?

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

Re: [GIT PULL] USB patches for v3.11 merge window

[Felipe Balbi]

Hi,

On Wed, Jun 12, 2013 at 03:37:00PM -0700, Greg KH wrote:
> On Wed, Jun 12, 2013 at 02:31:17PM -0700, Greg KH wrote:
> > On Thu, Jun 13, 2013 at 12:19:02AM +0300, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Wed, Jun 12, 2013 at 11:56:19PM +0300, Felipe Balbi wrote:
> > > > > But, I get a build error with your tree pulled in, at the link point 
> > > > > in
> > > > > time:
> > > > > 
> > > > > ERROR: "usb_add_phy" [drivers/usb/phy/phy-samsung-usb3.ko] undefined!
> > > > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-samsung-usb3.ko] 
> > > > > undefined!
> > > > > ERROR: "usb_add_phy" [drivers/usb/phy/phy-samsung-usb2.ko] undefined!
> > > > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-samsung-usb2.ko] 
> > > > > undefined!
> > > > > ERROR: "usb_add_phy" [drivers/usb/phy/phy-rcar-usb.ko] undefined!
> > > > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-rcar-usb.ko] undefined!
> > > > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-omap-usb3.ko] undefined!
> > > > > ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-omap-usb3.ko] undefined!
> > > > > ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-nop.ko] undefined!
> > > > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-nop.ko] undefined!
> > > > > ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-isp1301.ko] undefined!
> > > > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-isp1301.ko] undefined!
> > > > > ERROR: "usb_add_phy" [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined!
> > > > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-gpio-vbus-usb.ko] 
> > > > > undefined!
> > > > > ERROR: "usb_get_phy" [drivers/usb/musb/ux500.ko] undefined!
> > > > > ERROR: "usb_put_phy" [drivers/usb/musb/ux500.ko] undefined!
> > > > > ERROR: "usb_put_phy" [drivers/usb/gadget/pxa27x_udc.ko] undefined!
> > > > > ERROR: "usb_get_phy" [drivers/usb/gadget/pxa27x_udc.ko] undefined!
> > > > > ERROR: "devm_usb_get_phy" [drivers/usb/gadget/mv_udc.ko] undefined!
> > > > > ERROR: "devm_usb_get_phy" [drivers/usb/dwc3/dwc3.ko] undefined!
> > > > > ERROR: "devm_usb_get_phy_by_phandle" [drivers/usb/dwc3/dwc3.ko] 
> > > > > undefined!
> > > > > ERROR: "usb_get_phy" [drivers/usb/chipidea/ci_hdrc.ko] undefined!
> > > > > ERROR: "usb_put_phy" [drivers/usb/chipidea/ci_hdrc.ko] undefined!
> > > > > ERROR: "usb_get_phy" [drivers/power/isp1704_charger.ko] undefined!
> > > > > ERROR: "usb_put_phy" [drivers/power/isp1704_charger.ko] undefined!
> > > > > 
> > > > > Any ideas?
> > > > 
> > > > hmm... I think it was Roger's patches changing the way PHY layer is
> > > > enabled, do you mind if I drop that for now ? I would have to rebase,
> > > > but I guess it's a necessary evil at this point.
> > > 
> > > I took the silence as a yes and pushed a new tag with Roger's patches
> > > removed. I have also removed one musb patch which wasn't necessary after
> > > all.
> > 
> > Sorry for the silence, I went to lunch :)
> > 
> > > Here's an updated pull request, which I have compiled on ARM and x86
> > > and didn't see the linking problem mentioned above:
> > 
> > Ok, thanks, I'll try it out now...
> 
> That worked, now pulled and pushed out, thanks.

thanks Greg ;-)

-- 
balbi


signature.asc
Description: Digital signature

Fwd: Crash in xhci_hcd for 3.10-rc5 (old 3.5.0 bug)

[Jérôme Poulin]

On Wed, Jun 12, 2013 at 8:51 PM, Greg KH  wrote:
> This is using the uas driver, right?  That's known to be broken right
> now, can you fallback to "old" usb-storage support?

That seems to make sense, I don't have my laptop with me but I can say
I didn't try.

This is one way too old kernel panic bug, this feature should almost
be removed if *this* broken. I know it depends on BROKEN kernel symbol
but it seems Ubuntu's vanilla kernel has it compiled in by default and
help text says to say Y or M to get higher speed, sounds like a deal!

I didn't read more than the 2 first links in Google and didn't know
about the USB Attached SCSI yet.

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

Re: [PATCH v2 0/2] USB: PHY: Improve PHY selection logic

[Felipe Balbi]

On Fri, May 31, 2013 at 02:29:01PM +0300, Roger Quadros wrote:
> Hi,
> 
> Improve Kconfig so that the relevant PHY driver can be explicitely
> selected by the controller driver instead of relying on the user
> to do so.
> 
> Detailed description in patch 1.
> 
> v2:
> - Merge patches 3-5 into the first patch to prevent circular dependency
> between the Kconfig options during bisection.

FYI, these patches were dropped because they cause linking issues as
noted by Greg.

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context

[Ming Lei]

On Wed, Jun 12, 2013 at 3:45 PM, Thomas Gleixner  wrote:
> On Wed, 12 Jun 2013, Ming Lei wrote:
>
> Yes, please. I read through the thread and I really recommend that you
> get rid of the tasklet. tasklets are a complete disaster by design and
> we really should make efforts to get rid of the last users instead of
> trying to work around their semantical shortcomings.

The attached patch001 supports tasklet in HCD and patch002 implements
interrupt threaded handler, then if USB_HCD_THREADED_IRQ
is set, interrupt threaded handler is used to do URB giveback, otherwise
tasklet is used to do that.

The other 3 patches(2/4, 3/4, 4/4) aren't changed now, if anyone want to try it.
(the patch 2 is only for comparing performance difference, and welcome to
review/comment it so that we can get accurate test result to make decision)

Follows the mass storage test result(average over 10 times test) with
tasklet /interrupt threaded handler/hard interrupt handler under  same
environment of lenovo T410(x86), which means the test is switched by
reinserting module of usbcore or ehci-hcd without changing other things
in the machine.

- do below tests 10 times and figure out the average speed

  dd if=/dev/sdN of=/dev/null iflag=direct bs=200M 1

  device: sandisk extreme USB 3.0 16G, host: Lenovo T410 EHCI

- using interrupt threaded handler(default)
33.440 MB/sec

- using tasklet(#undef USB_HCD_THREADED_IRQ)
34.29 MB/sec

- using hard interrupt handler(by removing HCD_BH in ehci-hcd.c )
34.260 MB/s


So looks usb mass storage performance loss can be observed with
interrupt threaded handler because one mass storage read/write sectors
requires at least 3 interrupts which wake up usb-storage thread 3 times
(each interrupt wakeup the usb-storage each time), introducing irq threaded
handler will make 2 threads to be waken up about 6 times for one read/write.

I think usb mass storage transfer handler need to be rewritten, otherwise
it may become worsen after using irq threaded handler in USB 3.0.(the
above device can reach >120MB/sec with hardware handler or tasklet handler,
which means about ~3K interrupts/sec, so ~6K contexts switch in case of
using irq threaded handler)

So how about supporting tasklet first, then convert to interrupt
threaded handler
after usb mass storage transfer is rewritten without performance loss?
(rewriting
usb mass storage transfer handler may need some time and work since storage
stability/correctness is extremely important, :-)

Also another problem with irq threaded handler is that there is no sort of
tasklet_schedule() interface to wakeup the thread handler manually, so
I have to use work to schedule some URB giveback from drivers(root hub
transfer, unlink),  even though that isn't a big deal but will cause code a bit
much/complicated, :-)

Thanks,
--
Ming Lei


0002-USB-support-interrupt-threaded-handler.patch
Description: Binary data


0001-USB-HCD-support-giveback-of-URB-in-tasklet-context.patch
Description: Binary data

Re: [PATCh V10 04/12] usb: ehci: ehci-mv: use PHY driver for ehci

[Chao Xie]

On Thu, May 30, 2013 at 10:23 PM, Alan Stern  wrote:
> On Thu, 30 May 2013, Roger Quadros wrote:
>
>> >> So what are your idea about making the PHY layer more generic? How
>> >> ehci-hcd will make use of PHY layer?
>> >
>> >
>> > on probe grab the phy and initialize it. On suspend/resume,
>> > suspend/resume the PHY and so on. Whatever you were going to do on your
>> > ehci glue, do it on generic ehci-hcd.
>> >
>>
>> These operations sound generic enough to be done at HCD layer, no? So no 
>> need to
>> replicate the same stuff in ohci, ehci, xhci, etc.
>
> The HCD layer handles suspend and resume only for PCI host controllers.
> Not for other types.
>
> I don't know if the acquire/start and stop/release parts can be moved
> into the USB core.  Maybe they can.
>
> Alan Stern
>
hi
The following is my understanding.
I think for PHY initialization and shutdown part, it is generic for
other parts.
PHY initialization need to be called before hc_driver->reset is called.
I think it can be added at usb_add_hcd.
For PHY shutdown, it can be added at usb_remove_hcd.

For suspend/resume, i do not know how to add it. For our EHCI driver,
when system goes to deep idle states, we just directly shutdown the
hcd and initialize it again when the system goes back.
--
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: serial/ftdi_sio.c Fix kernel oops

[Ben Hutchings]

On Fri, 2013-06-07 at 15:14 +0200, Lotfi Manseur wrote:
> Handle null termios in ftdi_set_termios(), introduced in
> commit 552f6bf1bb0eda0011c0525dd587aa9e7ba5b846
> This has been corrected in the mainline by
> commits c515598e0f5769916c31c00392cc2bfe6af74e55 and
> a816e3113b63753c330ca4751ea1d208e93e3015.
> 
> This is to be fixed in longterm 2.6.32.60 and 3.4.47.
> This bug has been found with coccinelle.
> 
> Signed-off-by: Lotfi Manseur 
> Signed-off-by: Nicolas Palix 

I've queued up those changes for 3.2.  This backported version seems
nicer, but we generally prefer to use patches that are as close as
possible to those in mainline.

Ben.

> ---
>  drivers/usb/serial/ftdi_sio.c |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> index c374beb..615bd9e 100644
> --- a/drivers/usb/serial/ftdi_sio.c
> +++ b/drivers/usb/serial/ftdi_sio.c
> @@ -2364,7 +2364,8 @@ static void ftdi_set_termios(struct tty_struct *tty,
>  
>   cflag = termios->c_cflag;
>  
> - if (old_termios->c_cflag == termios->c_cflag
> + if (old_termios
> + && old_termios->c_cflag == termios->c_cflag
>   && old_termios->c_ispeed == termios->c_ispeed
>   && old_termios->c_ospeed == termios->c_ospeed)
>   goto no_c_cflag_changes;
> @@ -2373,7 +2374,8 @@ static void ftdi_set_termios(struct tty_struct *tty,
>  ftdi_sio_read_bulk_callback  - need to examine what this means -
>  don't see any problems yet */
>  
> - if ((old_termios->c_cflag & (CSIZE|PARODD|PARENB|CMSPAR|CSTOPB)) ==
> + if (old_termios &&
> + (old_termios->c_cflag & (CSIZE|PARODD|PARENB|CMSPAR|CSTOPB)) ==
>   (termios->c_cflag & (CSIZE|PARODD|PARENB|CMSPAR|CSTOPB)))
>   goto no_data_parity_stop_changes;
>  

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.


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

Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context

[Ming Lei]

On Wed, Jun 12, 2013 at 10:35 PM, Alan Stern  wrote:
> On Wed, 12 Jun 2013, Ming Lei wrote:
>
>> If not, I am wondering why one USB driver need register another hard
>> interrupt handler? Could you share such examples? I understand the
>> case only exists with timer handler as discussed with Oliver, don't I?
>
> Here's another possibility.  A USB driver has a private lock, and it
> acquires this lock in its completion handler.  But it also acquires
> this lock in other routines, and those other routines may be called by
> other drivers or subsystems in interrupt context.

OK, so the problem is more complicated than I imaged at start, :-(

>
>> > The drivers _do_ need to be changed, as explained above.  And that
>> > explanation was only one failure scenario.  There may be others.
>>
>> OK, I'd like to know what the others are? :-)
>
> Me too.  :-)
>
>> >> And finally, USB HCDs themselves will benefit from the change, won't they?
>> >
>> > How will they benefit?  Merely from not releasing their private locks?
>>
>> The interrupt of one HCD will be responded lately since another HCD's
>> interrupt handler takes very long time. With the change, the problem can
>> be avoided.
>
> For reasonably sophisticated host controllers like EHCI, the delay in
> responding to an interrupt doesn't matter much.  But for simpler host

EHCI might still benefit from the change: suppose uvc video is playing on
one EHCI bus, and mass storage's performance over another EHCI may
decrease because of the IRQ latency introduced.

> controllers (for example, those using PIO instead of DMA) it matters
> more, so those other HCDs will benefit more from the conversion.

Indeed, musb and ehci/ohci are coexisted on OMAP3/4/5.

>> >> Compared with "usb-storage" task's schedule latency, the tasklet
>> >> schedule delay should be lower at most of situations since the tasklet
>> >> is scheduled inside irq handler.
>> >
>> > True.  But the two latencies add.
>>
>> I think it should be one tasklet latency added, but what is the other one?
>
> I meant that the latency in tasklet scheduling has to be added to the
> latency in scheduling the usb-storage thread.
>
>> > Or you could have a separate tasklet for each host controller.
>>
>> Yes, but I will compare tasklet with interrupt threaded handler first.
>
> Switching to a threaded interrupt handler offers more possibilities.
> Instead of moving just the givebacks to the thread, we could put almost
> all the processing there.  (At least, we can for ehci-hcd.  Other HCDs
> may not be able to do this.)
>
> At this point we are talking about multiple changes:
>
> Moving the givebacks to a tasklet or threaded handler.
>
> Changing the USB completion handlers so that they can be called
> with interrupts enabled.
>
> Allowing the tasklet/thread to run with interrupts enabled.
>
> Moving more of the HCD processing into the tasklet/thread.
>
> Maybe other things too.  In principle, the first and second items can
> be done simultaneously.

Very good summery, we can push the 1st change with disabling local IRQ
when calling complete(), so that at least DMA unmapping can be done
with IRQ enabled, and at the same time do the API change, which
should be a bit slow but the mechanical way proposed by Oliver may
be OK.

The 3rd item is easy once the 1st two items are completed.

For the 4th one, it might be a long term thing, since refactoring
HCD interrupt handler is a bit complicated. Also, when the 1st
three items are completed, hard interrupt handler takes less time,
often less than 20us at average about EHCI, so I am wondering
if the 4th is worthy.


Thanks,
--
Ming Lei
--
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

Business Opportunity

[Mr.Chi Pui]

Good day, I Am Chi Pui;Do not be surprised! I got your email contact via the
World Email On-line Directory" I am crediting officer at Sino Pac Bank Plc
in Hong Kong and i have a deal of $17.3M to discuss with you urgently.

Regards,
Mr.Chi Pui

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