USB 3.0 ports drops when using usb3 external hard drive dock.

[Johannes Ylönen]

Problem is that, when I try to move files from usb3 hard drive dock to laptop,
all usb ports drops (all external ports are usb3).

How to reproduce bug:

1. When connecting hard drive dock everything is well, here is log:

Jul 28 10:21:49 localhost kernel: [  520.002851] usb 4-1: new SuperSpeed USB
device number 3 using xhci_hcd
Jul 28 10:21:49 localhost kernel: [  520.019075] scsi8 : usb-storage 4-1:1.0
Jul 28 10:21:50 localhost kernel: [  521.021139] scsi 8:0:0:0: Direct-Access
 Jmicron  Corp. PQ: 0 ANSI: 2 CCS
Jul 28 10:21:50 localhost kernel: [  521.022331] scsi 8:0:0:1: Direct-Access
 Jmicron  Corp. PQ: 0 ANSI: 2 CCS
Jul 28 10:21:50 localhost kernel: [  521.022491] sd 8:0:0:0: [sdd] 976773168
512-byte logical blocks: (500 GB/465 GiB)
Jul 28 10:21:50 localhost kernel: [  521.022848] sd 8:0:0:0: [sdd] Write
Protect is off
Jul 28 10:21:50 localhost kernel: [  521.023540] sd 8:0:0:1: [sde] 625142448
512-byte logical blocks: (320 GB/298 GiB)
Jul 28 10:21:50 localhost kernel: [  521.024695] sd 8:0:0:1: [sde] Write
Protect is off
Jul 28 10:21:50 localhost kernel: [  521.361179]  sde: sde1 sde2  sde5  sde3
sde4
Jul 28 10:21:50 localhost kernel: [  521.407740] sd 8:0:0:1: [sde] Attached
SCSI disk
Jul 28 10:21:50 localhost kernel: [  521.459722]  sdd: sdd1 sdd2 sdd3 sdd4 sdd5
Jul 28 10:21:50 localhost kernel: [  521.463033] sd 8:0:0:0: [sdd] Attached
SCSI disk
Jul 28 10:21:51 localhost udisksd[2065]: Error performing initial housekeeping
for drive
/org/freedesktop/UDisks2/drives/Hitachi_HTS545050A7E380_TE95113Q026ZVP: Error
updating SMART data: sk_disk_smart_status: Input/output error
(udisks-error-quark, 0)
Jul 28 10:21:52 localhost kernel: [  523.234071] NTFS driver 2.1.30 [Flags: R/W
MODULE].
Jul 28 10:21:53 localhost kernel: [  524.000962] EXT4-fs (sde5): warning:
maximal mount count reached, running e2fsck is recommended
Jul 28 10:21:53 localhost kernel: [  524.036259] EXT4-fs (sde5): recovery
complete
Jul 28 10:21:53 localhost kernel: [  524.038287] EXT4-fs (sde5): mounted
filesystem with ordered data mode. Opts: (null)
Jul 28 10:21:53 localhost udisksd[2065]: Mounted /dev/sde5 at
/run/media/louis/Media on behalf of uid 1000
Jul 28 10:21:53 localhost kernel: [  524.109506] NTFS volume version 3.1.
Jul 28 10:21:53 localhost kernel: [  524.418350] EXT4-fs (sde4): recovery
complete
Jul 28 10:21:53 localhost kernel: [  524.418991] EXT4-fs (sde4): mounted
filesystem with ordered data mode. Opts: (null)
Jul 28 10:21:53 localhost udisksd[2065]: Mounted /dev/sde4 at
/run/media/louis/e7014bfa-9606-44bc-a95e-85106ab9a4f1 on behalf of uid 1000
Jul 28 10:21:54 localhost kernel: [  525.316765] EXT4-fs (sde1): recovery
complete
Jul 28 10:21:55 localhost kernel: [  525.644713] EXT4-fs (sde1): mounted
filesystem with ordered data mode. Opts: (null)
Jul 28 10:21:55 localhost udisksd[2065]: Mounted /dev/sde1 at
/run/media/louis/ArchLinux on behalf of uid 1000
Jul 28 10:21:55 localhost kernel: [  526.417040] NTFS volume version 3.1.
Jul 28 10:21:56 localhost udisksd[2065]: Mounted /dev/sdd5 at
/run/media/louis/Recovery on behalf of uid 1000
Jul 28 10:21:56 localhost udisksd[2065]: Mounted /dev/sdd3 at
/run/media/louis/OS on behalf of uid 1000

2. When trying to move files from dock to laptop, that usb port doesn't respond
anymore. Log:

Jul 28 10:24:25 localhost kernel: [  675.410180] xhci_hcd :00:14.0: Timeout
while waiting for address device command
Jul 28 10:24:41 localhost kernel: [  692.259976] xhci_hcd :00:14.0: Timeout
while waiting for address device command
Jul 28 10:24:58 localhost kernel: [  709.216399] xhci_hcd :00:14.0: Timeout
while waiting for reset device command
Jul 28 10:25:15 localhost kernel: [  725.969590] xhci_hcd :00:14.0: Timeout
while waiting for reset device command
Jul 28 10:25:32 localhost udisksd[2065]: Error performing housekeeping for
drive /org/freedesktop/UDisks2/drives/Hitachi_HTS545050A7E380_TE95113Q026ZVP:
Error updating SMART data: sk_disk_check_sleep_mode: Operation not supported
(udisks-error-quark, 0)
Jul 28 10:25:32 localhost kernel: [  742.722908] xhci_hcd :00:14.0: Timeout
while waiting for reset device command
Jul 28 10:25:32 localhost kernel: [  742.722961] sd 8:0:0:1: Device offlined -
not ready after error recovery
Jul 28 10:25:32 localhost kernel: [  742.722969] usb 4-1: USB disconnect,
device number 3
Jul 28 10:25:32 localhost kernel: [  742.722991] sd 8:0:0:1: [sde] killing
request
Jul 28 10:25:32 localhost kernel: [  742.723006] sd 8:0:0:1: [sde] Unhandled
error code
Jul 28 10:25:32 localhost kernel: [  742.723008] sd 8:0:0:1: [sde]  Result:
hostbyte=0x01 driverbyte=0x00
Jul 28 10:25:32 localhost kernel: [  742.723011] sd 8:0:0:1: [sde] CDB:
cdb[0]=0x28: 28 00 03 4e 07 6f 00 00 08 00
Jul 28 10:25:32 localhost udisksd[2065]: Cleaning up mount point
/run/media/louis/Media (device 8:69 no longer exist)
Jul 28 10:25:32 localhost kernel: [  742.755469] xhci_hcd :00:14.0: xHCI
xhci_drop_endpoint called with disabled ep 

Re: [PATCH 3/3] usb: Change persist_enabled when attribute avoid_reset_quirk is modified

[Lan Tianyu]

On 2012年07月30日 15:24, Oliver Neukum wrote:

On Monday 30 July 2012 11:34:11 Lan Tianyu wrote:

--- a/drivers/usb/core/sysfs.c
+++ b/drivers/usb/core/sysfs.c
@@ -209,10 +209,13 @@ set_avoid_reset_quirk(struct device *dev, struct 
device_attribute *attr,
 if (sscanf(buf, %d,val) != 1 || val  0 || val  1)
 return -EINVAL;
 usb_lock_device(udev);
-   if (val)
+   if (val) {
 udev-quirks |= USB_QUIRK_RESET_MORPHS;
-   else
+   udev-persist_enabled = 0;
+   } else {
 udev-quirks= ~USB_QUIRK_RESET_MORPHS;
+   udev-persist_enabled = 1;
+   }
 usb_unlock_device(udev);
 return count;


Hi,

this is on second thought quite problematic. If user space has
disabled the persist feature it must stay disabled, even if
the quirk setting is removed.

Yeah. You are right. So how about remain the persist_enabled 0 or
do nothing with persist_enabled when quirk settting is removed.


Regards
Oliver



--
Best Regards
Tianyu Lan
linux kernel enabling team
--
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: bisected regression, v3.5 - next-20120724: PCI PM causes USB hotplug failure

[Bjørn Mork]

Huang Ying ying.hu...@intel.com writes:

 Do you have time to test the following patch to fix the lspci issue?

 Subject: [BUGFIX] PCI/PM: Keep parent bridge active when read/write config reg


Sure.  But keep this going and I will file a request for modular build
of the PCI subsystem :-)

The patch works fine for me:


nemi:/home/bjorn# lspci -t
-[:00]-+-00.0
   +-02.0
   +-02.1
   +-03.0
   +-19.0
   +-1a.0
   +-1a.1
   +-1a.2
   +-1a.7
   +-1b.0
   +-1c.0-[02]--
   +-1c.1-[03]00.0
   +-1d.0
   +-1d.1
   +-1d.2
   +-1d.7
   +-1e.0-[15]--
   +-1f.0
   +-1f.2
   \-1f.3

nemi:/home/bjorn# lspci -vvnns 1c.1; lspci -vvnns 3:0
00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express 
Port 2 [8086:2942] (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 3000-3fff
Memory behind bridge: f050-f05f
Prefetchable memory behind bridge: c040-c05f
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v1) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, 
L1 1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ 
TransPend-
LnkCap: Port #2, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency 
L0 256ns, L1 4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ 
DLActive+ BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ 
Surprise+
Slot #1, PowerLimit 6.500W; Interlock- NoCompl-
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- 
LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- 
Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ 
Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- 
CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID , PMEStatus- PMEPending-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c  Data: 4143
Capabilities: [90] Subsystem: Lenovo Device [17aa:20f3]
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME-
Capabilities: [100 v1] Virtual Channel
Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
Arb:Fixed+ WRR32- WRR64- WRR128-
Ctrl:   ArbSelect=Fixed
Status: InProgress-
VC0:Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb:Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [180 v1] Root Complex Link
Desc:   PortNumber=02 ComponentID=02 EltType=Config
Link0:  Desc:   TargetPort=00 TargetComponent=02 AssocRCRB- 
LinkType=MemMapped LinkValid+
Addr:   fed1c000
Kernel driver in use: pcieport

03:00.0 Network controller [0280]: Intel Corporation Ultimate N WiFi Link 5300 
[8086:4236]
Subsystem: Intel Corporation Device [8086:1011]
Physical Slot: 1
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Interrupt: pin A routed to IRQ 17
Region 0: Memory at f050 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power 

Re: [PATCH 1/3] usb: Rename temp variable config to val in the set_avoid_reset_quirk()

[Bjørn Mork]

Lan Tianyu tianyu@intel.com writes:

 - if (sscanf(buf, %d, config) != 1 || config  0 || config  1)
 + if (sscanf(buf, %d, val) != 1 || val  0 || val  1)
   return -EINVAL;

Not directly related to this patch, but a question I started wondering
about recently:  Is there some generic guideline wrt parsing boolean
flags in sysfs?  If not, shouldn't there be?

I see a lot of different approaches implementing this basic function.
Personally I would prefer if they all did something like the 
set_usb2_hardware_lpm in drivers/usb/core/sysfs.c:

static ssize_t
set_usb2_hardware_lpm(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
struct usb_device *udev = to_usb_device(dev);
bool value;
int ret;

usb_lock_device(udev);

ret = strtobool(buf, value);

if (!ret)
ret = usb_set_usb2_hardware_lpm(udev, value);

usb_unlock_device(udev);

if (!ret)
return count;

return ret;
}



Using strtobool() to allow Y, yes, 1 etc makes a nice user
interface IMHO.  Unless of course the variable is a true integer which
only happens to currently allow 0 and 1, but may be extended with more
values later.


Bjørn
--
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 v6 04/11] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Kishon Vijay Abraham I]

The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.

Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 249ff76..775e185 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5934,6 +5934,11 @@ static struct omap_hwmod_addr_space 
omap44xx_wd_timer2_addrs[] = {
.pa_end = 0x4a31407f,
.flags  = ADDR_TYPE_RT
},
+   {
+   .pa_start   = 0x4a00233c,
+   .pa_end = 0x4a00233f,
+   .flags  = ADDR_TYPE_RT
+   },
{ }
 };
 
-- 
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 v6 08/11] arm/dts: Add twl4030-usb data

[Kishon Vijay Abraham I]

Add twl4030-usb data node in twl4030 device tree file.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/boot/dts/twl4030.dtsi |   21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 22f4d13..761a5a5 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -37,6 +37,18 @@
regulator-max-microvolt = 315;
};
 
+   vusb1v5: regulator-vusb1v5 {
+   compatible = ti,twl4030-vusb1v5;
+   };
+
+   vusb1v8: regulator-vusb1v8 {
+   compatible = ti,twl4030-vusb1v8;
+   };
+
+   vusb3v1: regulator-vusb3v1 {
+   compatible = ti,twl4030-vusb3v1;
+   };
+
twl_gpio: gpio {
compatible = ti,twl4030-gpio;
gpio-controller;
@@ -44,4 +56,13 @@
interrupt-controller;
#interrupt-cells = 1;
};
+
+   twl4030-usb {
+   compatible = ti,twl4030-usb;
+   interrupts =  10 4 ;
+   usb1v5-supply = vusb1v5;
+   usb1v8-supply = vusb1v8;
+   usb3v1-supply = vusb3v1;
+   usb_mode = 1;
+   };
 };
-- 
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 v6 03/11] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2

[Kishon Vijay Abraham I]

All the PHY configuration other than VBUS, ID GND and OTG SRP are removed
from twl6030. The phy configurations are taken care by the dedicated
usb2 phy driver. So twl6030 is made as comparator driver for VBUS and
ID detection.

