USB 3.0 ports drops when using usb3 external hard drive dock.
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
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
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()
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
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
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
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
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
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
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
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
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
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
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
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()
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.
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.
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
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()
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
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
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
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
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
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
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
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
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.
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
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
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
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
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()
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.
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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.
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()
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
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
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