Writing to control module which is now handled in omap2430.c should be
removed once a driver for control module is in place.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/musb/omap2430.c   |   52 ---
 drivers/usb/musb/omap2430.h   |9 
 drivers/usb/otg/twl6030-usb.c |  114 +
 3 files changed, 67 insertions(+), 108 deletions(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 5fdb9da..addbebf 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -44,6 +44,7 @@ struct omap2430_glue {
struct platform_device  *musb;
enum omap_musb_vbus_id_status status;
struct work_struct  omap_musb_mailbox_work;
+   u32 __iomem *control_otghs;
 };
 #define glue_to_musb(g)platform_get_drvdata(g-musb)
 
@@ -51,6 +52,26 @@ struct omap2430_glue *_glue;
 
 static struct timer_list musb_idle_timer;
 
+/**
+ * omap4_usb_phy_mailbox - write to usb otg mailbox
+ * @glue: struct omap2430_glue *
+ * @val: the value to be written to the mailbox
+ *
+ * On detection of a device (ID pin is grounded), this API should be called
+ * to set AVALID, VBUSVALID and ID pin is grounded.
+ *
+ * When OMAP is connected to a host (OMAP in device mode), this API
+ * is called to set AVALID, VBUSVALID and ID pin in high impedance.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
+ * control module
+ */
+static void omap4_usb_phy_mailbox(struct omap2430_glue *glue, u32 val)
+{
+   if (glue-control_otghs)
+   writel(val, glue-control_otghs);
+}
+
 static void musb_do_idle(unsigned long _musb)
 {
struct musb *musb = (void *)_musb;
@@ -245,6 +266,7 @@ EXPORT_SYMBOL_GPL(omap_musb_mailbox);
 
 static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 {
+   u32 val;
struct musb *musb = glue_to_musb(glue);
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *pdata = dev-platform_data;
@@ -260,7 +282,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue 
*glue)
musb-xceiv-last_event = USB_EVENT_ID;
if (!is_otg_enabled(musb) || musb-gadget_driver) {
pm_runtime_get_sync(dev);
-   usb_phy_init(musb-xceiv);
+   val = AVALID | VBUSVALID;
+   omap4_usb_phy_mailbox(glue, val);
omap2430_musb_set_vbus(musb, 1);
}
break;
@@ -273,7 +296,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue 
*glue)
musb-xceiv-last_event = USB_EVENT_VBUS;
if (musb-gadget_driver)
pm_runtime_get_sync(dev);
-   usb_phy_init(musb-xceiv);
+   val = IDDIG | AVALID | VBUSVALID;
+   omap4_usb_phy_mailbox(glue, val);
break;
 
case OMAP_MUSB_ID_FLOAT:
@@ -291,7 +315,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue 
*glue)
if (musb-xceiv-otg-set_vbus)
otg_set_vbus(musb-xceiv-otg, 0);
}
-   usb_phy_shutdown(musb-xceiv);
+   val = SESSEND | IDDIG;
+   omap4_usb_phy_mailbox(glue, val);
break;
default:
dev_dbg(dev, ID float\n);
@@ -366,6 +391,7 @@ err1:
 static void omap2430_musb_enable(struct musb *musb)
 {
u8  devctl;
+   u32 val;
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
struct device *dev = musb-controller;
struct omap2430_glue *glue = dev_get_drvdata(dev-parent);
@@ -375,7 +401,8 @@ static void omap2430_musb_enable(struct musb *musb)
switch (glue-status) {
 
case OMAP_MUSB_ID_GROUND:
-   usb_phy_init(musb-xceiv);
+   val = AVALID | VBUSVALID;
+   omap4_usb_phy_mailbox(glue, val);
if (data-interface_type != MUSB_INTERFACE_UTMI)
break;
devctl = musb_readb(musb-mregs, MUSB_DEVCTL);
@@ -394,7 +421,8 @@ static void omap2430_musb_enable(struct musb *musb)
break;
 
case OMAP_MUSB_VBUS_VALID:
-   usb_phy_init(musb-xceiv);
+   val = IDDIG | AVALID | VBUSVALID;
+   omap4_usb_phy_mailbox(glue, val);
break;
 
default:
@@ -404,11 +432,14 @@ static void omap2430_musb_enable(struct musb *musb)
 
 static void omap2430_musb_disable(struct musb *musb)
 {
+   u32 val;
struct device *dev = musb-controller;
struct omap2430_glue *glue = 

[PATCH v6 05/11] drivers: usb: twl6030: Add dt support for twl6030 usb

[Kishon Vijay Abraham I]

Add device tree support for twl6030 usb driver.
Update the Documentation with device tree binding information.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 .../devicetree/bindings/usb/twl-usb.txt|   21 +++
 drivers/usb/otg/twl6030-usb.c  |   39 +---
 2 files changed, 47 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt

diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt 
b/Documentation/devicetree/bindings/usb/twl-usb.txt
new file mode 100644
index 000..930f9ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -0,0 +1,21 @@
+USB COMPARATOR OF TWL CHIPS
+
+TWL6030 USB COMPARATOR
+ - compatible : Should be ti,twl6030-usb
+ - interrupts : Two interrupt numbers to the cpu should be specified. First
+   interrupt number is the otg interrupt number that raises ID interrupts when
+   the controller has to act as host and the second interrupt number is the
+   usb interrupt number that raises VBUS interrupts when the controller has to
+   act as device
+ - usb-supply : phandle to the regulator device tree node. It should be vusb
+   if it is twl6030 or ldousb if it is twl6025 subclass.
+
+twl6030-usb {
+   compatible = ti,twl6030-usb;
+   interrupts =  4 10 ;
+};
+
+Board specific device node entry
+twl6030-usb {
+   usb-supply = vusb;
+};
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 6a361d2..f29c9ef 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -105,7 +105,7 @@ struct twl6030_usb {
u8  asleep;
boolirq_enabled;
boolvbus_enable;
-   unsigned long   features;
+   const char  *regulator;
 };
 
 #definecomparator_to_twl(x) container_of((x), struct twl6030_usb, 
comparator)
@@ -153,13 +153,6 @@ static int twl6030_start_srp(struct phy_companion 
*comparator)
 
 static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
 {
-   char *regulator_name;
-
-   if (twl-features  TWL6025_SUBCLASS)
-   regulator_name = ldousb;
-   else
-   regulator_name = vusb;
-
/* Set to OTG_REV 1.3 and turn on the ID_WAKEUP_COMP */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x1, TWL6030_BACKUP_REG);
 
@@ -169,7 +162,7 @@ static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
/* Program MISC2 register and set bit VUSB_IN_VBAT */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x10, TWL6030_MISC2);
 
-   twl-usb3v3 = regulator_get(twl-dev, regulator_name);
+   twl-usb3v3 = regulator_get(twl-dev, twl-regulator);
if (IS_ERR(twl-usb3v3))
return -ENODEV;
 
@@ -324,9 +317,9 @@ static int __devinit twl6030_usb_probe(struct 
platform_device *pdev)
 {
struct twl6030_usb  *twl;
int status, err;
-   struct twl4030_usb_data *pdata;
-   struct device *dev = pdev-dev;
-   pdata = dev-platform_data;
+   struct device_node  *np = pdev-dev.of_node;
+   struct device   *dev = pdev-dev;
+   struct twl4030_usb_data *pdata = dev-platform_data;
 
twl = devm_kzalloc(dev, sizeof *twl, GFP_KERNEL);
if (!twl)
@@ -335,13 +328,24 @@ static int __devinit twl6030_usb_probe(struct 
platform_device *pdev)
twl-dev= pdev-dev;
twl-irq1   = platform_get_irq(pdev, 0);
twl-irq2   = platform_get_irq(pdev, 1);
-   twl-features   = pdata-features;
twl-linkstat   = OMAP_MUSB_UNKNOWN;
 
twl-comparator.set_vbus= twl6030_set_vbus;
twl-comparator.start_srp   = twl6030_start_srp;
omap_usb2_set_comparator(twl-comparator);
 
+   if (np) {
+   twl-regulator = usb;
+   } else if (pdata) {
+   if (pdata-features  TWL6025_SUBCLASS)
+   twl-regulator = ldousb;
+   else
+   twl-regulator = vusb;
+   } else {
+   dev_err(pdev-dev, twl6030 initialized without pdata\n);
+   return -EINVAL;
+   }
+
/* init spinlock for workqueue */
spin_lock_init(twl-lock);
 
@@ -403,12 +407,21 @@ static int __exit twl6030_usb_remove(struct 
platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id twl6030_usb_id_table[] = {
+   { .compatible = ti,twl6030-usb },
+   {}
+};
+MODULE_DEVICE_TABLE(of, twl6030_usb_id_table);
+#endif
+
 static struct platform_driver twl6030_usb_driver = {
.probe  = twl6030_usb_probe,
.remove = __exit_p(twl6030_usb_remove),
.driver = {
.name   = twl6030_usb,
.owner  = THIS_MODULE,
+   .of_match_table = of_match_ptr(twl6030_usb_id_table),

Re: [PATCH 00/12] chipidea/imx: add otg support and some bug fix

[Richard Zhao]

On Thu, Jul 26, 2012 at 06:59:48PM +0800, Richard Zhao wrote:
 On Thu, Jul 19, 2012 at 10:05:54AM +0800, Richard Zhao wrote:
  On Mon, Jul 16, 2012 at 05:40:57PM -0700, Greg KH wrote:
   On Thu, Jul 12, 2012 at 03:01:40PM +0800, Richard Zhao wrote:
The patch set is tested on imx6q_sabrelite board.

The patch can also be found at
https://github.com/riczhao/kernel-imx/commits/topics/usb-driver

For test which merged platform patches:
https://github.com/riczhao/kernel-imx/commits/topics/usb-test

It's better apply after patch I sent out:
usb: chipidea: cleanup dma_pool if udc_start() fails
   
   I need acks from Alexander before I can accept any of these.
  ping Alexander ...
 ping Alexander again ...
Hi Greg,

Is there a better way but keeping waiting?

Hi Felipe,

Could you help review the patch series?

Thanks
Richard
 
 --
 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: [PATCH v3 1/3] USB: chipidea: add imx usbmisc support

[Sascha Hauer]

On Thu, Jul 26, 2012 at 06:35:14PM +0800, Richard Zhao wrote:
 i.MX usb controllers shares non-core registers, which may include
 SoC specific controls. We take it as a usbmisc device and usbmisc
 driver set operations needed by ci13xxx_imx driver.
 
 For example, Sabrelite board has bad over-current design, we can
 usbmisc to disable over-current detect.
 
 Signed-off-by: Richard Zhao richard.z...@freescale.com
 ---
  .../devicetree/bindings/usb/ci13xxx-imx.txt|2 +
  .../devicetree/bindings/usb/usbmisc-imx.txt|   12 ++
  drivers/usb/chipidea/Makefile  |3 +-
  drivers/usb/chipidea/ci13xxx_imx.c |   72 -
  drivers/usb/chipidea/usbmisc_imx6q.c   |  155 
 
  5 files changed, 242 insertions(+), 2 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/usb/usbmisc-imx.txt
  create mode 100644 drivers/usb/chipidea/usbmisc_imx6q.c
 
 diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt 
 b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
 index 2c29041..06105ce 100644
 --- a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
 +++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
 @@ -8,6 +8,7 @@ Required properties:
  Optional properties:
  - fsl,usbphy: phandler of usb phy that connects to the only one port
  - vbus-supply: regulator for vbus
 +- disable-over-current: disable over current detect
  
  Examples:
  usb@02184000 { /* USB OTG */
 @@ -15,4 +16,5 @@ usb@02184000 { /* USB OTG */
   reg = 0x02184000 0x200;
   interrupts = 0 43 0x04;
   fsl,usbphy = usbphy1;
 + disable-over-current;
  };
 diff --git a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt 
 b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
 new file mode 100644
 index 000..4fa500d
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
 @@ -0,0 +1,12 @@
 +* Freescale i.MX non-core registers
 +
 +Required properties:
 +- compatible: Should be one of below:
 + fsl,imx6q-usbmisc for imx6q
 +- reg: Should contain registers location and length
 +
 +Examples:
 +usbmisc@02184800 {
 + compatible = fsl,imx6q-usbmisc;
 + reg = 0x02184800 0x200;
 +};
 diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
 index 5c66d9c..36f94c9d 100644
 --- a/drivers/usb/chipidea/Makefile
 +++ b/drivers/usb/chipidea/Makefile
 @@ -15,5 +15,6 @@ ifneq ($(CONFIG_PCI),)
  endif
  
  ifneq ($(CONFIG_OF_DEVICE),)
 - obj-$(CONFIG_USB_CHIPIDEA)  += ci13xxx_imx.o
 + obj-$(CONFIG_USB_CHIPIDEA)  += ci13xxx-imx.o
 + ci13xxx-imx-y   := ci13xxx_imx.o usbmisc_imx6q.o
  endif
 diff --git a/drivers/usb/chipidea/ci13xxx_imx.c 
 b/drivers/usb/chipidea/ci13xxx_imx.c
 index ef60d06..d178889 100644
 --- a/drivers/usb/chipidea/ci13xxx_imx.c
 +++ b/drivers/usb/chipidea/ci13xxx_imx.c
 @@ -22,6 +22,7 @@
  #include linux/regulator/consumer.h
  
  #include ci.h
 +#include ci13xxx_imx.h
  
  #define pdev_to_phy(pdev) \
   ((struct usb_phy *)platform_get_drvdata(pdev))
 @@ -34,6 +35,48 @@ struct ci13xxx_imx_data {
   struct regulator *reg_vbus;
  };
  
 +static const struct usbmisc_ops *usbmisc_ops;
 +
 +/* Common functions shared by usbmisc drivers */
 +
 +int usbmisc_set_ops(const struct usbmisc_ops *ops)
 +{
 + if (usbmisc_ops)
 + return -EBUSY;
 +
 + usbmisc_ops = ops;
 +
 + return 0;
 +}
 +
 +void usbmisc_unset_ops(const struct usbmisc_ops *ops)
 +{
 + usbmisc_ops = NULL;
 +}
 +
 +int usbmisc_get_init_data(struct device *dev, struct usbmisc_usb_device 
 *usbdev)
 +{
 + struct device_node *np = dev-of_node;
 + int id;
 +
 + usbdev-dev = dev;
 +
 + id = of_alias_get_id(np, usb);
 + if (id  0) {
 + dev_err(dev, Failed to get alias id, errno %d\n, id);
 + memset(usbdev, 0, sizeof(*usbdev));
 + return id;
 + }
 + usbdev-index = id;
 +
 + if (of_find_property(np, disable-over-current, NULL))
 + usbdev-disable_oc = 1;
 +
 + return 0;
 +}
 +
 +/* End of common functions shared by usbmisc drivers*/
 +
  static struct ci13xxx_platform_data ci13xxx_imx_platdata __devinitdata  = {
   .name   = ci13xxx_imx,
   .flags  = CI13XXX_REQUIRE_TRANSCEIVER |
 @@ -120,6 +163,16 @@ static int __devinit ci13xxx_imx_probe(struct 
 platform_device *pdev)
   *pdev-dev.dma_mask = DMA_BIT_MASK(32);
   dma_set_coherent_mask(pdev-dev, *pdev-dev.dma_mask);
   }
 +
 + if (usbmisc_ops  usbmisc_ops-init) {
 + ret = usbmisc_ops-init(pdev-dev);
 + if (ret) {
 + dev_err(pdev-dev,
 + usbmisc init failed, ret=%d\n, ret);
 + return ret;
 + }
 + }
 +
   plat_ci = ci13xxx_add_device(pdev-dev,
   pdev-resource, pdev-num_resources,
 

Re: [PATCH v3 1/3] USB: chipidea: add imx usbmisc support

[Richard Zhao]

On Mon, Jul 30, 2012 at 11:32:44AM +0200, Sascha Hauer wrote:
 On Thu, Jul 26, 2012 at 06:35:14PM +0800, Richard Zhao wrote:
  i.MX usb controllers shares non-core registers, which may include
  SoC specific controls. We take it as a usbmisc device and usbmisc
  driver set operations needed by ci13xxx_imx driver.
  
  For example, Sabrelite board has bad over-current design, we can
  usbmisc to disable over-current detect.
  
  Signed-off-by: Richard Zhao richard.z...@freescale.com
  ---
   .../devicetree/bindings/usb/ci13xxx-imx.txt|2 +
   .../devicetree/bindings/usb/usbmisc-imx.txt|   12 ++
   drivers/usb/chipidea/Makefile  |3 +-
   drivers/usb/chipidea/ci13xxx_imx.c |   72 -
   drivers/usb/chipidea/usbmisc_imx6q.c   |  155 
  
   5 files changed, 242 insertions(+), 2 deletions(-)
   create mode 100644 Documentation/devicetree/bindings/usb/usbmisc-imx.txt
   create mode 100644 drivers/usb/chipidea/usbmisc_imx6q.c
  
  diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt 
  b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
  index 2c29041..06105ce 100644
  --- a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
  +++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
  @@ -8,6 +8,7 @@ Required properties:
   Optional properties:
   - fsl,usbphy: phandler of usb phy that connects to the only one port
   - vbus-supply: regulator for vbus
  +- disable-over-current: disable over current detect
   
   Examples:
   usb@02184000 { /* USB OTG */
  @@ -15,4 +16,5 @@ usb@02184000 { /* USB OTG */
  reg = 0x02184000 0x200;
  interrupts = 0 43 0x04;
  fsl,usbphy = usbphy1;
  +   disable-over-current;
   };
  diff --git a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt 
  b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
  new file mode 100644
  index 000..4fa500d
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
  @@ -0,0 +1,12 @@
  +* Freescale i.MX non-core registers
  +
  +Required properties:
  +- compatible: Should be one of below:
  +   fsl,imx6q-usbmisc for imx6q
  +- reg: Should contain registers location and length
  +
  +Examples:
  +usbmisc@02184800 {
  +   compatible = fsl,imx6q-usbmisc;
  +   reg = 0x02184800 0x200;
  +};
  diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
  index 5c66d9c..36f94c9d 100644
  --- a/drivers/usb/chipidea/Makefile
  +++ b/drivers/usb/chipidea/Makefile
  @@ -15,5 +15,6 @@ ifneq ($(CONFIG_PCI),)
   endif
   
   ifneq ($(CONFIG_OF_DEVICE),)
  -   obj-$(CONFIG_USB_CHIPIDEA)  += ci13xxx_imx.o
  +   obj-$(CONFIG_USB_CHIPIDEA)  += ci13xxx-imx.o
  +   ci13xxx-imx-y   := ci13xxx_imx.o usbmisc_imx6q.o
   endif
  diff --git a/drivers/usb/chipidea/ci13xxx_imx.c 
  b/drivers/usb/chipidea/ci13xxx_imx.c
  index ef60d06..d178889 100644
  --- a/drivers/usb/chipidea/ci13xxx_imx.c
  +++ b/drivers/usb/chipidea/ci13xxx_imx.c
  @@ -22,6 +22,7 @@
   #include linux/regulator/consumer.h
   
   #include ci.h
  +#include ci13xxx_imx.h
   
   #define pdev_to_phy(pdev) \
  ((struct usb_phy *)platform_get_drvdata(pdev))
  @@ -34,6 +35,48 @@ struct ci13xxx_imx_data {
  struct regulator *reg_vbus;
   };
   
  +static const struct usbmisc_ops *usbmisc_ops;
  +
  +/* Common functions shared by usbmisc drivers */
  +
  +int usbmisc_set_ops(const struct usbmisc_ops *ops)
  +{
  +   if (usbmisc_ops)
  +   return -EBUSY;
  +
  +   usbmisc_ops = ops;
  +
  +   return 0;
  +}
  +
  +void usbmisc_unset_ops(const struct usbmisc_ops *ops)
  +{
  +   usbmisc_ops = NULL;
  +}
  +
  +int usbmisc_get_init_data(struct device *dev, struct usbmisc_usb_device 
  *usbdev)
  +{
  +   struct device_node *np = dev-of_node;
  +   int id;
  +
  +   usbdev-dev = dev;
  +
  +   id = of_alias_get_id(np, usb);
  +   if (id  0) {
  +   dev_err(dev, Failed to get alias id, errno %d\n, id);
  +   memset(usbdev, 0, sizeof(*usbdev));
  +   return id;
  +   }
  +   usbdev-index = id;
  +
  +   if (of_find_property(np, disable-over-current, NULL))
  +   usbdev-disable_oc = 1;
  +
  +   return 0;
  +}
  +
  +/* End of common functions shared by usbmisc drivers*/
  +
   static struct ci13xxx_platform_data ci13xxx_imx_platdata __devinitdata  = {
  .name   = ci13xxx_imx,
  .flags  = CI13XXX_REQUIRE_TRANSCEIVER |
  @@ -120,6 +163,16 @@ static int __devinit ci13xxx_imx_probe(struct 
  platform_device *pdev)
  *pdev-dev.dma_mask = DMA_BIT_MASK(32);
  dma_set_coherent_mask(pdev-dev, *pdev-dev.dma_mask);
  }
  +
  +   if (usbmisc_ops  usbmisc_ops-init) {
  +   ret = usbmisc_ops-init(pdev-dev);
  +   if (ret) {
  +   dev_err(pdev-dev,
  +   usbmisc init failed, ret=%d\n, ret);
  +   return ret;
  +   }
  +   }
  +
  plat_ci = 

Re: [PATCH 3/3] usb: Change persist_enabled when attribute avoid_reset_quirk is modified

[Oliver Neukum]

On Monday 30 July 2012 15:58:25 Lan Tianyu wrote:
 On 2012年07月30日 15:24, Oliver Neukum wrote:

  this is on second thought quite problematic. If user space has
  disabled the persist feature it must stay disabled, even if
  the quirk setting is removed.
 Yeah. You are right. So how about remain the persist_enabled 0 or
 do nothing with persist_enabled when quirk settting is removed.

Hi,

this leads to behavior that is not easy to predict or understand.
It would be cleaner to leave the flag alone and check for the quirk
in addition for the flag when the check is done.

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 v6 01/11] drivers: usb: otg: add a new driver for omap usb2 phy

[Shubhrajyoti]

On Monday 30 July 2012 03:16 PM, ABRAHAM, KISHON VIJAY wrote:
 Hi,

 On Mon, Jul 30, 2012 at 3:07 PM, Shubhrajyoti shubhrajy...@ti.com wrote:
 On Monday 30 July 2012 02:39 PM, Kishon Vijay Abraham I wrote:
 + writel(~PHY_PD, phy-control_dev);
 + /* XXX: add proper documentation for this delay */
 + mdelay(200);
 Do you need this to be busy?
 This might be called from interrupt context. This delay was initially
 added in omap_phy_internal.c and I just inherited it.
Thanks for the explanation.

 Thanks
 Kishon

--
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 v3] usb: dwc3: Introduce OTG driver for dwc3

[Ido Shayevitz]

Hi Anton,

On Mon, July 30, 2012 5:25 am, Anton Tikhomirov wrote:
 Hi Ido,

 
  You activate sm only if gadget and host are ready. At the same time,
  in dwc3_otg_interrupt() you schedule work if interrupt happens. In
  situation
  when host is not set yet, but cable is plugged, we will have unwanted
 sm
  activation
  (in interrupt handler) and, as a consequence, repeating error unable
 to
  start A-device\n
  in dwc3_otg_sm_work().

 Host and gadget should set themselves to the otg on drivers probe, in
 boot
 time. So cable connect happens later.
 If the scenario you describe does happen it means that the xHCI driver
 was
 not loaded into the kernel, but cable with micro-A was plugged into your
 device, so need add host support to the menuconfig.
 It should be enough to select in the menuconfig CONFIG_USB and
 CONFIG_USB_XHCI_HCD.

 Agree. But what if my controller supports DRD mode, but I _want_ to keep
 this
 option (XHCI support) off, for any reason. By the way, it seems we will
 have
 similar effect when micro-A cable is plugged after otg_set_host(phy-otg,
 NULL)
 call. Of course such situations are rare.


OK, so I will avoid the re-schedule of the sm_work after this error will
be printed (so will be printed once...)
Thanks...

 But if your controller DWC_MODE (see core.c) does not support DRD, or
 the
 cable plugged in is micro-B then this error should not be printed
 eventhough the host was not set.

   +  } else {
   +  if (otg-phy-state == OTG_STATE_A_HOST) {
   +  dwc3_otg_start_host(otg, 0);
   +  otg-host = NULL;
   +  otg-phy-state = OTG_STATE_UNDEFINED;
   +  schedule_work(dotg-sm_work);
   +  } else {
   +  otg-host = NULL;
   +  }
   +  }
   +
   +  return 0;
   +}
   +
   +/**
   + * dwc3_otg_start_peripheral -  bind/unbind the peripheral
  controller.
   + *
   + * @otg: Pointer to the otg_transceiver structure.
   + * @gadget: pointer to the usb_gadget structure.
  
   This comment doesn't match the function definition (@on, not
 @gadget).
  
   + *
   + * Returns 0 on success otherwise negative errno.
   + */
   +static int dwc3_otg_start_peripheral(struct usb_otg *otg, int on)
   +{
   +  struct dwc3_otg *dotg = container_of(otg, struct dwc3_otg,
 otg);
   +
   +  if (!otg-gadget)
   +  return -EINVAL;
   +
   +  if (on) {
   +  dev_dbg(otg-phy-dev, %s: turn on gadget %s\n,
   +  __func__,
 otg-gadget-name);
   +  dwc3_otg_set_peripheral_regs(dotg);
   +  usb_gadget_vbus_connect(otg-gadget);
   +  } else {
   +  dev_dbg(otg-phy-dev, %s: turn off gadget %s\n,
   +  __func__,
 otg-gadget-name);
   +  usb_gadget_vbus_disconnect(otg-gadget);
   +  }
   +
   +  return 0;
   +}
   +
   +/**
   + * dwc3_otg_set_peripheral -  bind/unbind the peripheral
 controller
   driver.
   + *
   + * @otg: Pointer to the otg_transceiver structure.
   + * @gadget: pointer to the usb_gadget structure.
   + *
   + * Returns 0 on success otherwise negative errno.
   + */
   +static int dwc3_otg_set_peripheral(struct usb_otg *otg,
   +  struct usb_gadget *gadget)
   +{
   +  struct dwc3_otg *dotg = container_of(otg, struct dwc3_otg,
 otg);
   +
   +  if (gadget) {
   +  dev_dbg(otg-phy-dev, %s: set gadget %s\n,
   +  __func__, gadget-name);
   +  otg-gadget = gadget;
   +
   +  /*
   +   * Only after both peripheral and host are set then
 check
   +   * OTG sm. This prevents unnecessary activation of
 the
 sm
   +   * in case the ID is grounded.
   +   */
   +  if (otg-host)
   +  schedule_work(dotg-sm_work);
   +  } else {
   +  if (otg-phy-state == OTG_STATE_B_PERIPHERAL) {
   +  dwc3_otg_start_peripheral(otg, 0);
   +  otg-gadget = NULL;
   +  otg-phy-state = OTG_STATE_UNDEFINED;
   +  schedule_work(dotg-sm_work);
   +  } else {
   +  otg-gadget = NULL;
   +  }
   +  }
   +
   +  return 0;
   +}
   +
   +/**
   + * dwc3_otg_interrupt - interrupt handler for dwc3 otg events.
  
   You forgot about @irq here.
  
   + * @_dotg: Pointer to out controller context structure
   + *
   + * Returns IRQ_HANDLED on success otherwise IRQ_NONE.
   + */
   +static irqreturn_t dwc3_otg_interrupt(int irq, void *_dotg)
   +{
   +  struct dwc3_otg *dotg = (struct dwc3_otg *)_dotg;
   +  u32 oevt_reg;
   +  int ret = IRQ_NONE;
   +  u32 handled_irqs = 0;
   +
   +  oevt_reg = dwc3_readl(dotg-regs, DWC3_OEVT);
   +
   +  if (oevt_reg  

Re: [PATCH] usb: serial: mos7840: Avoid kfree() on bad pointer

[Sergei Shtylyov]

Hello.

On 07/24/2012 11:17 PM, Mark Ferrell wrote:

 * mos7840_startup() blindly calls kfree() on memory that may have never been
   allocated.

   Callling kfree() on NULL pointers is valid.

 Signed-off-by: Mark Ferrell mferr...@uplogix.com

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 1/3] usb: Rename temp variable config to val in the set_avoid_reset_quirk()

[Michal Nazarewicz]

On Mon, 30 Jul 2012 10:33:27 +0200, Bjørn Mork bj...@mork.no wrote:

Lan Tianyu tianyu@intel.com writes:
Not directly related to this patch, but a question I started wondering
about recently:  Is there some generic guideline wrt parsing boolean
flags in sysfs?  If not, shouldn't there be?

I see a lot of different approaches implementing this basic function.
Personally I would prefer if they all did something like the
set_usb2_hardware_lpm in drivers/usb/core/sysfs.c:


[...]

ret = strtobool(buf, value);

[...]


Using strtobool() to allow Y, yes, 1 etc makes a nice user
interface IMHO.  Unless of course the variable is a true integer which
only happens to currently allow 0 and 1, but may be extended with more
values later.


I'd say that if someone is handling sysfs directly, he has burn in his brain
that 0 is false and 1 is true. ;)  (Shell complicates things a little, but
still I feel that for sysfs users the connection is obvious.)  Because of that,
I stick to kstrtouint().

Also, I don't like how strtobool() treats 01 as a false value.

--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--
--
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]staging: usbip: Fix typos.

[Justin P. Mattock]

From: Justin P. Mattock justinmatt...@gmail.com

Signed-off-by: Justin P. Mattock justinmatt...@gmail.com

---

The below patch fixes typos found while reading through staging: usbip

 drivers/staging/usbip/stub_rx.c  |2 +-
 drivers/staging/usbip/vhci_hcd.c |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/usbip/stub_rx.c b/drivers/staging/usbip/stub_rx.c
index 1d5b3fc..694cfd7 100644
--- a/drivers/staging/usbip/stub_rx.c
+++ b/drivers/staging/usbip/stub_rx.c
@@ -155,7 +155,7 @@ static int tweak_set_configuration_cmd(struct urb *urb)
 * eventually reassigned to the device as far as driver matching
 * condition is kept.
 *
-* Unfortunatelly, an existing usbip connection will be dropped
+* Unfortunately, an existing usbip connection will be dropped
 * due to this driver unbinding. So, skip here.
 * A user may need to set a special configuration value before
 * exporting the device.
diff --git a/drivers/staging/usbip/vhci_hcd.c b/drivers/staging/usbip/vhci_hcd.c
index 12a9a5f..dd15dc0 100644
--- a/drivers/staging/usbip/vhci_hcd.c
+++ b/drivers/staging/usbip/vhci_hcd.c
@@ -828,11 +828,11 @@ static void vhci_shutdown_connection(struct usbip_device 
*ud)
 *  disable endpoints. pending urbs are unlinked(dequeued).
 *
 * NOTE: After calling rh_port_disconnect(), the USB device drivers of a
-* deteched device should release used urbs in a cleanup function(i.e.
+* detached device should release used urbs in a cleanup function(i.e.
 * xxx_disconnect()). Therefore, vhci_hcd does not need to release
 * pushed urbs and their private data in this function.
 *
-* NOTE: vhci_dequeue() must be considered carefully. When shutdowning
+* NOTE: vhci_dequeue() must be considered carefully. When shuting down
 * a connection, vhci_shutdown_connection() expects vhci_dequeue()
 * gives back pushed urbs and frees their private data by request of
 * the cleanup function of a USB driver. When unlinking a urb with an
-- 
1.7.5.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 ebeam PATCH 3/3] input: misc: New USB eBeam input driver.

[Yann Cantin]

Hi,

 The code structure (device selector + functions indirection) also seems 
 overkill
 to me for now, but permit to anticipate device's variations. If it appears 
 that they
 all works in the same way, it'll be easy (and more comfortable to me) to 
 step down,
 the opposite seems more difficult.
 
 Actually I am hesitant to add infrastructure if it is unclear if we need
 it at all.

Understand.

I've thrown some hook to see if i can get my hands on other devices.

In the meantime, i'll bet on uniform support and strip down the driver. Wish me 
luck.

Thanks.
-- 
Yann Cantin
A4FEB47F
--
--
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: Take attribute avoid_reset_quirk out of usb device's attribute group

[Alan Stern]

On Mon, 30 Jul 2012, Oliver Neukum wrote:

 On Monday 30 July 2012 11:34:10 Lan Tianyu wrote:
  The hub is always supposed to support reset and its persist is enabled.
 
 By default, not necessarily always. User space may disable it.

No -- necessarily always.  Userspace cannot disable it.  The persist 
attribute doesn't even exist for hub devices.

  So hub doesn't need attribute avoid_reset_quirk. The patch is to take
  attribute avoid_reset_quirk out of usb device's attribute group and
  add or remove it in the usb_create/remove_sysfs_dev_files() if the device
  is not a usb hub.
 
 Why? What is gained doing so? Without further explanation about the need
 or benefit of doing so, why do you want to make hubs different from
 other devices?

They already are different.  The patch does not make the difference any 
bigger.

A hub that needs a firmware update after a reset probably is not worth 
supporting.

Alan Stern

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

Re: [PATCH 1/3] usb: Rename temp variable config to val in the set_avoid_reset_quirk()

[Alan Stern]

On Mon, 30 Jul 2012, Bjørn Mork wrote:

 Lan Tianyu tianyu@intel.com writes:
 
  -   if (sscanf(buf, %d, config) != 1 || config  0 || config  1)
  +   if (sscanf(buf, %d, val) != 1 || val  0 || val  1)
  return -EINVAL;
 
 Not directly related to this patch, but a question I started wondering
 about recently:  Is there some generic guideline wrt parsing boolean
 flags in sysfs?  If not, shouldn't there be?

Agreed; this area is ripe for kernel janitors.

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 3/3] usb: Change persist_enabled when attribute avoid_reset_quirk is modified

[Alan Stern]

On Mon, 30 Jul 2012, Oliver Neukum wrote:

 On Monday 30 July 2012 15:58:25 Lan Tianyu wrote:
  On 2012年07月30日 15:24, Oliver Neukum wrote:
 
   this is on second thought quite problematic. If user space has
   disabled the persist feature it must stay disabled, even if
   the quirk setting is removed.
  Yeah. You are right. So how about remain the persist_enabled 0 or
  do nothing with persist_enabled when quirk settting is removed.
 
 Hi,
 
 this leads to behavior that is not easy to predict or understand.
 It would be cleaner to leave the flag alone and check for the quirk
 in addition for the flag when the check is done.

I disagree.  Leaving the flag set but then not implementing the 
persist behavior would be confusing also.  Maybe even worse.

Alan Stern

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

[PATCH 7/7] drivers/usb/host/ehci-xilinx-of.c: use devm_ functions

[Julia Lawall]

From: Julia Lawall julia.law...@lip6.fr

The various devm_ functions allocate memory that is released when a driver
detaches.  This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.

Signed-off-by: Julia Lawall julia.law...@lip6.fr

---
Not compiled

 drivers/usb/host/ehci-xilinx-of.c |   20 +++-
 1 file changed, 3 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/host/ehci-xilinx-of.c 
b/drivers/usb/host/ehci-xilinx-of.c
index 39f24fa..6a3f921 100644
--- a/drivers/usb/host/ehci-xilinx-of.c
+++ b/drivers/usb/host/ehci-xilinx-of.c
@@ -152,12 +152,6 @@ static int __devinit ehci_hcd_xilinx_of_probe(struct 
platform_device *op)
hcd-rsrc_start = res.start;
hcd-rsrc_len = resource_size(res);
 
-   if (!request_mem_region(hcd-rsrc_start, hcd-rsrc_len, hcd_name)) {
-   printk(KERN_ERR %s: request_mem_region failed\n, __FILE__);
-   rv = -EBUSY;
-   goto err_rmr;
-   }
-
irq = irq_of_parse_and_map(dn, 0);
if (!irq) {
printk(KERN_ERR %s: irq_of_parse_and_map failed\n, __FILE__);
@@ -165,11 +159,11 @@ static int __devinit ehci_hcd_xilinx_of_probe(struct 
platform_device *op)
goto err_irq;
}
 
-   hcd-regs = ioremap(hcd-rsrc_start, hcd-rsrc_len);
+   hcd-regs = devm_request_and_ioremap(op-dev, res);
if (!hcd-regs) {
-   printk(KERN_ERR %s: ioremap failed\n, __FILE__);
+   pr_err(%s: devm_request_and_ioremap failed\n, __FILE__);
rv = -ENOMEM;
-   goto err_ioremap;
+   goto err_irq;
}
 
ehci = hcd_to_ehci(hcd);
@@ -200,12 +194,7 @@ static int __devinit ehci_hcd_xilinx_of_probe(struct 
platform_device *op)
if (rv == 0)
return 0;
 
-   iounmap(hcd-regs);
-
-err_ioremap:
 err_irq:
-   release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
-err_rmr:
usb_put_hcd(hcd);
 
return rv;
@@ -227,9 +216,6 @@ static int ehci_hcd_xilinx_of_remove(struct platform_device 
*op)
 
usb_remove_hcd(hcd);
 
-   iounmap(hcd-regs);
-   release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
-
usb_put_hcd(hcd);
 
return 0;

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

[PATCH 5/7] drivers/usb/host/ehci-tegra.c: use devm_ functions

[Julia Lawall]

From: Julia Lawall julia.law...@lip6.fr

The various devm_ functions allocate memory that is released when a driver
detaches.  This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.

Signed-off-by: Julia Lawall julia.law...@lip6.fr

---
Not compiled

 drivers/usb/host/ehci-tegra.c |   40 +---
 1 file changed, 13 insertions(+), 27 deletions(-)

diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 950e95e..ba5039f 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -634,7 +634,8 @@ static int tegra_ehci_probe(struct platform_device *pdev)
 
setup_vbus_gpio(pdev, pdata);
 
-   tegra = kzalloc(sizeof(struct tegra_ehci_hcd), GFP_KERNEL);
+   tegra = devm_kzalloc(pdev-dev, sizeof(struct tegra_ehci_hcd),
+GFP_KERNEL);
if (!tegra)
return -ENOMEM;
 
@@ -642,13 +643,12 @@ static int tegra_ehci_probe(struct platform_device *pdev)
dev_name(pdev-dev));
if (!hcd) {
dev_err(pdev-dev, Unable to create HCD\n);
-   err = -ENOMEM;
-   goto fail_hcd;
+   return -ENOMEM;
}
 
platform_set_drvdata(pdev, tegra);
 
-   tegra-clk = clk_get(pdev-dev, NULL);
+   tegra-clk = devm_clk_get(pdev-dev, NULL);
if (IS_ERR(tegra-clk)) {
dev_err(pdev-dev, Can't get ehci clock\n);
err = PTR_ERR(tegra-clk);
@@ -657,9 +657,9 @@ static int tegra_ehci_probe(struct platform_device *pdev)
 
err = clk_prepare_enable(tegra-clk);
if (err)
-   goto fail_clken;
+   goto fail_clk;
 
-   tegra-emc_clk = clk_get(pdev-dev, emc);
+   tegra-emc_clk = devm_clk_get(pdev-dev, emc);
if (IS_ERR(tegra-emc_clk)) {
dev_err(pdev-dev, Can't get emc clock\n);
err = PTR_ERR(tegra-emc_clk);
@@ -677,7 +677,7 @@ static int tegra_ehci_probe(struct platform_device *pdev)
}
hcd-rsrc_start = res-start;
hcd-rsrc_len = resource_size(res);
-   hcd-regs = ioremap(res-start, resource_size(res));
+   hcd-regs = devm_ioremap(pdev-dev, res-start, resource_size(res));
if (!hcd-regs) {
dev_err(pdev-dev, Failed to remap I/O memory\n);
err = -ENOMEM;
@@ -702,7 +702,7 @@ static int tegra_ehci_probe(struct platform_device *pdev)
default:
err = -ENODEV;
dev_err(pdev-dev, unknown usb instance\n);
-   goto fail_phy;
+   goto fail_io;
}
}
 
@@ -712,7 +712,7 @@ static int tegra_ehci_probe(struct platform_device *pdev)
if (IS_ERR(tegra-phy)) {
dev_err(pdev-dev, Failed to open USB phy\n);
err = -ENXIO;
-   goto fail_phy;
+   goto fail_io;
}
 
err = tegra_usb_phy_power_on(tegra-phy);
@@ -733,7 +733,8 @@ static int tegra_ehci_probe(struct platform_device *pdev)
 
 #ifdef CONFIG_USB_OTG_UTILS
if (pdata-operating_mode == TEGRA_USB_OTG) {
-   tegra-transceiver = usb_get_phy(USB_PHY_TYPE_USB2);
+   tegra-transceiver =
+   devm_usb_get_phy(pdev-dev, USB_PHY_TYPE_USB2);
if (!IS_ERR_OR_NULL(tegra-transceiver))
otg_set_host(tegra-transceiver-otg, hcd-self);
}
@@ -757,25 +758,16 @@ static int tegra_ehci_probe(struct platform_device *pdev)
 
 fail:
 #ifdef CONFIG_USB_OTG_UTILS
-   if (!IS_ERR_OR_NULL(tegra-transceiver)) {
+   if (!IS_ERR_OR_NULL(tegra-transceiver))
otg_set_host(tegra-transceiver-otg, NULL);
-   usb_put_phy(tegra-transceiver);
-   }
 #endif
tegra_usb_phy_close(tegra-phy);
-fail_phy:
-   iounmap(hcd-regs);
 fail_io:
clk_disable_unprepare(tegra-emc_clk);
-   clk_put(tegra-emc_clk);
 fail_emc_clk:
clk_disable_unprepare(tegra-clk);
-fail_clken:
-   clk_put(tegra-clk);
 fail_clk:
usb_put_hcd(hcd);
-fail_hcd:
-   kfree(tegra);
return err;
 }
 
@@ -792,25 +784,19 @@ static int tegra_ehci_remove(struct platform_device *pdev)
pm_runtime_put_noidle(pdev-dev);
 
 #ifdef CONFIG_USB_OTG_UTILS
-   if (!IS_ERR_OR_NULL(tegra-transceiver)) {
+   if (!IS_ERR_OR_NULL(tegra-transceiver))
otg_set_host(tegra-transceiver-otg, NULL);
-   usb_put_phy(tegra-transceiver);
-   }
 #endif
 
usb_remove_hcd(hcd);
usb_put_hcd(hcd);
 
tegra_usb_phy_close(tegra-phy);
-   iounmap(hcd-regs);
 
clk_disable_unprepare(tegra-clk);
-   clk_put(tegra-clk);
 
clk_disable_unprepare(tegra-emc_clk);
-   clk_put(tegra-emc_clk);
 
-   kfree(tegra);
return 0;
 }
 

--
To 

[PATCH 1/7] drivers/usb/host/ehci-ppc-of.c: use devm_ functions

[Julia Lawall]

From: Julia Lawall julia.law...@lip6.fr

The various devm_ functions allocate memory that is released when a driver
detaches.  This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.

Signed-off-by: Julia Lawall julia.law...@lip6.fr

---
Not compiled

 drivers/usb/host/ehci-ppc-of.c |   28 +++-
 1 file changed, 7 insertions(+), 21 deletions(-)

diff --git a/drivers/usb/host/ehci-ppc-of.c b/drivers/usb/host/ehci-ppc-of.c
index bbbe89d..fa937d0 100644
--- a/drivers/usb/host/ehci-ppc-of.c
+++ b/drivers/usb/host/ehci-ppc-of.c
@@ -114,12 +114,6 @@ static int __devinit ehci_hcd_ppc_of_probe(struct 
platform_device *op)
hcd-rsrc_start = res.start;
hcd-rsrc_len = resource_size(res);
 
-   if (!request_mem_region(hcd-rsrc_start, hcd-rsrc_len, hcd_name)) {
-   printk(KERN_ERR %s: request_mem_region failed\n, __FILE__);
-   rv = -EBUSY;
-   goto err_rmr;
-   }
-
irq = irq_of_parse_and_map(dn, 0);
if (irq == NO_IRQ) {
printk(KERN_ERR %s: irq_of_parse_and_map failed\n, __FILE__);
@@ -127,9 +121,9 @@ static int __devinit ehci_hcd_ppc_of_probe(struct 
platform_device *op)
goto err_irq;
}
 
-   hcd-regs = ioremap(hcd-rsrc_start, hcd-rsrc_len);
+   hcd-regs = devm_request_and_ioremap(op-dev, res);
if (!hcd-regs) {
-   printk(KERN_ERR %s: ioremap failed\n, __FILE__);
+   pr_err(%s: devm_request_and_ioremap failed\n, __FILE__);
rv = -ENOMEM;
goto err_ioremap;
}
@@ -139,8 +133,10 @@ static int __devinit ehci_hcd_ppc_of_probe(struct 
platform_device *op)
if (np != NULL) {
/* claim we really affected by usb23 erratum */
if (!of_address_to_resource(np, 0, res))
-   ehci-ohci_hcctrl_reg = ioremap(res.start +
-   OHCI_HCCTRL_OFFSET, OHCI_HCCTRL_LEN);
+   ehci-ohci_hcctrl_reg =
+   devm_ioremap(op-dev,
+res.start + OHCI_HCCTRL_OFFSET,
+OHCI_HCCTRL_LEN);
else
pr_debug(%s: no ohci offset in fdt\n, __FILE__);
if (!ehci-ohci_hcctrl_reg) {
@@ -169,19 +165,13 @@ static int __devinit ehci_hcd_ppc_of_probe(struct 
platform_device *op)
 
rv = usb_add_hcd(hcd, irq, 0);
if (rv)
-   goto err_ehci;
+   goto err_ioremap;
 
return 0;
 
-err_ehci:
-   if (ehci-has_amcc_usb23)
-   iounmap(ehci-ohci_hcctrl_reg);
-   iounmap(hcd-regs);
 err_ioremap:
irq_dispose_mapping(irq);
 err_irq:
-   release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
-err_rmr:
usb_put_hcd(hcd);
 
return rv;
@@ -202,9 +192,7 @@ static int ehci_hcd_ppc_of_remove(struct platform_device 
*op)
 
usb_remove_hcd(hcd);
 
-   iounmap(hcd-regs);
irq_dispose_mapping(hcd-irq);
-   release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
 
/* use request_mem_region to test if the ohci driver is loaded.  if so
 * ensure the ohci core is operational.
@@ -222,8 +210,6 @@ static int ehci_hcd_ppc_of_remove(struct platform_device 
*op)
pr_debug(%s: no ohci offset in fdt\n, 
__FILE__);
of_node_put(np);
}
-
-   iounmap(ehci-ohci_hcctrl_reg);
}
usb_put_hcd(hcd);
 

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

[PATCH 2/7] drivers/usb/host/ehci-s5p.c: use devm_ functions

[Julia Lawall]

From: Julia Lawall julia.law...@lip6.fr

The various devm_ functions allocate memory that is released when a driver
detaches.  This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.

Signed-off-by: Julia Lawall julia.law...@lip6.fr

---
Not compiled

 drivers/usb/host/ehci-s5p.c |7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 9d8f1dd..d055503 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -128,7 +128,7 @@ static int __devinit s5p_ehci_probe(struct platform_device 
*pdev)
}
 
s5p_ehci-hcd = hcd;
-   s5p_ehci-clk = clk_get(pdev-dev, usbhost);
+   s5p_ehci-clk = devm_clk_get(pdev-dev, usbhost);
 
if (IS_ERR(s5p_ehci-clk)) {
dev_err(pdev-dev, Failed to get usbhost clock\n);
@@ -138,7 +138,7 @@ static int __devinit s5p_ehci_probe(struct platform_device 
*pdev)
 
err = clk_enable(s5p_ehci-clk);
if (err)
-   goto fail_clken;
+   goto fail_clk;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
@@ -184,8 +184,6 @@ static int __devinit s5p_ehci_probe(struct platform_device 
*pdev)
 
 fail_io:
clk_disable(s5p_ehci-clk);
-fail_clken:
-   clk_put(s5p_ehci-clk);
 fail_clk:
usb_put_hcd(hcd);
return err;
@@ -203,7 +201,6 @@ static int __devexit s5p_ehci_remove(struct platform_device 
*pdev)
pdata-phy_exit(pdev, S5P_USB_PHY_HOST);
 
clk_disable(s5p_ehci-clk);
-   clk_put(s5p_ehci-clk);
 
usb_put_hcd(hcd);
 

--
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 3/7] drivers/usb/host/ehci-sead3.c: use devm_ functions

[Julia Lawall]

From: Julia Lawall julia.law...@lip6.fr

The various devm_ functions allocate memory that is released when a driver
detaches.  This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.

Signed-off-by: Julia Lawall julia.law...@lip6.fr

---
Not compiled

 drivers/usb/host/ehci-sead3.c |   15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/host/ehci-sead3.c b/drivers/usb/host/ehci-sead3.c
index 58c96bd..802dad8 100644
--- a/drivers/usb/host/ehci-sead3.c
+++ b/drivers/usb/host/ehci-sead3.c
@@ -112,17 +112,11 @@ static int ehci_hcd_sead3_drv_probe(struct 
platform_device *pdev)
hcd-rsrc_start = res-start;
hcd-rsrc_len = resource_size(res);
 
-   if (!request_mem_region(hcd-rsrc_start, hcd-rsrc_len, hcd_name)) {
-   pr_debug(request_mem_region failed);
-   ret = -EBUSY;
-   goto err1;
-   }
-
-   hcd-regs = ioremap(hcd-rsrc_start, hcd-rsrc_len);
+   hcd-regs = devm_request_and_ioremap(pdev-dev, res);
if (!hcd-regs) {
pr_debug(ioremap failed);
ret = -ENOMEM;
-   goto err2;
+   goto err1;
}
 
/* Root hub has integrated TT. */
@@ -135,9 +129,6 @@ static int ehci_hcd_sead3_drv_probe(struct platform_device 
*pdev)
return ret;
}
 
-   iounmap(hcd-regs);
-err2:
-   release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
 err1:
usb_put_hcd(hcd);
return ret;
@@ -148,8 +139,6 @@ static int ehci_hcd_sead3_drv_remove(struct platform_device 
*pdev)
struct usb_hcd *hcd = platform_get_drvdata(pdev);
 
usb_remove_hcd(hcd);
-   iounmap(hcd-regs);
-   release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
usb_put_hcd(hcd);
platform_set_drvdata(pdev, NULL);
 

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

[PATCH 4/7] drivers/usb/host/ehci-sh.c: use devm_ functions

[Julia Lawall]

From: Julia Lawall julia.law...@lip6.fr

The various devm_ functions allocate memory that is released when a driver
detaches.  This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.

Signed-off-by: Julia Lawall julia.law...@lip6.fr

---
Not compiled

 drivers/usb/host/ehci-sh.c |   35 +++
 1 file changed, 7 insertions(+), 28 deletions(-)

diff --git a/drivers/usb/host/ehci-sh.c b/drivers/usb/host/ehci-sh.c
index b3f1e36..6081e1e 100644
--- a/drivers/usb/host/ehci-sh.c
+++ b/drivers/usb/host/ehci-sh.c
@@ -125,33 +125,27 @@ static int ehci_hcd_sh_probe(struct platform_device *pdev)
hcd-rsrc_start = res-start;
hcd-rsrc_len = resource_size(res);
 
-   if (!request_mem_region(hcd-rsrc_start, hcd-rsrc_len,
-   driver-description)) {
-   dev_dbg(pdev-dev, controller already in use\n);
-   ret = -EBUSY;
-   goto fail_request_resource;
-   }
-
-   hcd-regs = ioremap_nocache(hcd-rsrc_start, hcd-rsrc_len);
+   hcd-regs = devm_request_and_ioremap(pdev-dev, res);
if (hcd-regs == NULL) {
dev_dbg(pdev-dev, error mapping memory\n);
ret = -ENXIO;
-   goto fail_ioremap;
+   goto fail_request_resource;
}
 
-   priv = kmalloc(sizeof(struct ehci_sh_priv), GFP_KERNEL);
+   priv = devm_kzalloc(pdev-dev, sizeof(struct ehci_sh_priv),
+   GFP_KERNEL);
if (!priv) {
dev_dbg(pdev-dev, error allocating priv data\n);
ret = -ENOMEM;
-   goto fail_alloc;
+   goto fail_request_resource;
}
 
/* These are optional, we don't care if they fail */
-   priv-fclk = clk_get(pdev-dev, usb_fck);
+   priv-fclk = devm_clk_get(pdev-dev, usb_fck);
if (IS_ERR(priv-fclk))
priv-fclk = NULL;
 
-   priv-iclk = clk_get(pdev-dev, usb_ick);
+   priv-iclk = devm_clk_get(pdev-dev, usb_ick);
if (IS_ERR(priv-iclk))
priv-iclk = NULL;
 
@@ -176,14 +170,6 @@ fail_add_hcd:
clk_disable(priv-iclk);
clk_disable(priv-fclk);
 
-   clk_put(priv-iclk);
-   clk_put(priv-fclk);
-
-   kfree(priv);
-fail_alloc:
-   iounmap(hcd-regs);
-fail_ioremap:
-   release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
 fail_request_resource:
usb_put_hcd(hcd);
 fail_create_hcd:
@@ -198,19 +184,12 @@ static int __exit ehci_hcd_sh_remove(struct 
platform_device *pdev)
struct usb_hcd *hcd = priv-hcd;
 
usb_remove_hcd(hcd);
-   iounmap(hcd-regs);
-   release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
usb_put_hcd(hcd);
platform_set_drvdata(pdev, NULL);
 
clk_disable(priv-fclk);
clk_disable(priv-iclk);
 
-   clk_put(priv-fclk);
-   clk_put(priv-iclk);
-
-   kfree(priv);
-
return 0;
 }
 

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

[PATCH 6/7] drivers/usb/host/ehci-vt8500.c: use devm_ functions

[Julia Lawall]

From: Julia Lawall julia.law...@lip6.fr

The various devm_ functions allocate memory that is released when a driver
detaches.  This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.

Signed-off-by: Julia Lawall julia.law...@lip6.fr

---
Not compiled

 drivers/usb/host/ehci-vt8500.c |   15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/host/ehci-vt8500.c b/drivers/usb/host/ehci-vt8500.c
index 4d147c4..a891617 100644
--- a/drivers/usb/host/ehci-vt8500.c
+++ b/drivers/usb/host/ehci-vt8500.c
@@ -106,17 +106,11 @@ static int vt8500_ehci_drv_probe(struct platform_device 
*pdev)
hcd-rsrc_start = res-start;
hcd-rsrc_len = resource_size(res);
 
-   if (!request_mem_region(hcd-rsrc_start, hcd-rsrc_len, hcd_name)) {
-   pr_debug(request_mem_region failed);
-   ret = -EBUSY;
-   goto err1;
-   }
-
-   hcd-regs = ioremap(hcd-rsrc_start, hcd-rsrc_len);
+   hcd-regs = devm_request_and_ioremap(pdev-dev, res);
if (!hcd-regs) {
pr_debug(ioremap failed);
ret = -ENOMEM;
-   goto err2;
+   goto err1;
}
 
ehci = hcd_to_ehci(hcd);
@@ -129,9 +123,6 @@ static int vt8500_ehci_drv_probe(struct platform_device 
*pdev)
return ret;
}
 
-   iounmap(hcd-regs);
-err2:
-   release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
 err1:
usb_put_hcd(hcd);
return ret;
@@ -142,8 +133,6 @@ static int vt8500_ehci_drv_remove(struct platform_device 
*pdev)
struct usb_hcd *hcd = platform_get_drvdata(pdev);
 
usb_remove_hcd(hcd);
-   iounmap(hcd-regs);
-   release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
usb_put_hcd(hcd);
platform_set_drvdata(pdev, NULL);
 

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

[PATCH] USB: echi-dbgp: increase the controller wait time to come out of halt.

[Colin Ian King]

The default 10 microsecond delay for the controller to come out of
halt in dbgp_ehci_startup is too short, so increase it to 1 millisecond.

This is based on emperical testing on various USB debug ports on
modern machines such as a Lenovo X220i and an Ivybridge development
platform that needed to wait ~450-950 microseconds.

Signed-off-by: Colin Ian King colin.k...@canonical.com
---
 drivers/usb/early/ehci-dbgp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/early/ehci-dbgp.c b/drivers/usb/early/ehci-dbgp.c
index ee0ebac..89dcf15 100644
--- a/drivers/usb/early/ehci-dbgp.c
+++ b/drivers/usb/early/ehci-dbgp.c
@@ -450,7 +450,7 @@ static int dbgp_ehci_startup(void)
writel(FLAG_CF, ehci_regs-configured_flag);
 
/* Wait until the controller is no longer halted */
-   loop = 10;
+   loop = 1000;
do {
status = readl(ehci_regs-status);
if (!(status  STS_HALT))
-- 
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 3/3] usb: Change persist_enabled when attribute avoid_reset_quirk is modified

[Alan Stern]

On Mon, 30 Jul 2012, Oliver Neukum wrote:

 On Monday 30 July 2012 10:39:50 Alan Stern wrote:
   this leads to behavior that is not easy to predict or understand.
   It would be cleaner to leave the flag alone and check for the quirk
   in addition for the flag when the check is done.
  
  I disagree.  Leaving the flag set but then not implementing the 
  persist behavior would be confusing also.  Maybe even worse.
 
 But we cannot guarantee persistance anyway. We can only try.
 But trying makes no sense if we are sure to fail.
 
 In addition, we even undermine the file permission to a small
 extent if we allow one attribute to alter another attribute.

Putting all these thoughts together leads to a single conclusion:

We should not change persist_enabled when avoid_reset_quirk
gets set.

As you say, coupling the two attributes is confusing and circumvents
the permissions.  If the device needs a reset-resume, we'll go ahead
and try to do it.  If the reset fails because the firmware gets erased,
at least there will be an error message in the system log to explain
what went wrong.  (But it's still a good idea to add a sentence about
this issue to the Documentation file.)

Whereas if we silently change attribute values or silently skip a 
reset-resume when RESET_MORPHS is set, there will be no indication in 
the log or anywhere else to tell the user what happened.

Besides, as far as I can tell the RESET_MORPHS quirk is used in only 
one place (in usb-storage).  We don't even have any existing quirk 
entries that set this flag!

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 3/3] usb: Change persist_enabled when attribute avoid_reset_quirk is modified

[Oliver Neukum]

On Monday 30 July 2012 11:16:12 Alan Stern wrote:
 As you say, coupling the two attributes is confusing and circumvents
 the permissions.  If the device needs a reset-resume, we'll go ahead
 and try to do it.  If the reset fails because the firmware gets erased,
 at least there will be an error message in the system log to explain
 what went wrong.  (But it's still a good idea to add a sentence about
 this issue to the Documentation file.)
 
 Whereas if we silently change attribute values or silently skip a 
 reset-resume when RESET_MORPHS is set, there will be no indication in 
 the log or anywhere else to tell the user what happened.

That makes sense.

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 00/12] chipidea/imx: add otg support and some bug fix

[Greg KH]

On Mon, Jul 30, 2012 at 05:17:58PM +0800, Richard Zhao wrote:
 On Thu, Jul 26, 2012 at 06:59:48PM +0800, Richard Zhao wrote:
  On Thu, Jul 19, 2012 at 10:05:54AM +0800, Richard Zhao wrote:
   On Mon, Jul 16, 2012 at 05:40:57PM -0700, Greg KH wrote:
On Thu, Jul 12, 2012 at 03:01:40PM +0800, Richard Zhao wrote:
 The patch set is tested on imx6q_sabrelite board.
 
 The patch can also be found at
 https://github.com/riczhao/kernel-imx/commits/topics/usb-driver
 
 For test which merged platform patches:
 https://github.com/riczhao/kernel-imx/commits/topics/usb-test
 
 It's better apply after patch I sent out:
 usb: chipidea: cleanup dma_pool if udc_start() fails

I need acks from Alexander before I can accept any of these.
   ping Alexander ...
  ping Alexander again ...
 Hi Greg,
 
 Is there a better way but keeping waiting?

It's the middle of the merge window, even if Alexander shows up right
now, I can't do anything with these patches until 3.6-rc1 is out.

So be patient, this is vacation time for lots of people.

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

[PATCH RESEND] [RFC] usb:gadget: Refcount for gadget pullup

[Lukasz Majewski]

This commit fixes the way gadget's pullup method (wrapped at
usb_gadget_connect/disconnect) is called in the udc-core.

The composite driver allows correct driver registration, even when it calls
the usb_gadget_disconnect method (composite driver configuration is defered 
for user space - please look into the description of usb_composite_probe at
composite.c - line: 1623)

One such example is the CCG (Configurable Composite Gadget) driver (at
drivers/staging/ccg), which after its registration has no usb descriptor
(i.e. idProduct, idVendor etc.) and functions registered. Those are configured
after writing to /sys/module/g_ccg/parameters/ or /sys/class/ccg_usb/ccg0/.

Unfortunately, the code at 'usb_gadget_probe_driver' method (some code omitted):

if (udc_is_newstyle(udc)) {
bind(udc-gadget);
usb_gadget_udc_start(udc-gadget, driver);
usb_gadget_connect(udc-gadget);
}

Explicitly calls the usb_gadget_connect method for this driver. It looks like
the udc-core enables pullup for a driver, which has no functions and no
descriptor filled (those values are feed from userspace).

The USB composite driver API allows correct driver registration with calling 
usb_gadget_disconnect method, but as it is now, _ALL_ newstyle usb gadgets are
connected by default. Therefore it violates the composite API.

The solution (at least until the udc-core is reworked) is to add atomic
variable, which helps in balancing the number of called usb_gadget_connect/
disconnect functions.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/usb/gadget/udc-core.c |   17 -
 include/linux/usb/gadget.h|   13 +++--
 2 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/udc-core.c b/drivers/usb/gadget/udc-core.c
index e5e44f8..a26517e 100644
--- a/drivers/usb/gadget/udc-core.c
+++ b/drivers/usb/gadget/udc-core.c
@@ -349,7 +349,22 @@ found:
}
usb_gadget_connect(udc-gadget);
} else {
-
+   /*
+* This is a hack for old style gadgets:
+*
+* The udc_start for old style gadgets performs implicitly all
+* operations done by usb_gadget_connect(but not calling it).
+* Therefore non composite gadgets (like rndis) works even with
+* wrong connect_count value (old style gadgets don't call
+* usb_gadget_connect/disconnect).
+*
+* On the other hand the CCG (Configurable Composite Gadget)
+* requires this incrementation since it calls
+* usb_gadget_disconnect on its probe (it is allowed) and hence
+* the proper balance is needed when the usb_gadget_connect(i.e.
+* pullup) is called, when triggered from userspace event.
+*/
+   atomic_inc(udc-gadget-connect_count);
ret = usb_gadget_start(udc-gadget, driver, bind);
if (ret)
goto err1;
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 9517466..0801d83 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -534,6 +534,7 @@ struct usb_gadget {
unsignedb_hnp_enable:1;
unsigneda_hnp_support:1;
unsigneda_alt_hnp_support:1;
+   atomic_tconnect_count;
const char  *name;
struct device   dev;
 };
@@ -739,7 +740,11 @@ static inline int usb_gadget_connect(struct usb_gadget 
*gadget)
 {
if (!gadget-ops-pullup)
return -EOPNOTSUPP;
-   return gadget-ops-pullup(gadget, 1);
+
+   if (atomic_inc_return(gadget-connect_count) == 1)
+   return gadget-ops-pullup(gadget, 1);
+
+   return 0;
 }
 
 /**
@@ -761,7 +766,11 @@ static inline int usb_gadget_disconnect(struct usb_gadget 
*gadget)
 {
if (!gadget-ops-pullup)
return -EOPNOTSUPP;
-   return gadget-ops-pullup(gadget, 0);
+
+   if (atomic_dec_and_test(gadget-connect_count))
+   return gadget-ops-pullup(gadget, 0);
+
+   return 0;
 }
 
 
-- 
1.7.2.3

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

Re: [PATCH 1/3] usb: Rename temp variable config to val in the set_avoid_reset_quirk()

[Greg KH]

On Mon, Jul 30, 2012 at 10:33:27AM +0200, Bjørn Mork wrote:
 Lan Tianyu tianyu@intel.com writes:
 
  -   if (sscanf(buf, %d, config) != 1 || config  0 || config  1)
  +   if (sscanf(buf, %d, val) != 1 || val  0 || val  1)
  return -EINVAL;
 
 Not directly related to this patch, but a question I started wondering
 about recently:  Is there some generic guideline wrt parsing boolean
 flags in sysfs?  If not, shouldn't there be?
 
 I see a lot of different approaches implementing this basic function.
 Personally I would prefer if they all did something like the 
 set_usb2_hardware_lpm in drivers/usb/core/sysfs.c:
 
 static ssize_t
 set_usb2_hardware_lpm(struct device *dev, struct device_attribute *attr,
 const char *buf, size_t count)
 {
 struct usb_device *udev = to_usb_device(dev);
 bool value;
 int ret;
 
 usb_lock_device(udev);
 
 ret = strtobool(buf, value);
 
 if (!ret)
 ret = usb_set_usb2_hardware_lpm(udev, value);
 
 usb_unlock_device(udev);
 
 if (!ret)
 return count;
 
 return ret;
 }
 
 
 
 Using strtobool() to allow Y, yes, 1 etc makes a nice user
 interface IMHO.  Unless of course the variable is a true integer which
 only happens to currently allow 0 and 1, but may be extended with more
 values later.

Yes, using that function should be encouraged.

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]staging: usbip: Fix typos.

[Sergei Shtylyov]

Hello.

On 07/30/2012 06:23 PM, Justin P. Mattock wrote:

 From: Justin P. Mattock justinmatt...@gmail.com

 Signed-off-by: Justin P. Mattock justinmatt...@gmail.com

 ---

 The below patch fixes typos found while reading through staging: usbip

   Unfortunately, it introduces some new instead. :-)

 diff --git a/drivers/staging/usbip/vhci_hcd.c 
 b/drivers/staging/usbip/vhci_hcd.c
 index 12a9a5f..dd15dc0 100644
 --- a/drivers/staging/usbip/vhci_hcd.c
 +++ b/drivers/staging/usbip/vhci_hcd.c
 @@ -828,11 +828,11 @@ static void vhci_shutdown_connection(struct 
 usbip_device *ud)
*  disable endpoints. pending urbs are unlinked(dequeued).
*
* NOTE: After calling rh_port_disconnect(), the USB device drivers of a
 -  * deteched device should release used urbs in a cleanup function(i.e.
 +  * detached device should release used urbs in a cleanup function(i.e.

   Space is needed before (i.e..

* xxx_disconnect()). Therefore, vhci_hcd does not need to release
* pushed urbs and their private data in this function.
*
 -  * NOTE: vhci_dequeue() must be considered carefully. When shutdowning
 +  * NOTE: vhci_dequeue() must be considered carefully. When shuting down

   Shutting.

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 v2] USB: ohci-pxa27x: add DT bindings

[Daniel Mack]

On 30.07.2012 19:05, Greg KH wrote:
 On Mon, Jul 30, 2012 at 09:29:12AM +0200, Daniel Mack wrote:
 Add DT bindings to the ohci-pxa27x driver and some documentation.

 Successfully tested on a PXA3xx board.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
 Changes from v1:
  - renamed mrvl to marvell

 Greg, I think that would best go through your usb tree. Is that ok?
 
 Ok, but it will have to wait until after 3.6-rc1 is out.

Sure, no hurries at all. The rest of the releated patches won't make it
to mainline before 3.7 anyway.


Thanks,
Daniel
--
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: musb: drop useless board_mode usage

[Sergei Shtylyov]

Hello.

On 11/24/2011 09:59 PM, Sergei Shtylyov wrote:

 we are compiling the driver always with full OTG
 capabilities, so that board_mode trick becomes
 useless.

 Signed-off-by: Felipe Balbiba...@ti.com
 ---

 I would like to get Acks from blackfin, da8xx and davinci guys, please.

After having looked thru the patch, I have a few questions...

   I still haven't got the replies on my questions. Felipe, looks like you've
forgotten about this quite important patch?.. :-(

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 2/3] usb: Take attribute avoid_reset_quirk out of usb device's attribute group

[Sarah Sharp]

On Mon, Jul 30, 2012 at 09:28:36AM +0200, Oliver Neukum wrote:
 On Monday 30 July 2012 11:34:10 Lan Tianyu wrote:
  The hub is always supposed to support reset and its persist is enabled.
 
 By default, not necessarily always. User space may disable it.
 
  So hub doesn't need attribute avoid_reset_quirk. The patch is to take
  attribute avoid_reset_quirk out of usb device's attribute group and
  add or remove it in the usb_create/remove_sysfs_dev_files() if the device
  is not a usb hub.
 
 Why? What is gained doing so? Without further explanation about the need
 or benefit of doing so, why do you want to make hubs different from
 other devices?

Along those lines, Tianyu, can you share what your master plan for
implementing the automatic powering off of ports?  I think it would help
to understand the bigger picture when looking at small patches like
these.

So far, the discussion on the mailing list seems to boil down to:

Issues
--

 - We need to issue a reset resume for all suspended devices that have
   been powered off.

 - We can't power off ports with connected devices that require firmware
   (e.g. bluetooth and 3G modems).  The firmware would be lost when
   they're reset.

 - Some devices may morph into a different USB device on reset, so we
   need to avoid powering the port down when those devices are attached.
   Drivers for those devices will have the USB_QUIRK_RESET_MORPHS set.

 - I'm not sure if it's true that all devices that need firmware will
   have USB_QUIRK_RESET_MORPHS set.  Alan, Oliver?

 - Many drivers may turn on remote wakeup when a device is suspended,
   but userspace may not need the wakeup.  An example would be if the
   user clicked Disable bluetooth from ConnMan.  It obviously wouldn't
   care about remote wakeups from the bluetooth device.

Possible solutions
--

 - We need a new interface driver flag to indicate a driver is fine with
   the port being powered off.  Something like supports_power_off.

 - In addition to the port power sysfs values of on or off, we also
   need an auto value that attempts to apply a smart in-kernel policy
   to when to power off the port.  That policy might look like:

   1. If the device is internal and unpluggable, power off the port

   2. If the device is internal and suspended, power off the port if all
  the following are true:

  a) all interface drivers have supports_power_off set, or no
 interface drivers are bound and usbfs has not claimed the
 device.
  b) remote wakeup is disabled
  c) USB_QUIRK_RESET_MORPHS is not set

 - If userspace wants a port to be powered off, and one of the interface
   drivers doesn't set supports_power_off or the driver enables remote
   wakeup, then userspace will need to unbind or unload the driver.


So far, the discussion has been mainly focused on figuring out a smart
policy for internal USB ports.  However, I'd like to see the auto
in-kernel policy extended to external USB ports.  Perhaps we need to
expose the ACPI internal/external port and connectable/unconnectable
values through sysfs, and apply the policy to both internal and external
devices?

Then userspace could look at whether a port is internal or external, and
decide when it makes sense to auto-power-off the port.  It could decide
to set an auto policy on all ports when the screen blanks.  When the
user starts interacting with the system and the screen turns back on,
userspace could change the policy back to on for external ports and
internal connectable ports.

Then policy #1 would just change to If the device is disconnected,
power off the port and policy #2 would apply to both internal and
external suspended ports.

Thoughts?

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: [PATCH 2/3] usb: Take attribute avoid_reset_quirk out of usb device's attribute group

[Bjørn Mork]

Sarah Sharp sarah.a.sh...@linux.intel.com writes:
 On Mon, Jul 30, 2012 at 09:28:36AM +0200, Oliver Neukum wrote:
 On Monday 30 July 2012 11:34:10 Lan Tianyu wrote:
  The hub is always supposed to support reset and its persist is enabled.
 
 By default, not necessarily always. User space may disable it.
 
  So hub doesn't need attribute avoid_reset_quirk. The patch is to take
  attribute avoid_reset_quirk out of usb device's attribute group and
  add or remove it in the usb_create/remove_sysfs_dev_files() if the device
  is not a usb hub.
 
 Why? What is gained doing so? Without further explanation about the need
 or benefit of doing so, why do you want to make hubs different from
 other devices?

 Along those lines, Tianyu, can you share what your master plan for
 implementing the automatic powering off of ports?  I think it would help
 to understand the bigger picture when looking at small patches like
 these.

 So far, the discussion on the mailing list seems to boil down to:

 Issues
 --

  - We need to issue a reset resume for all suspended devices that have
been powered off.

  - We can't power off ports with connected devices that require firmware
(e.g. bluetooth and 3G modems).  The firmware would be lost when
they're reset.

I don't think that is limited to devices needing firmware.  Even modems
with persistent firmware will keep lots of internal state which the
driver cannot re-establish.  And even if you could reset the device
state, the mobile network kept some state which also was lost when you
powered off the modem.

I really think this poweroff-on-suspend thought is a bit simplistic. It
may work for some simple devices, but there are certainly a number of
devices where suspend cannot be replaced by poweroff.

  - Many drivers may turn on remote wakeup when a device is suspended,
but userspace may not need the wakeup.  An example would be if the
user clicked Disable bluetooth from ConnMan.  It obviously wouldn't
care about remote wakeups from the bluetooth device.

This I did not understand.  Do you have some way to override the drivers
decision to enable remote wakeup?  Based on what?  Do you want to power
off a device where the driver requested remote wakeup?

I fail to see how that is going to work.  You need to cooperate with the
driver.

 Possible solutions
 --

  - We need a new interface driver flag to indicate a driver is fine with
the port being powered off.  Something like supports_power_off.

May work for some devices.  But what are the use cases? Which devices
will work better with such driver support than they will if you simply
unload the driver?

  - In addition to the port power sysfs values of on or off, we also
need an auto value that attempts to apply a smart in-kernel policy
to when to power off the port.  That policy might look like:

1. If the device is internal and unpluggable, power off the port

How do you detect the unpluggable?  Did you consider rfkill switches
plugging and unplugging internal devices?

2. If the device is internal and suspended, power off the port if all
   the following are true:

   a) all interface drivers have supports_power_off set, or no
interface drivers are bound and usbfs has not claimed the
device.
   b) remote wakeup is disabled
   c) USB_QUIRK_RESET_MORPHS is not set

Why can't that be a userspace decision?  I.e. drop all this policy in
the kernel stuff, and just implement:

  - If userspace wants a port to be powered off, and one of the interface
drivers doesn't set supports_power_off or the driver enables remote
wakeup, then userspace will need to unbind or unload the driver.


 So far, the discussion has been mainly focused on figuring out a smart
 policy for internal USB ports.  However, I'd like to see the auto
 in-kernel policy extended to external USB ports.  Perhaps we need to
 expose the ACPI internal/external port and connectable/unconnectable
 values through sysfs, and apply the policy to both internal and external
 devices?

 Then userspace could look at whether a port is internal or external, and
 decide when it makes sense to auto-power-off the port.  It could decide
 to set an auto policy on all ports when the screen blanks.  When the
 user starts interacting with the system and the screen turns back on,
 userspace could change the policy back to on for external ports and
 internal connectable ports.

Yes, this is the way to go IMHO. 

BTW, what if the interaction started with a USB keyboard being plugged
in?  No problem for you - that was the userspace daemon bad coice of
policy :-)

 Then policy #1 would just change to If the device is disconnected,
 power off the port and policy #2 would apply to both internal and
 external suspended ports.

 Thoughts?

I really think the kernel should limit itself to providing the basic
functionality (driver support flag and port power switch), and leave any
policy decisions for 

Re: [PATCH 2/3] usb: Take attribute avoid_reset_quirk out of usb device's attribute group

[Oliver Neukum]

On Monday 30 July 2012 22:35:37 Bjørn Mork wrote:
 Sarah Sharp sarah.a.sh...@linux.intel.com writes:
  On Mon, Jul 30, 2012 at 09:28:36AM +0200, Oliver Neukum wrote:

   - We need to issue a reset resume for all suspended devices that have
 been powered off.
 
   - We can't power off ports with connected devices that require firmware
 (e.g. bluetooth and 3G modems).  The firmware would be lost when
 they're reset.
 
 I don't think that is limited to devices needing firmware.  Even modems
 with persistent firmware will keep lots of internal state which the
 driver cannot re-establish.  And even if you could reset the device
 state, the mobile network kept some state which also was lost when you
 powered off the modem.

Sure. Maybe a per driver flag is insufficient and we need an extra attribute
like remote_wakeup.

  Possible solutions
  --
 
   - We need a new interface driver flag to indicate a driver is fine with
 the port being powered off.  Something like supports_power_off.
 
 May work for some devices.  But what are the use cases? Which devices
 will work better with such driver support than they will if you simply
 unload the driver?

uvc, some hid, some storage devices.

 2. If the device is internal and suspended, power off the port if all
the following are true:
 
a) all interface drivers have supports_power_off set, or no
   interface drivers are bound and usbfs has not claimed the
   device.
b) remote wakeup is disabled
c) USB_QUIRK_RESET_MORPHS is not set
 
 Why can't that be a userspace decision?  I.e. drop all this policy in
 the kernel stuff, and just implement:

We cannot. User space doesn't know and cannot know when remote wakeup
is needed.

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: usb scheduler

[Alan Stern]

On Mon, 30 Jul 2012, Alexey Filin wrote:

  Yes, something like it might work, I think.  But you probably wouldn't
  want to use URBs for this; they have too much overhead.  You'd need a
  more direct interface to the host controller driver.
 
 really, too much, about 7 us on my pc (Core2 Duo CPU  E7500  2.93GHz)
 a direct access to EHCI controller should be used
 
 
  The EHCI spec doesn't put any strict time limit on how long the host
  controller can wait before writing back the completion information to a
  transfer descriptor.  If the hardware waits more than 1 us, your scheme
  is doomed.
 
 it works on Intel Corporation N10/ICH 7 Family USB2 EHCI Controller
 
 I measured times for 4-byte IN transfer:
 
 fill+submit time 7 us (average) +- 1.5 us
 transaction time 3.7 us (average) +- 0.5 us (without tails)

How did you measure the transaction time?  Using a bus analyzer?

 completion time 20-150 us (flat), as expected for microframe boundary
 not synched with transfer
 
 getnstimeofday overhead 60 ns (used to measure times)
 
 transaction time increases up to 20 us for 1% of 1 transfers
 
 histograms in png are attached to the email.
 
 so 4 us latency is achievable

For one transaction.  If each external read/write operation requires
two USB transactions then the latency will be higher.  But maybe you
could change the implementation: Map an external bus read to a USB IN
transfer and an external bus write to a USB OUT transfer.

Alan Stern

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

Re: [PATCH] usb: host: xhci: Compliance Mode port recovery

['Greg KH']

On Mon, Jul 30, 2012 at 03:22:52PM -0500, Alexis Cortes wrote:
 Hi Greg,
 
 I'm sorry for my late response on this. First of all thanks for your reply
 and your feedback :) 
 
 We have been discussing with one of our major customers the possibility of
 identifying the platforms with the failing piece of hardware
 (SN65LVPE502CP), and as you suggested they have provided some DMI strings we
 can check in order to identify the platforms where those devices were
 installed. 
 
 I have modified the patch so it will be executed only on those platforms
 reporting the specified DMI strings. I also applied some other suggestions
 you made on your previous email.
 
 I would really appreciate if you could take a look at the patch and give me
 your feedback. Do you think that the patch is now suitable to be included in
 future kernel releases? 

That's really up to Sarah, as she is the maintainer of this driver.

How about resending it in a format that it can be applied in, and she
will take it from there?

But, at first glance, yes, it's much nicer now that you are matching on
DMI entries, thanks for taking the time to do that.

thanks,

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

Re: usb scheduler

[Alexey Filin]

On Tue, Jul 31, 2012 at 1:08 AM, Alan Stern st...@rowland.harvard.edu wrote:
 On Mon, 30 Jul 2012, Alexey Filin wrote:

  Yes, something like it might work, I think.  But you probably wouldn't
  want to use URBs for this; they have too much overhead.  You'd need a
  more direct interface to the host controller driver.

 really, too much, about 7 us on my pc (Core2 Duo CPU  E7500  2.93GHz)
 a direct access to EHCI controller should be used

 
  The EHCI spec doesn't put any strict time limit on how long the host
  controller can wait before writing back the completion information to a
  transfer descriptor.  If the hardware waits more than 1 us, your scheme
  is doomed.

 it works on Intel Corporation N10/ICH 7 Family USB2 EHCI Controller

 I measured times for 4-byte IN transfer:

 fill+submit time 7 us (average) +- 1.5 us
 transaction time 3.7 us (average) +- 0.5 us (without tails)

 How did you measure the transaction time?  Using a bus analyzer?

Unfortunately I don't have one. Temporary licence for WaveRunner 6Zi
is over. If you can recommend specialised USB bus analyzer for usage
with Linux I would be thank you.

I call getnstimeofday in such a way:

memset buffer to zero
clear t0, t1, t2, t3
getnstimeofday( t0 )
fill+submit
getnstimeofday( t1 )
while buffer is empty, test it
getnstimeofday( t2 )

completion handler: getnstimeofday( t3 )

So (brackets because we should take into account seconds and nanoseconds):
submission time = [t1] - [t0]
transaction time = [t2] - [t1]
completion time = [t3] - [t1]

Of course estimate of transaction and completion time is less than
real, I hope error is small.

usb device sends 4 non-zero bytes.


 completion time 20-150 us (flat), as expected for microframe boundary
 not synched with transfer

 getnstimeofday overhead 60 ns (used to measure times)

 transaction time increases up to 20 us for 1% of 1 transfers

Not 1 percent, some percents. May be long transfers are executed
during bus service intervals (listen for new devices, time reserved
for interrupt transfers, don't know).
I noted: transfer time is usually less 1 us just after reset of USB
device, don't know why.


 histograms in png are attached to the email.

 so 4 us latency is achievable

 For one transaction.  If each external read/write operation requires
 two USB transactions then the latency will be higher.  But maybe you
 could change the implementation: Map an external bus read to a USB IN
 transfer and an external bus write to a USB OUT transfer.

Address to read/write by is required always to be sent to device. In
any case I will discuss the results with our hw designers. The way is
enough risky but latencies are not guaranteed for any bus.

Regards,
Alexey.
--
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 v6 00/14] add imx usb driver based on Greg next tree

[Fabio Estevam]

On Mon, Jun 25, 2012 at 11:37 PM, Shawn Guo shawn@linaro.org wrote:
 On Mon, Jun 25, 2012 at 01:18:22PM -0300, Fabio Estevam wrote:
 Any suggestions as to how to make the driver work on mx23?

 I won't be able to test it on my imx23-evk board, because the board
 design is somehow odd on vbus supply, which probably requires a board
 rework.

Which board rework?

It looks like the 2.6.35 FSL kernel supports USB host on mx23evk
without the need of hardware rework.

Can we try getting USB to work on mx23 too?

Regards,

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

Re: [PATCH 2/2] xhci: EHCI/XHCI ports switching on Intense-PC.

[Sarah Sharp]

Hi Denis,

Can you send me the output of `sudo dmidecode`?  I'd like to see if I
can make a more general patch apply to the Intense-PC.

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: bisected regression, v3.5 - next-20120724: PCI PM causes USB hotplug failure

[Huang Ying]

On Mon, 2012-07-30 at 18:57 +0200, Bjørn Mork wrote:
 huang ying huang.ying.cari...@gmail.com writes:
 
  On Mon, Jul 30, 2012 at 4:08 PM, Bjørn Mork bj...@mork.no wrote:
  Huang Ying ying.hu...@intel.com writes:
 
  Do you have time to test the following patch to fix the lspci issue?
 
  Subject: [BUGFIX] PCI/PM: Keep parent bridge active when read/write 
  config reg
 
 
  Sure.  But keep this going and I will file a request for modular build
  of the PCI subsystem :-)
 
  Why?  All not so old PC hardware has PCI/PCIe devices.
 
 So that I didn't have to reboot all the time to test your new patches...
 
 It was a (bad) joke.  I don't really think my laptop would work all that
 well without PCI.

Haha, understood now.

Best Regards,
Huang Ying

--
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/2] UVC webcam gadget related changes

[Bhupesh Sharma]

This patchset tries to handle all the review comments received
on the following UVC gadget related patches:

[PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
[PATCH 5/5] usb: gadget/uvc: Add support for 'USB_GADGET_DELAYED_STATUS'
response for a set_intf(alt-set 1) command

which can be viewed here:
[1] http://patchwork.linuxtv.org/patch/11563/
[2] http://patchwork.linuxtv.org/patch/11564/

The rest of the patches in the original patchset have been applied.

This patchset is based on the tag 'gadget-for-v3.6'.

I have tested this patchset on a super-speed compliant USB device
controller (DWC3), with the VIVI capture device acting as a dummy source
of video data and I also have modified the 'uvc-gadget' application written
by Laurent (original application available here:
http://git.ideasonboard.org/uvc-gadget.git) for testing the
complete flow from V4L2 to UVC domain and vice versa.

Changes since V1:
- Addresses the review comments received on V1 of this patchset from Laurent

Bhupesh Sharma (2):
  usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
  usb: gadget/uvc: Add support for 'USB_GADGET_DELAYED_STATUS' response
for a set_intf(alt-set 1) command

 drivers/usb/gadget/f_uvc.c |   16 +-
 drivers/usb/gadget/uvc.h   |1 +
 drivers/usb/gadget/uvc_queue.c |  531 
 drivers/usb/gadget/uvc_queue.h |   25 +--
 drivers/usb/gadget/uvc_v4l2.c  |   42 ++--
 drivers/usb/gadget/uvc_video.c |   28 ++-
 6 files changed, 216 insertions(+), 427 deletions(-)

-- 
1.7.2.2

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

[PATCH V2 1/2] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework

[Bhupesh Sharma]

This patch reworks the videobuffer management logic present in the UVC
webcam gadget and ports it to use the more apt videobuf2 framework for
video buffer management.

To support routing video data captured from a real V4L2 video capture
device with a zero copy operation on videobuffers (as they pass from
the V4L2 domain to UVC domain via a user-space application), we need to support
USER_PTR IO method at the UVC gadget side.

So the V4L2 capture device driver can still continue to use MMAP IO
method and now the user-space application can just pass a pointer to the video
buffers being dequeued from the V4L2 device side while queueing them at the UVC
gadget end. This ensures that we have a zero-copy design as the videobuffers
pass from the V4L2 capture device to the UVC gadget.

Note that there will still be a need to apply UVC specific payload
headers on top of each UVC payload data, which will still require a copy
operation to be performed in the 'encode' routines of the UVC gadget.

This patch also addresses two issues found out while porting the UVC
gadget to videobuf2 framework:
- In case the usb requests queued by the gadget get completed
  with a status of -ESHUTDOWN (disconnected from host), the
  queue of videobuf2 should be cancelled to ensure that the
  application space daemon is not left in a state waiting for
  a vb2 to be successfully absorbed at the USB side.

- In case the underlying UDC has already returned -ESHUTDOWN
  as status of a queued request, it means that the video
  streaming endpoint is going to be disabled and hence the
  underlying UDC will giveback all queued requests with a status
  of -ESHUTDOWN. In such a case, the requests are not longer
  queued at the UDC end and it doesn't make sense to dequeue
  them again in uvc_video_enable(0).

Signed-off-by: Bhupesh Sharma bhupesh.sha...@st.com
---
 drivers/usb/gadget/uvc_queue.c |  531 
 drivers/usb/gadget/uvc_queue.h |   25 +--
 drivers/usb/gadget/uvc_v4l2.c  |   27 +--
 drivers/usb/gadget/uvc_video.c |   28 ++-
 4 files changed, 190 insertions(+), 421 deletions(-)

diff --git a/drivers/usb/gadget/uvc_queue.c b/drivers/usb/gadget/uvc_queue.c
index 104ae9c..bf6621b 100644
--- a/drivers/usb/gadget/uvc_queue.c
+++ b/drivers/usb/gadget/uvc_queue.c
@@ -10,6 +10,7 @@
  * (at your option) any later version.
  */
 
+#include linux/atomic.h
 #include linux/kernel.h
 #include linux/mm.h
 #include linux/list.h
@@ -18,7 +19,8 @@
 #include linux/videodev2.h
 #include linux/vmalloc.h
 #include linux/wait.h
-#include linux/atomic.h
+
+#include media/videobuf2-vmalloc.h
 
 #include uvc.h
 
@@ -28,330 +30,163 @@
  * Video queues is initialized by uvc_queue_init(). The function performs
  * basic initialization of the uvc_video_queue struct and never fails.
  *
- * Video buffer allocation and freeing are performed by uvc_alloc_buffers and
- * uvc_free_buffers respectively. The former acquires the video queue lock,
- * while the later must be called with the lock held (so that allocation can
- * free previously allocated buffers). Trying to free buffers that are mapped
- * to user space will return -EBUSY.
- *
- * Video buffers are managed using two queues. However, unlike most USB video
- * drivers that use an in queue and an out queue, we use a main queue to hold
- * all queued buffers (both 'empty' and 'done' buffers), and an irq queue to
- * hold empty buffers. This design (copied from video-buf) minimizes locking
- * in interrupt, as only one queue is shared between interrupt and user
- * contexts.
- *
- * Use cases
- * -
- *
- * Unless stated otherwise, all operations that modify the irq buffers queue
- * are protected by the irq spinlock.
- *
- * 1. The user queues the buffers, starts streaming and dequeues a buffer.
- *
- *The buffers are added to the main and irq queues. Both operations are
- *protected by the queue lock, and the later is protected by the irq
- *spinlock as well.
- *
- *The completion handler fetches a buffer from the irq queue and fills it
- *with video data. If no buffer is available (irq queue empty), the handler
- *returns immediately.
- *
- *When the buffer is full, the completion handler removes it from the irq
- *queue, marks it as ready (UVC_BUF_STATE_DONE) and wakes its wait queue.
- *At that point, any process waiting on the buffer will be woken up. If a
- *process tries to dequeue a buffer after it has been marked ready, the
- *dequeing will succeed immediately.
- *
- * 2. Buffers are queued, user is waiting on a buffer and the device gets
- *disconnected.
- *
- *When the device is disconnected, the kernel calls the completion handler
- *with an appropriate status code. The handler marks all buffers in the
- *irq queue as being erroneous (UVC_BUF_STATE_ERROR) and wakes them up so
- *that any process 

[PATCH V2 2/2] usb: gadget/uvc: Add support for 'USB_GADGET_DELAYED_STATUS' response for a set_intf(alt-set 1) command

[Bhupesh Sharma]

This patch adds the support in UVC webcam gadget design for providing
USB_GADGET_DELAYED_STATUS in response to a set_interface(alt setting 1)
command issue by the Host.

The current UVC webcam gadget design generates a STREAMON event
corresponding to a set_interface(alt setting 1) command from the Host.
This STREAMON event will eventually be routed to a real V4L2 device.

To start video streaming, it may be required to perform some register
writes to a camera sensor device over slow external busses like I2C or SPI.
So, it makes sense to ensure that we delay the STATUS stage of the
set_interface(alt setting 1) command.

Otherwise, a lot of ISOC IN tokens sent by the Host will be replied to
by zero-length packets by the webcam device. On certain Hosts this may even
lead to ISOC URBs been cancelled from the Host side.

So, as soon as we finish doing all the streaming related stuff on the
real V4L2 device, we call a STREAMON ioctl on the UVC side and from here we
call the 'usb_composite_setup_continue' function to complete the status
stage of the set_interface(alt setting 1) command.

Further, we need to ensure that we queue no video buffers on the UVC
webcam gadget, until we de-queue a video buffer from the V4L2 device.
So, the application should call the STREAMON on UVC side only when it has
dequeued sufficient buffers from the V4L2 side and queued them to the
UVC gadget.

Signed-off-by: Bhupesh Sharma bhupesh.sha...@st.com
---
 drivers/usb/gadget/f_uvc.c|   16 +++-
 drivers/usb/gadget/uvc.h  |1 +
 drivers/usb/gadget/uvc_v4l2.c |   15 ++-
 3 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index 2a8bf06..22f7570 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -272,6 +272,13 @@ uvc_function_setup(struct usb_function *f, const struct 
usb_ctrlrequest *ctrl)
return 0;
 }
 
+void uvc_function_setup_continue(struct uvc_device *uvc)
+{
+   struct usb_composite_dev *cdev = uvc-func.config-cdev;
+
+   usb_composite_setup_continue(cdev);
+}
+
 static int
 uvc_function_get_alt(struct usb_function *f, unsigned interface)
 {
@@ -334,7 +341,8 @@ uvc_function_set_alt(struct usb_function *f, unsigned 
interface, unsigned alt)
v4l2_event_queue(uvc-vdev, v4l2_event);
 
uvc-state = UVC_STATE_CONNECTED;
-   break;
+
+   return 0;
 
case 1:
if (uvc-state != UVC_STATE_CONNECTED)
@@ -352,14 +360,12 @@ uvc_function_set_alt(struct usb_function *f, unsigned 
interface, unsigned alt)
v4l2_event.type = UVC_EVENT_STREAMON;
v4l2_event_queue(uvc-vdev, v4l2_event);
 
-   uvc-state = UVC_STATE_STREAMING;
-   break;
+
+   return USB_GADGET_DELAYED_STATUS;
 
default:
return -EINVAL;
}
-
-   return 0;
 }
 
 static void
diff --git a/drivers/usb/gadget/uvc.h b/drivers/usb/gadget/uvc.h
index 93b0c11..9391993 100644
--- a/drivers/usb/gadget/uvc.h
+++ b/drivers/usb/gadget/uvc.h
@@ -190,6 +190,7 @@ struct uvc_file_handle
  * Functions
  */
 
+extern void uvc_function_setup_continue(struct uvc_device *uvc);
 extern void uvc_endpoint_stream(struct uvc_device *dev);
 
 extern void uvc_function_connect(struct uvc_device *uvc);
diff --git a/drivers/usb/gadget/uvc_v4l2.c b/drivers/usb/gadget/uvc_v4l2.c
index 134bfe5..b47e0f7 100644
--- a/drivers/usb/gadget/uvc_v4l2.c
+++ b/drivers/usb/gadget/uvc_v4l2.c
@@ -245,7 +245,20 @@ uvc_v4l2_do_ioctl(struct file *file, unsigned int cmd, 
void *arg)
if (*type != video-queue.queue.type)
return -EINVAL;
 
-   return uvc_video_enable(video, 1);
+   /* enable uvc video. */
+   ret = uvc_video_enable(video, 1);
+   if (ret  0)
+   return ret;
+
+   /*
+* since the real video device has now started streaming
+* its safe now to complete the status phase of the
+* set_interface (alt setting 1)
+*/
+   uvc_function_setup_continue(uvc);
+   uvc-state = UVC_STATE_STREAMING;
+
+   return 0;
}
 
case VIDIOC_STREAMOFF:
-- 
1.7.2.2

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

RE: [PATCH v3 1/3] USB: chipidea: add imx usbmisc support

[Chen Peter-B29397]

 
 
  usbmisc 0 would then mean port 0 of the usbmisc device.
 I didn't add the restriction that a usbmisc driver must have a usbmisc
 device. I'm not sure whether all SoC and future SoC can be look as
 a device.
 
 Peter, do you have any idea?
 
I have not followed this usbmisc design, I just list some facts at i.mx
USB controller:

Sigmatel-derived SoCs (i.mx23, i.mx28) have no this register region, all phy 
controls
are through PHY register.
Other freescale SoCs have this usbmisc register region to control phy and tune 
some
signal quality. This register region is from another 0x800 or (last controller 
base address + 0x200) 

 Thanks
 Richard
 
  If the usbmisc property exists, you can return -EPROBE_DEFER until it
 is
  available. If it doesn't exist, you just continue without usbmisc
  support (i.MX28)
 
  Sascha
 
 
  --
  Pengutronix e.K.   |
 |
  Industrial Linux Solutions | http://www.pengutronix.de/
 |
  Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
 |
  Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917-
  |
 

--
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: bisected regression, v3.5 - next-20120724: PCI PM causes USB hotplug failure

[Huang Ying]

On Mon, 2012-07-30 at 10:19 -0400, Alan Stern wrote:
 On Mon, 30 Jul 2012, Huang Ying wrote:
 
   Yup, that worked in the quick test I just did.
   
lspci reading the device config will still not wake the bridge, but I
   assume that is intentional?  But loading the device driver now wakes
   both the bridge and the device, so that works.
  
  Do you have time to test the following patch to fix the lspci issue?
  
  Subject: [BUGFIX] PCI/PM: Keep parent bridge active when read/write config 
  reg
  
  This patch fixes the following bug:
  
  http://marc.info/?l=linux-pcim=134338059022620w=2
  
  Where lspci does not work properly if a device and the corresponding
  parent bridge (such as PCIe port) is suspended.  This is because the
  device configuration space registers will be not accessible if the
  corresponding parent bridge is suspended.
  
  To solve the issue, the bridge/PCIe port connected to the device is
  put into active state before read/write configuration space registers.
 
 What happens when you run lspci and the device is in D3cold?  Then even 
 if the parent bridge is active, lspci will still fail.
 
 It seems that in this case you need to resume the device itself, not 
 just its parent.

How about the following patch?

Subject: [BUGFIX] PCI/PM: Keep parent bridge active when read/write config reg

This patch fixes the following bug:

http://marc.info/?l=linux-pcim=134338059022620w=2

Where lspci does not work properly if a device and the corresponding
parent bridge (such as PCIe port) is suspended.  This is because the
device configuration space registers will be not accessible if the
corresponding parent bridge is suspended or the device is put into
D3cold state.

To solve the issue, the bridge/PCIe port connected to the device is
put into active state before read/write configuration space registers.
If the device is in D3cold state, it will be put into active state
too.

To avoid resume/suspend PCIe port for each configuration register
read/write, a small delay is added before the PCIe port to go
suspended.

Reported-by: Bjorn Mork bj...@mork.no
Signed-off-by: Huang Ying ying.hu...@intel.com
---
 drivers/pci/pci-sysfs.c|   68 ++---
 drivers/pci/pcie/portdrv_pci.c |9 +
 2 files changed, 60 insertions(+), 17 deletions(-)

--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -463,15 +463,17 @@ pci_read_config(struct file *filp, struc
struct bin_attribute *bin_attr,
char *buf, loff_t off, size_t count)
 {
-   struct pci_dev *dev = to_pci_dev(container_of(kobj,struct device,kobj));
+   struct device *dev = container_of(kobj,struct device,kobj);
+   struct pci_dev *pdev = to_pci_dev(dev);
+   struct device *parent = dev-parent;
unsigned int size = 64;
loff_t init_off = off;
u8 *data = (u8*) buf;
 
/* Several chips lock up trying to read undefined config space */
if (security_capable(filp-f_cred, init_user_ns, CAP_SYS_ADMIN) == 0) {
-   size = dev-cfg_size;
-   } else if (dev-hdr_type == PCI_HEADER_TYPE_CARDBUS) {
+   size = pdev-cfg_size;
+   } else if (pdev-hdr_type == PCI_HEADER_TYPE_CARDBUS) {
size = 128;
}
 
@@ -484,9 +486,20 @@ pci_read_config(struct file *filp, struc
size = count;
}
 
+   if (parent)
+   pm_runtime_get_sync(parent);
+   pm_runtime_get_noresume(dev);
+   /*
+* pdev-current_state is set to PCI_D3cold during suspending,
+* so wait until suspending completes
+*/
+   pm_runtime_barrier(dev);
+   if (pdev-current_state == PCI_D3cold)
+   pm_runtime_resume(dev);
+
if ((off  1)  size) {
u8 val;
-   pci_user_read_config_byte(dev, off, val);
+   pci_user_read_config_byte(pdev, off, val);
data[off - init_off] = val;
off++;
size--;
@@ -494,7 +507,7 @@ pci_read_config(struct file *filp, struc
 
if ((off  3)  size  2) {
u16 val;
-   pci_user_read_config_word(dev, off, val);
+   pci_user_read_config_word(pdev, off, val);
data[off - init_off] = val  0xff;
data[off - init_off + 1] = (val  8)  0xff;
off += 2;
@@ -503,7 +516,7 @@ pci_read_config(struct file *filp, struc
 
while (size  3) {
u32 val;
-   pci_user_read_config_dword(dev, off, val);
+   pci_user_read_config_dword(pdev, off, val);
data[off - init_off] = val  0xff;
data[off - init_off + 1] = (val  8)  0xff;
data[off - init_off + 2] = (val  16)  0xff;
@@ -514,7 +527,7 @@ pci_read_config(struct file *filp, struc
 
if (size = 2) {
u16 val;
-   pci_user_read_config_word(dev, off, val);
+   

Re: [PATCH 2/2] xhci: EHCI/XHCI ports switching on Intense-PC.

[Oliver Neukum]

On Monday 30 July 2012 15:34:06 Sarah Sharp wrote:
 Hi Denis,
 
 Can you send me the output of `sudo dmidecode`?  I'd like to see if I
 can make a more general patch apply to the Intense-PC.

As this is for shutdown, why not all systems?

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] usb: host: ohci-platform: add pm_runtime_xx()

[Kuninori Morimoto]

this patch enable to use pm_runtime_xxx() on ohci-platform
if .config has CONFIG_PM_RUNTIME, otherwise, these are ignored

Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
 drivers/usb/host/ohci-platform.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index 670c705..6fe73ac 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -124,6 +124,9 @@ static int __devinit ohci_platform_probe(struct 
platform_device *dev)
if (err)
goto err_iounmap;
 
+   pm_runtime_enable(dev-dev);
+   pm_runtime_get_sync(dev-dev);
+
platform_set_drvdata(dev, hcd);
 
return err;
@@ -141,6 +144,9 @@ static int __devexit ohci_platform_remove(struct 
platform_device *dev)
 {
struct usb_hcd *hcd = platform_get_drvdata(dev);
 
+   pm_runtime_put_sync(dev-dev);
+   pm_runtime_disable(dev-dev);
+
usb_remove_hcd(hcd);
iounmap(hcd-regs);
release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
-- 
1.7.5.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: the dreaded needs XHCI_TRUST_TX_LENGTH quirk returns

[Matthew Hall]

On Thu, Jul 26, 2012 at 11:36:44PM -0700, Matthew Hall wrote:
 On Thu, Jul 26, 2012 at 11:27:47PM -0700, Sarah Sharp wrote:
  Man, I hope my code hasn't eaten your disk.  Is there any chance you
  could replace the drive in the enclosure and create a new file system to
  test?
 
 This part is tricky, because I only have two of these SDXC memory cards, and 
 I 
 haven't got a reliable way of formatting exfat back onto one right now to be 
 sure I get a clean run.
 
 My only Windows box is a Windows XP VirtualBox VM, because I've used Linux as 
 my by-far primary OS since 2005 and main OS since 1996. I will try to see if 
 I 
 can convince XP to put a new exfat FS on there using one of the USB 2.0 ports 
 and see how far I get.

Hi Sarah,

I found I could format it with the Windows XP CLI via USB 2 port from inside 
VirtualBox, as long as the exfat system update was present, so we get an 
authoritative patent-encumbered filesystem. :-/

After performing this step, while we have the quirks patch and memory 
wraparound patch applied, the behavior is the same as before, although 
subjectively it seems like it could be coming unmounted more rapidly.

http://www.mhcomputing.net/tmp/xhci-bug/dmesg-usb-3-port-reformatted.txt.gz

What are the next steps needed in order to make progress from this point? 
Originally, I was hoping I could get the card reader working right in time for 
Saturday, when I'd like to use it to transfer some huge 24 mbit AVCHD files 
from a new video camera out of some SDXC cards into my desktop so I can 
transcode them, but it seems like I'll be stuck with USB 2 for now.

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

Re: [PATCH 3/3] usb: Change persist_enabled when attribute avoid_reset_quirk is modified

[Lan Tianyu]

On 2012年07月30日 23:16, Alan Stern wrote:

On Mon, 30 Jul 2012, Oliver Neukum wrote:


On Monday 30 July 2012 10:39:50 Alan Stern wrote:

this leads to behavior that is not easy to predict or understand.
It would be cleaner to leave the flag alone and check for the quirk
in addition for the flag when the check is done.


I disagree.  Leaving the flag set but then not implementing the
persist behavior would be confusing also.  Maybe even worse.


But we cannot guarantee persistance anyway. We can only try.
But trying makes no sense if we are sure to fail.

In addition, we even undermine the file permission to a small
extent if we allow one attribute to alter another attribute.


Putting all these thoughts together leads to a single conclusion:

We should not change persist_enabled when avoid_reset_quirk
gets set.

As you say, coupling the two attributes is confusing and circumvents
the permissions.  If the device needs a reset-resume, we'll go ahead
and try to do it.  If the reset fails because the firmware gets erased,
at least there will be an error message in the system log to explain
what went wrong.  (But it's still a good idea to add a sentence about
this issue to the Documentation file.)

Whereas if we silently change attribute values or silently skip a
reset-resume when RESET_MORPHS is set, there will be no indication in
the log or anywhere else to tell the user what happened.


How about checking RESET_MORPHS before doing reset_resume, set reset_resume
to 0 and do resume when RESET_MORPHS is set. At the same time, print Convert
reset_resume to resume due to RESET_MORPHS. Then these two attributes are
separated but for reset-resume, there are two conditions. persist is true
RESET_MORPHS is unset.


--
Best Regards
Tianyu Lan
linux kernel enabling team
--
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