Re: [linux-usb-devel] USB Host at full speed
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, May 29, 2007 5:11 PM To: [EMAIL PROTECTED] Subject: USB Host at full speed Hello ALL, I m currently trying to force the USB host controller from MPC8349 to only work at full speed i.e. whatever is the connected device, the bandwidth should be 12MB. I thought i could perform it just by setting some registers to right value but it aren't working. I fear i have to force software to always use TT and split transfer but i dont know exactly where to start.. If anybody could help, would be so great!! Your question can be interpreted as how to force EHCI host driver to work in full speed. Usb-devel list cc'ed should be a better place for such a question. - Leo - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB Host at full speed
Am Dienstag, 29. Mai 2007 13:01 schrieb Li Yang-r58472: Your question can be interpreted as how to force EHCI host driver to work in full speed. Usb-devel list cc'ed should be a better place for such a question. It can't, which is the reason you pair EHCI with OHCI/UHCI. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Please reactivate your Yahoo! Groups email address
Dear Yahoo! Groups member, You belong to one or more email groups provided by Yahoo! Groups (groups.yahoo.com). Recently, messages sent to you from Yahoo! Groups have been returned to us as undeliverable. As a result, we have temporarily turned off message delivery to this email address. If you are reading this message, the delivery problem appears to be fixed. To start receiving your groups messages by email again and turn your account back on, please visit: http://groups.yahoo.com/unbounce?adj=232689933,17976p=1180440294 (You can also copy and paste this link into your browser, and hit the 'Return' key.) Once you reactivate your Yahoo! Groups account by clicking the link above, you will receive messages from your group(s) again. Tip: You can read messages you might have missed while delivery was turned off by visiting your groups here: http://groups.yahoo.com/mygroups Thank you for using Yahoo! Groups! Yahoo! Groups Customer Care Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Removing Gadget File Storage module
On 5/28/07, Alan Stern [EMAIL PROTECTED] wrote: On Mon, 28 May 2007, Ragner N Magalhães wrote: Hi all, I am working with OMAP H2 and when I run rmmod g_file_storage, it stay waiting some thing and not terminate ... Somebody know some thing about this ? Which version of the Linux kernel are you using? I am using the last omap git tree from http://www.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git If you enable debugging in g_file_storage, what shows up in the dmesg log? ... udc: OMAP UDC driver, version: 4 October 2004 (iso) (dma) bus platform: add driver omap_udc platform: Matched Device omap_udc with Driver omap_udc platform: Probing driver omap_udc with device omap_udc udc: OMAP UDC rev 3.6, Mini-AB udc: hmc mode 19, isp1301_omap transceiver udc: fifo mode 3, 392 bytes not used DEV: registering device: ID = 'gadget' PM: Adding info for No Bus:gadget bound device 'omap_udc' to driver 'omap_udc' platform: Bound Device omap_udc to Driver omap_udc DEV: registering device: ID = 'vcs2' PM: Adding info for No Bus:vcs2 DEV: registering device: ID = 'vcsa2' PM: Adding info for No Bus:vcsa2 DEV: registering device: ID = 'vcs1' PM: Adding info for No Bus:vcs1 DEV: registering device: ID = 'vcsa1' PM: Adding info for No Bus:vcsa1 DEV: registering device: ID = 'gadget-lun0' PM: Adding info for No Bus:gadget-lun0 g_file_storage gadget: File-backed Storage Gadget, version: 28 November 2005 g_file_storage gadget: Number of LUNs=1 g_file_storage gadget: transport=Bulk-only (x50) g_file_storage gadget: protocol=Transparent SCSI (x06) g_file_storage gadget: VendorID=x0525, ProductID=xa4a5, Release=x0308 g_file_storage gadget: removable=1, stall=1, buflen=16384 g_file_storage gadget: I/O thread pid: 957 otg: b_idle, SWITCH to gadget, ctrl 098021 isp1301_omap 1-002d: ready for dual-role USB ... tps65010: battery charging udc: USB reset done, gadget g_file_storage g_file_storage gadget: suspend g_file_storage gadget: resume udc: USB reset done, gadget g_file_storage g_file_storage gadget: suspend g_file_storage gadget: resume udc: USB reset done, gadget g_file_storage g_file_storage gadget: ep0-setup, length 8: 0: 80 06 00 01 00 00 40 00 g_file_storage gadget: get device descriptor g_file_storage gadget: ep0-in, length 18: 0: 12 01 00 02 00 00 00 40 25 05 a5 a4 08 03 01 02 10: 03 01 udc: USB reset done, gadget g_file_storage g_file_storage gadget: ep0-setup, length 8: 0: 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor g_file_storage gadget: ep0-in, length 18: 0: 12 01 00 02 00 00 00 40 25 05 a5 a4 08 03 01 02 10: 03 01 g_file_storage gadget: ep0-setup, length 8: 0: 80 06 00 06 00 00 0a 00 g_file_storage gadget: ep0-setup, length 8: 0: 80 06 00 06 00 00 0a 00 g_file_storage gadget: ep0-setup, length 8: 0: 80 06 00 06 00 00 0a 00 g_file_storage gadget: ep0-setup, length 8: 0: 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor g_file_storage gadget: ep0-in, length 9: 0: 09 02 23 00 01 01 04 e0 01 g_file_storage gadget: ep0-setup, length 8: 0: 80 06 00 02 00 00 23 00 g_file_storage gadget: get configuration descriptor g_file_storage gadget: ep0-in, length 35: 0: 09 02 23 00 01 01 04 e0 01 03 09 03 09 04 00 00 10: 02 08 06 50 05 07 05 81 02 40 00 00 07 05 02 02 20: 40 00 00 g_file_storage gadget: ep0-setup, length 8: 0: 80 06 00 03 00 00 ff 00 g_file_storage gadget: get string descriptor g_file_storage gadget: ep0-in, length 4: 0: 04 03 09 04 g_file_storage gadget: ep0-setup, length 8: 0: 80 06 02 03 09 04 ff 00 g_file_storage gadget: get string descriptor g_file_storage gadget: ep0-in, length 54: 0: 36 03 46 00 69 00 6c 00 65 00 2d 00 62 00 61 00 10: 63 00 6b 00 65 00 64 00 20 00 53 00 74 00 6f 00 20: 72 00 61 00 67 00 65 00 20 00 47 00 61 00 64 00 30: 67 00 65 00 74 00 g_file_storage gadget: ep0-setup, length 8: 0: 80 06 01 03 09 04 ff 00 g_file_storage gadget: get string descriptor g_file_storage gadget: ep0-in, length 106: 0: 6a 03 4c 00 69 00 6e 00 75 00 78 00 20 00 32 00 10: 2e 00 36 00 2e 00 32 00 32 00 2d 00 72 00 63 00 20: 32 00 2d 00 6f 00 6d 00 61 00 70 00 31 00 2d 00 30: 67 00 61 00 38 00 62 00 32 00 38 00 39 00 39 00 40: 65 00 2d 00 64 00 69 00 72 00 74 00 79 00 20 00 50: 77 00 69 00 74 00 68 00 20 00 6f 00 6d 00 61 00 60: 70 00 5f 00 75 00 64 00 63 00 g_file_storage gadget: ep0-setup, length 8: 0: 80 06 03 03 09 04 ff 00 g_file_storage gadget: get string descriptor g_file_storage gadget: ep0-in, length 26: 0: 1a 03 33 00 32 00 33 00 38 00 32 00 30 00 34 00 10: 45 00 36 00 46 00 37 00 36 00 g_file_storage gadget: ep0-setup, length 8: 0: 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration g_file_storage gadget: suspend g_file_storage gadget: resume tps65010: battery discharging g_file_storage gadget: unbind DEV:
Re: [linux-usb-devel] hub.c port power handling on over-current
To answer Your questions:
*) the affected hub does report per port power switching correctly
*) whether it is an erratum or design I can tell You in case I get
a clear answer on that point.
The following patch works well for my problem and might be useful
(at least not harmful) in the common code path:
--- linux-2.6.21.3/drivers/usb/host/ehci-hub.c.orig Tue May 29 17:12:50
2007
+++ linux-2.6.21.3/drivers/usb/host/ehci-hub.c Tue May 29 12:19:47 2007
@@ -389,6 +389,18 @@ ehci_hub_status_data (struct usb_hcd *hc
buf [1] |= 1 (i - 7);
status = STS_PCD;
}
+
+ /* The hub was supposed to disable port power autonomously on
over-current.
+* However, not all hubs can be trusted to do this although
they need port
+* power disabled in order to recover properly.
+*/
+ if (temp PORT_OCC) {
+ if (HCS_PPC(ehci-hcs_params)){
+ temp = ~(PORT_RWC_BITS | PORT_POWER);
+ writel (temp, ehci-regs-port_status [i]);
+ }
+ }
+
}
/* FIXME autosuspend idle root hubs */
spin_unlock_irqrestore (ehci-lock, flags);
- Christian
-Original Message-
From: David Brownell [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 26, 2007 6:18 AM
To: linux-usb-devel@lists.sourceforge.net
Cc: Engelmayer Christian
Subject: Re: [linux-usb-devel] hub.c port power handling on over-current
On Friday 25 May 2007, Engelmayer Christian wrote:
Hi all,
If I am not mistaken the current policy is to leave port power
enabled at all times during over-current situations and let
the power provider handle current limitation.
More accurately: let the hub handle it. And ISTR that the
hub is supposed to automatically power off (or at least current
limit) ports observing overcurrent conditions.
Overcurrent has been a problem recently with EHCI; I'm not
entirely sure why. It'd be no surprise to find that there's
something the driver should do differently for some silicon.
In particular, we want root hubs to follow chapter 11 of the
USB spec (hubs). The hub driver in usbcore expects that.
But the details of that expectation have changed a lot over
the 2.6 cycle, and I suspect some root hubs have fallen a
bit behind ... not acting enough like a real hub.
I experienced problems with the EHCI on an MPC8343E, which
after some over-current situations no longer asserts the
Connect Change Status Bit in the Port Status and Control Register,
leading to the result that USB would be fully functional, but
is no longer effectively serviced...
The solution to this problem according to Freescale support
would be to disable and re-enable port power after the over-current
situation. Trying this with a hardware debugger gets us back in service.
Is this an erratum, or are they saying that's how they read
the EHCI spec? Does this EHCI report that it supports per-port
power switching? (Probe messages with USB_DEBUG enabled will
report that, as will current versions of lsusb -v.)
I'd have to check, but I think that Linux won't currently turn
off per-port power unless the host controller reports that it
actually supports per-port power switching. And most EHCI
implementations don't report that in the hardware, so Linux
won't power it off ...
As I am no big fan of work-arounds and rather new to the
USB-subsystem, might I ask what would be an accaptable way
to patch this behaviour?
One thing to try would be to make the root hub descriptor
report that it supports per-port power switching ... assuming
that the hardware says otherwise. ehci_hub_descriptor() is
the thing; or maybe HCS_PPC().
I'd have to look at usbcore's hub driver again to verify,
but I think that might be sufficient to change its behavior.
If not, you might also have to modify ehci_hub_status() to
power off ports when OCC is detected ... some silicon will
do that automatically, some won't, Linux could always do so.
In general what we'd like to have is one code path which
can work on all hardware. If you read the EHCI spec you'll
see it allows some implementation flexibility in this area;
if this isn't an erratum, I'd expect that what makes your
case work better would not hurt other EHCI implementations.
- Dave
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hub.c port power handling on over-current
On Tuesday 29 May 2007, Engelmayer Christian wrote:
To answer Your questions:
*) the affected hub does report per port power switching correctly
*) whether it is an erratum or design I can tell You in case I get
a clear answer on that point.
The following patch works well for my problem and might be useful
(at least not harmful) in the common code path:
Looks fair to me ... it won't trigger on any of my hardware, none
of it reports per-port power switching.
Got a signed-off-by update? And and update so the lines stay
under 80 characters?
- Dave
--- linux-2.6.21.3/drivers/usb/host/ehci-hub.c.orig Tue May 29 17:12:50
2007
+++ linux-2.6.21.3/drivers/usb/host/ehci-hub.cTue May 29 12:19:47 2007
@@ -389,6 +389,18 @@ ehci_hub_status_data (struct usb_hcd *hc
buf [1] |= 1 (i - 7);
status = STS_PCD;
}
+
+ /* The hub was supposed to disable port power autonomously on
over-current.
+ * However, not all hubs can be trusted to do this although
they need port
+ * power disabled in order to recover properly.
+ */
+ if (temp PORT_OCC) {
+ if (HCS_PPC(ehci-hcs_params)){
+ temp = ~(PORT_RWC_BITS | PORT_POWER);
+ writel (temp, ehci-regs-port_status [i]);
+ }
+ }
+
}
/* FIXME autosuspend idle root hubs */
spin_unlock_irqrestore (ehci-lock, flags);
- Christian
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2.6.22-rc1-mm1] ehci-hcd - BUG: scheduling while atomic: rmmod/0x00000001/4568
On Tue, 29 May 2007 10:14:35 -0500 [EMAIL PROTECTED] wrote: Sorry about that. Would it be helpful if I verified that and sent it in signed off? Yes please. The question in my mind was did it add a race: say, the notifier chain gets called by some external source after we've gone and reset the device? -Original Message- From: Andrew Morton [mailto:[EMAIL PROTECTED] Sent: Friday, May 25, 2007 5:00 PM To: Greg KH Cc: Mattia Dongili; Linux Kernel Mailing List; Hayes, Stuart; David Brownell; linux-usb-devel@lists.sourceforge.net Subject: Re: [2.6.22-rc1-mm1] ehci-hcd - BUG: scheduling while atomic: rmmod/0x0001/4568 On Fri, 25 May 2007 14:40:05 -0700 Greg KH [EMAIL PROTECTED] wrote: On Mon, May 21, 2007 at 11:44:37AM +0900, Mattia Dongili wrote: Hello, with gregkh-usb-usb-ehci-cpufreq-fix.patch removing ehci-hcd causes the following BUG: Thanks for letting me know. Stuart, any help here? pretty obvious. cpufreq_unregister_notifier() sleeps, and that patch causes it to be called under spinlock. Something like this... --- a/drivers/usb/host/ehci-hcd.c~fix-gregkh-usb-usb-ehci-cpufreq-fix +++ a/drivers/usb/host/ehci-hcd.c @@ -452,14 +452,14 @@ static void ehci_stop (struct usb_hcd *h if (HC_IS_RUNNING (hcd-state)) ehci_quiesce (ehci); -#ifdef CONFIG_CPU_FREQ - cpufreq_unregister_notifier(ehci-cpufreq_transition, - CPUFREQ_TRANSITION_NOTIFIER); -#endif ehci_reset (ehci); ehci_writel(ehci, 0, ehci-regs-intr_enable); spin_unlock_irq(ehci-lock); +#ifdef CONFIG_CPU_FREQ + cpufreq_unregister_notifier(ehci-cpufreq_transition, + CPUFREQ_TRANSITION_NOTIFIER); +#endif /* let companion controllers work when we aren't */ ehci_writel(ehci, 0, ehci-regs-configured_flag); _ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 2.6.22-rc3] USB: Disable file_storage USB_CONFIG_ATT_WAKEUP
From: Tony Lindgren [EMAIL PROTECTED]
Disable file_storage USB_CONFIG_ATT_WAKEUP as it requires
user interaction during Chapter 9 tests.
Signed-off-by: Tony Lindgren [EMAIL PROTECTED]
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
Acked-by: Alan Stern [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
---
--- a/drivers/usb/gadget/file_storage.c
+++ b/drivers/usb/gadget/file_storage.c
@@ -3965,8 +3965,7 @@ static int __init fsg_bind(struct usb_gadget *gadget)
#endif
if (gadget-is_otg) {
- otg_desc.bmAttributes |= USB_OTG_HNP,
- config_desc.bmAttributes |= USB_CONFIG_ATT_WAKEUP;
+ otg_desc.bmAttributes |= USB_OTG_HNP;
}
rc = -ENOMEM;
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] crash for ftdi_sio, usbmon
I've managed to reproduce the problem despite cutting the link between 4 and 1,6 in both directions on my null modem cables. usb 1-1.1: uhci_result_common: failed with status 44 usb 1-1.2: uhci_result_common: failed with status 44 hub 1-1:1.0: state 7 ports 4 chg evt 0006 hub 1-1:1.0: port 1, status 0101, change 0001, 12 Mb/s usb 1-1.1: USB disconnect, address 9 usb 1-1.1: usb_disable_device nuking all URBs usb 1-1.1: unregistering interface 1-1.1:1.0 usbdev1.9_ep81: ep_device_release called for usbdev1.9_ep81 usbdev1.9_ep02: ep_device_release called for usbdev1.9_ep02 ftdi_sio 1-1.1:1.0: device disconnected usb 1-1.1:1.0: uevent usb 1-1.1: unregistering device Where exactly does it fail? Could you post the full log with debug and indicate when exactly it fails? Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Problem with V630i phone (0x0fce:0xe043)
OoO En ce milieu de nuit étoilée du mardi 29 mai 2007, vers 03:59, Alan Stern [EMAIL PROTECTED] disait: It looks like the phone's firmware is broken. Does it work with other non-Linux computer systems? Can you get a firmware update from the manufacturer? I have no Windows system, but I will try to access one to test. Sony Ericsson gives special drivers to work with Windows. I will try without and with it. Firmware update also needs Windows. -- panic(huh?\n); 2.2.16 /usr/src/linux/arch/i386/kernel/smp.c - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Fix OTG HNP for hub.c (USB OTG HNP (can you find any other appropriate TLAs?)
On Friday 25 May 2007, Tony Lindgren wrote:
+
Mostly this patch just seems to move a block of code into a
standalone function, removing some nesting ... which is OK
as a cleanup, but makes it hard to see the substantive changes
in this routine.
So it'd be best to see a minimal patch just fixing any bugs...
Those substantive changes unfortunately include inserting
bugs ... which would have been easier to see if they were
not interspersed with cleanups!
+ /* If B-device wants to do HNP, it will do it after we suspend */
+ if (bus-b_hnp_enable) {
+ dev_err(udev-dev, trying HNP, suspending bus\n);
+ err = __usb_port_suspend(udev, udev-bus-otg_port);
No, it shouldn't suspend at this point. If the device is in
the targeted peripherals list, the host must continue to try
using the device ... using the normal code paths.
Here, you've changed it to immediately try HNP, even when
the host wants to handle the targeted device (that is, when
A_BUS_REQ is true).
+ if (err 0) {
+ dev_err(udev-dev, suspend for HNP failed\n);
+ return -ENODEV;
+ }
+
+ /* TB_ASE0_BRST, minimum 3.125 ms */
+ mdelay(4);
The assumption was that lower level code would manage
T(A/SE0 -- B/RST) as part of triggering HNP in the root
hub ... the root hub can always tell if it's triggering
HNP, so that timeout applies. Since that timeout tends
to have hardware support, I'd rather not see it here.
+
+ /* Failed resume means B-device took over the bus with HNP */
There's another suspend/resume sequence to consider.
That's one triggered by autosuspend ... or in terms
of the OTG spec, when A_BUS_REQ goes false.
The original code sequence -- only trigger HNP for
unsupported devices -- handled normal use cases
correctly: hook up an OTG capable peripheral to the
OTG host, it gets used as usual until everything goes
idle, then it suspends (autoidle), and attempts HNP.
If HNP succeeds, work gets done the other direction
(host and peripheral roles switched), until *that* is
idlle, at which point b_host suspends; disconnect.
This modified code sequence skips that primary usage:
the peripheral can't be used as a peripheral, since
it immediately jumps into host mode.
+ err = usb_port_resume(udev);
+ if (err 0) {
+ dev_err(udev-dev, HNP success\n);
Not an error. Except in the sense that it shouldn't
have been tried here at all ... not a _runtime_ error.
+ return -ENODEV;
+ }
+ }
+
+ /* HNP failed. Reject B-devices not in our whitelist */
+ if (!is_targeted(udev))
... and here you fail for the wrong reason.
The original logic was OTG-conformant:
- Enable HNP early (later would be OK too);
- For non-whitelisted devices:
* trigger HNP if possible
* never proceed any further
- For whitelisted devices (*)
* proceed normally
* implicitly, autosuspend triggers HNP
This patch removes the primary (*) branch.
- Dave
+ return -ENODEV;
+
+ return 0;
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] USB: replace flush_workqueue with cancel_sync_work
This patch (as912) replaces a couple of calls to flush_workqueue()
with cancel_sync_work() and cancel_rearming_delayed_work(). Using a
more directed approach allows us to avoid some nasty deadlocks. The
prime example occurs when a first-level device (the parent is a root
hub) is removed while at the same time the root hub gets a remote
wakeup request. khubd would try to flush the autosuspend workqueue
while holding the root-hub's lock, and the remote-wakeup workqueue
routine would be waiting to lock the root hub.
The patch also reorganizes the power management portion of
usb_disconnect(), separating it out into its own routine. The
autosuspend workqueue entry is cancelled immediately instead of
waiting for the device's release routine. In addition,
synchronization with the autosuspend thread is carried out even for
root hubs (an oversight in the original code).
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
On Tue, 29 May 2007, Linus Torvalds wrote:
Ok, let's merge the fix them. Alan, can you send it up-stream with the
proper commit message and sign-off?
Here it is. This will apply to 2.6.22-rc3. I'll let you duke it out
with Greg and Andrew to see who wants to apply it where. :-)
Alan Stern
Index: 2.6.22-rc3/drivers/usb/core/hub.c
===
--- 2.6.22-rc3.orig/drivers/usb/core/hub.c
+++ 2.6.22-rc3/drivers/usb/core/hub.c
@@ -1158,6 +1158,30 @@ static void release_address(struct usb_d
}
}
+#ifdef CONFIG_USB_SUSPEND
+
+static void usb_stop_pm(struct usb_device *udev)
+{
+ /* Synchronize with the ksuspend thread to prevent any more
+* autosuspend requests from being submitted, and decrement
+* the parent's count of unsuspended children.
+*/
+ usb_pm_lock(udev);
+ if (udev-parent !udev-discon_suspended)
+ usb_autosuspend_device(udev-parent);
+ usb_pm_unlock(udev);
+
+ /* Stop any autosuspend requests already submitted */
+ cancel_rearming_delayed_work(udev-autosuspend);
+}
+
+#else
+
+static inline void usb_stop_pm(struct usb_device *udev)
+{ }
+
+#endif
+
/**
* usb_disconnect - disconnect a device (usbcore-internal)
* @pdev: pointer to device being disconnected
@@ -1224,13 +1248,7 @@ void usb_disconnect(struct usb_device **
*pdev = NULL;
spin_unlock_irq(device_state_lock);
- /* Decrement the parent's count of unsuspended children */
- if (udev-parent) {
- usb_pm_lock(udev);
- if (!udev-discon_suspended)
- usb_autosuspend_device(udev-parent);
- usb_pm_unlock(udev);
- }
+ usb_stop_pm(udev);
put_device(udev-dev);
}
Index: 2.6.22-rc3/drivers/usb/core/usb.c
===
--- 2.6.22-rc3.orig/drivers/usb/core/usb.c
+++ 2.6.22-rc3/drivers/usb/core/usb.c
@@ -184,10 +184,6 @@ static void usb_release_dev(struct devic
udev = to_usb_device(dev);
-#ifdef CONFIG_USB_SUSPEND
- cancel_delayed_work(udev-autosuspend);
- flush_workqueue(ksuspend_usb_wq);
-#endif
usb_destroy_configuration(udev);
usb_put_hcd(bus_to_hcd(udev-bus));
kfree(udev-product);
Index: 2.6.22-rc3/drivers/usb/core/hcd.c
===
--- 2.6.22-rc3.orig/drivers/usb/core/hcd.c
+++ 2.6.22-rc3/drivers/usb/core/hcd.c
@@ -1681,7 +1681,7 @@ void usb_remove_hcd(struct usb_hcd *hcd)
spin_unlock_irq (hcd_root_hub_lock);
#ifdef CONFIG_PM
- flush_workqueue(ksuspend_usb_wq);
+ cancel_work_sync(hcd-wakeup_work);
#endif
mutex_lock(usb_bus_list_lock);
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [Bugme-new] [Bug 8551] New: USB hard drive (iPod) I/O errors on read
On Tue, 29 May 2007 13:20:52 -0700 [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8551 Summary: USB hard drive (iPod) I/O errors on read Kernel Version: 2.6.20-16-generic Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did *NOT* occur:? Distribution:Ubuntu Feisty Fawn Hardware Environment:Biostar M7VIT Pro V1.0 Software Environment:Gnome Problem Description: I'm getting I/O errors when trying to read from a USB drive (iPod, 4th gen, 20 GB) on a fresh Feisty install. -The USB drive (iPod) works fine in Windows XP -I have a second, identical, iPod that acts the same way Kernel: 2.6.20-15-generic /var/log/messages [ 81.186626] usb 4-2: new high speed USB device using ehci_hcd and address 3 [ 81.319663] usb 4-2: configuration #1 chosen from 1 choice [ 81.320018] scsi1 : SCSI emulation for USB Mass Storage devices [ 86.323066] scsi 1:0:0:0: Direct-Access Apple iPod 1.62 PQ: 0 ANSI: 0 [ 86.326962] SCSI device sdb: 39063023 512-byte hdwr sectors (2 MB) [ 86.327854] sdb: Write Protect is off [ 86.329474] SCSI device sdb: 39063023 512-byte hdwr sectors (2 MB) [ 86.330351] sdb: Write Protect is off [ 86.330362] sdb: sdb1 sdb2 [ 86.401917] sd 1:0:0:0: Attached scsi removable disk sdb [ 86.402002] sd 1:0:0:0: Attached scsi generic sg1 type 0 [ 102.963876] usb 4-2: reset high speed USB device using ehci_hcd and address 3 [ 133.204025] usb 4-2: reset high speed USB device using ehci_hcd and address 3 [ 143.446733] usb 4-2: reset high speed USB device using ehci_hcd and address 3 [ 159.792681] usb 4-2: reset high speed USB device using ehci_hcd and address 3 [ 160.040649] usb 4-2: reset high speed USB device using ehci_hcd and address 3 [ 170.283313] usb 4-2: reset high speed USB device using ehci_hcd and address 3 [ 170.416509] sd 1:0:0:0: scsi: Device offlined - not ready after error recovery [ 170.416532] sd 1:0:0:0: SCSI error: return code = 0x0005 [ 170.416536] end_request: I/O error, dev sdb, sector 11072029 [ 170.416595] lost page write due to I/O error on sdb2 [ 170.416610] lost page write due to I/O error on sdb2 [ 170.416625] lost page write due to I/O error on sdb2 [ 170.416633] lost page write due to I/O error on sdb2 [ 170.416646] lost page write due to I/O error on sdb2 [ 170.416654] lost page write due to I/O error on sdb2 [ 170.416661] lost page write due to I/O error on sdb2 [ 170.416668] lost page write due to I/O error on sdb2 [ 176.519551] lost page write due to I/O error on sdb2 [ 176.519567] lost page write due to I/O error on sdb2 [ 210.206268] usb 4-2: USB disconnect, address 3 /var/log/dmesg [ 26.397583] usb 1-1: new full speed USB device using uhci_hcd and address 3 [ 26.567620] usb 1-1: configuration #1 chosen from 1 choice [ 26.572573] hub 1-1:1.0: USB hub found [ 26.574518] hub 1-1:1.0: 3 ports detected [ 26.845607] hdc: LTN526D, ATAPI CD/DVD-ROM drive [ 26.887371] usb 1-1.1: new full speed USB device using uhci_hcd and address 4 [ 27.031437] usb 1-1.1: configuration #1 chosen from 1 choice [ 27.247224] usb 1-1.2: new full speed USB device using uhci_hcd and address 5 [ 27.392287] usb 1-1.2: configuration #1 chosen from 1 choice [ 27.599068] usb 1-1.3: new full speed USB device using uhci_hcd and address 6 [ 27.629510] hdd: PLEXTOR CD-R PX-W1210A, ATAPI CD/DVD-ROM drive [ 27.685829] ide1 at 0x170-0x177,0x376 on irq 15 [ 27.697154] SCSI subsystem initialized [ 27.704343] libata version 2.20 loaded. [ 27.716512] hda: max request size: 128KiB [ 27.724969] hda: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100) [ 27.724982] hda: cache flushes not supported [ 27.725065] hda: hda1 hda2 6usb 1-1.3: configuration #1 chosen from 1 choice [ 27.768828] usbcore: registered new interface driver libusual [ 27.775215] Initializing USB Mass Storage driver... [ 27.779032] hda5 [ 27.779760] hdb: max request size: 128KiB [ 27.785634] hdb: 8421840 sectors (4311 MB) w/256KiB Cache, CHS=8912/15/63, UDMA(66) [ 27.785646] hdb: cache flushes not supported [ 27.785710] hdb:6scsi0 : SCSI emulation for USB Mass Storage devices [ 27.786890] usbcore: registered new interface driver usb-storage [ 27.786896] USB Mass Storage support registered. [ 27.787045] usb-storage: device found at 6 [ 27.787049] usb-storage: waiting for device to settle before scanning [ 27.820845] hdb1 [ 27.832704] hdc: ATAPI 52X CD-ROM drive, 120kB Cache, UDMA(33) [ 27.832717] Uniform CD-ROM driver Revision: 3.20 [ 27.872893] hdd: ATAPI 32X CD-ROM CD-R/RW drive, 2048kB Cache, DMA [ 28.354832] Attempting manual resume [ 28.354838] swsusp: Resume From Partition 3:5 [ 28.354841] PM: Checking swsusp image. [ 28.355024] PM: Resume from disk failed. [ 28.390346] kjournald starting. Commit interval 5 seconds [ 28.390365] EXT3-fs: mounted filesystem
[linux-usb-devel] Dealing with flaky USB storage devices and rootfs
Hello, We have a system where the rootfs is a partition on a USB device, and I've noticed upon a few rare cases where the USB controller loses the connection to the USB device after some uptime (days, weeks...), and the USB device reappears a very short time later. It doesn't really matter why, I guess that USB controllers and storage devices aren't always of the best quality - let's assume that. The issue is that Linux currently makes it problematic to recover the rootfs for several reasons. If /dev/sda1 is mounted as root and the SCSI device goes into offline mode, it is quite impossible to get out of this situation. At first, I had to disable the usermode helper that sends events to udev since it blocks on the dysfunction /dev/sda1. Afterwards, I noticed that the reappearing device is being assigned with /dev/sdb along with a new SCSI host. I guess the the VFS and block layer still keep a reference to the old scsi_disk and as a result sd doesn't free it. So, I gave some thoughts about this, I and came up with two main solutions: 1) Improve the USB storage error handling - bind the already existing SCSI host to the USB port that has the device, e.g., if host2 got created for usb 5-3 then keep it that way for the sake of EH. /dev/sda1 should come to life when the USB device recovers, unless a few seconds have passed or some attributes (such as manufactor id or serial) have changed. 2) Block layer hack - Write a special layering block device driver that acts as a proxy to the currently functioning /dev/sd* which gets auto-detected by this block layer driver. md multipath for the 'poor', you might say.. I chose '2' for the time being. It was much easier than hacking around the USB subsystem... Yes, I know rootfs on USB is an uncommon use-case at the moment but I do like to know if there are some improvements planned in this area. -- Dan Aloni XIV LTD, http://www.xivstorage.com da-x (at) monatomic.org, dan (at) xiv.co.il - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [3/4] 2.6.22-rc3: known regressions
Hi all, Here is a list of some known regressions in 2.6.22-rc3. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions Suspend Subject: 2.6.22-rc1 suspend to RAM problem References : http://permalink.gmane.org/gmane.linux.power-management.general/5819 Submitter : Marcus Better [EMAIL PROTECTED] Handled-By : Stefan Richter [EMAIL PROTECTED] Kristian Høgsberg [EMAIL PROTECTED] Status : caused by fw-ohci module Timers Subject: hrtimer overflow bug on 64-bit systems References : http://lkml.org/lkml/2007/5/24/391 Submitter : David Miller [EMAIL PROTECTED] Status : problem is being debugged TTY Subject: tty-related oops in latest kernel(s) References : http://lkml.org/lkml/2007/5/27/104 Submitter : Tero Roponen [EMAIL PROTECTED] Status : problem is being debugged USB Subject: usb hotplug/udev cannot correctly register usb/scanners References : http://lkml.org/lkml/2007/5/15/205 Submitter : [EMAIL PROTECTED] [EMAIL PROTECTED] Status : Unknown Regards, Michal -- Najbardziej brakowało mi twojego milczenia. -- Andrzej Sapkowski Coś więcej - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Fix OTG HNP for hub.c (USB OTG HNP (can you find any other appropriate TLAs?)
* David Brownell [EMAIL PROTECTED] [070529 12:18]:
On Friday 25 May 2007, Tony Lindgren wrote:
+
Mostly this patch just seems to move a block of code into a
standalone function, removing some nesting ... which is OK
as a cleanup, but makes it hard to see the substantive changes
in this routine.
So it'd be best to see a minimal patch just fixing any bugs...
Those substantive changes unfortunately include inserting
bugs ... which would have been easier to see if they were
not interspersed with cleanups!
Yes, I tried, but the nesting was getting too deep :)
+ /* If B-device wants to do HNP, it will do it after we suspend */
+ if (bus-b_hnp_enable) {
+ dev_err(udev-dev, trying HNP, suspending bus\n);
+ err = __usb_port_suspend(udev, udev-bus-otg_port);
No, it shouldn't suspend at this point. If the device is in
the targeted peripherals list, the host must continue to try
using the device ... using the normal code paths.
Here, you've changed it to immediately try HNP, even when
the host wants to handle the targeted device (that is, when
A_BUS_REQ is true).
Hmm, in the USB_OTG_1-3.pdf it says the host must offer HNP to
peripherals that support HNP during the session. In my patch
we offer it right away if the peripheral wants to use it.
Quoting few sentences from USB_OTG_1-3.pdf 6.4.1.4 a_host:
If the SetFeature(b_hnp_enable) command is sent and accepted
during the session, then the A-device shall exit to the a_suspend
state and wait for the B-device to start a session (See Section 6.5.2)
So the way I understand sent and accepted above, it's up to the
b_device to use or not use the HNP session offered.
+ if (err 0) {
+ dev_err(udev-dev, suspend for HNP failed\n);
+ return -ENODEV;
+ }
+
+ /* TB_ASE0_BRST, minimum 3.125 ms */
+ mdelay(4);
The assumption was that lower level code would manage
T(A/SE0 -- B/RST) as part of triggering HNP in the root
hub ... the root hub can always tell if it's triggering
HNP, so that timeout applies. Since that timeout tends
to have hardware support, I'd rather not see it here.
Sorry, I don't understand how you prefer the 3.125 ms
timeout handled, can you please clarify? Just leave it out?
+
+ /* Failed resume means B-device took over the bus with HNP
*/
There's another suspend/resume sequence to consider.
That's one triggered by autosuspend ... or in terms
of the OTG spec, when A_BUS_REQ goes false.
OK
The original code sequence -- only trigger HNP for
unsupported devices -- handled normal use cases
correctly: hook up an OTG capable peripheral to the
OTG host, it gets used as usual until everything goes
idle, then it suspends (autoidle), and attempts HNP.
If HNP succeeds, work gets done the other direction
(host and peripheral roles switched), until *that* is
idlle, at which point b_host suspends; disconnect.
This modified code sequence skips that primary usage:
the peripheral can't be used as a peripheral, since
it immediately jumps into host mode.
Yes, but as I understand it's up to the peripheral to use
the HNP or not when offered. So unless b_host is enabled
on peripheral, HNP does not get used.
I see your point though with autoidle, but that's after
the devices have enumerated the wrong way, right? If on
the b_device user selects b_host mode, it can start
right away when the devices are connected.
Maybe we should offer HNP early and every autoidle?
+ err = usb_port_resume(udev);
+ if (err 0) {
+ dev_err(udev-dev, HNP success\n);
Not an error. Except in the sense that it shouldn't
have been tried here at all ... not a _runtime_ error.
+ return -ENODEV;
+ }
+ }
+
+ /* HNP failed. Reject B-devices not in our whitelist */
+ if (!is_targeted(udev))
... and here you fail for the wrong reason.
The original logic was OTG-conformant:
- Enable HNP early (later would be OK too);
- For non-whitelisted devices:
* trigger HNP if possible
* never proceed any further
- For whitelisted devices (*)
* proceed normally
* implicitly, autosuspend triggers HNP
This patch removes the primary (*) branch.
AFAIK, the logic should be:
- Enable HNP early (later would be OK too);
- Offer to do HNP if the peripheral wants to use it
(Peripheral maintains _both_ b_hnp_enable set by
a_host and user preference on b_device on using
b_hnp_enable)
- For peripheral wanting to become b_host, suspend
and let b_host take over the bus
- For peripheral not wanting to become b_host, check
whitelist
- For whitelisted devices, proceed normally
- Reject non-whitelisted devices
But this I've only verified working with two N800s and
usbcv13.exe,
Re: [linux-usb-devel] [PATCH] USB: replace flush_workqueue with cancel_sync_work
Thanks again, Alan!
From: Alan Stern [EMAIL PROTECTED]
This patch (as912) replaces a couple of calls to flush_workqueue()
with cancel_sync_work() and cancel_rearming_delayed_work(). Using a
more directed approach allows us to avoid some nasty deadlocks. The
prime example occurs when a first-level device (the parent is a root
hub) is removed while at the same time the root hub gets a remote
wakeup request. khubd would try to flush the autosuspend workqueue
while holding the root-hub's lock, and the remote-wakeup workqueue
routine would be waiting to lock the root hub.
The patch also reorganizes the power management portion of
usb_disconnect(), separating it out into its own routine. The
autosuspend workqueue entry is cancelled immediately instead of
waiting for the device's release routine. In addition,
synchronization with the autosuspend thread is carried out even for
root hubs (an oversight in the original code).
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Acked-by: Mark Lord [EMAIL PROTECTED]
---
Index: 2.6.22-rc3/drivers/usb/core/hub.c
===
--- 2.6.22-rc3.orig/drivers/usb/core/hub.c
+++ 2.6.22-rc3/drivers/usb/core/hub.c
@@ -1158,6 +1158,30 @@ static void release_address(struct usb_d
}
}
+#ifdef CONFIG_USB_SUSPEND
+
+static void usb_stop_pm(struct usb_device *udev)
+{
+ /* Synchronize with the ksuspend thread to prevent any more
+* autosuspend requests from being submitted, and decrement
+* the parent's count of unsuspended children.
+*/
+ usb_pm_lock(udev);
+ if (udev-parent !udev-discon_suspended)
+ usb_autosuspend_device(udev-parent);
+ usb_pm_unlock(udev);
+
+ /* Stop any autosuspend requests already submitted */
+ cancel_rearming_delayed_work(udev-autosuspend);
+}
+
+#else
+
+static inline void usb_stop_pm(struct usb_device *udev)
+{ }
+
+#endif
+
/**
* usb_disconnect - disconnect a device (usbcore-internal)
* @pdev: pointer to device being disconnected
@@ -1224,13 +1248,7 @@ void usb_disconnect(struct usb_device **
*pdev = NULL;
spin_unlock_irq(device_state_lock);
- /* Decrement the parent's count of unsuspended children */
- if (udev-parent) {
- usb_pm_lock(udev);
- if (!udev-discon_suspended)
- usb_autosuspend_device(udev-parent);
- usb_pm_unlock(udev);
- }
+ usb_stop_pm(udev);
put_device(udev-dev);
}
Index: 2.6.22-rc3/drivers/usb/core/usb.c
===
--- 2.6.22-rc3.orig/drivers/usb/core/usb.c
+++ 2.6.22-rc3/drivers/usb/core/usb.c
@@ -184,10 +184,6 @@ static void usb_release_dev(struct devic
udev = to_usb_device(dev);
-#ifdef CONFIG_USB_SUSPEND
- cancel_delayed_work(udev-autosuspend);
- flush_workqueue(ksuspend_usb_wq);
-#endif
usb_destroy_configuration(udev);
usb_put_hcd(bus_to_hcd(udev-bus));
kfree(udev-product);
Index: 2.6.22-rc3/drivers/usb/core/hcd.c
===
--- 2.6.22-rc3.orig/drivers/usb/core/hcd.c
+++ 2.6.22-rc3/drivers/usb/core/hcd.c
@@ -1681,7 +1681,7 @@ void usb_remove_hcd(struct usb_hcd *hcd)
spin_unlock_irq (hcd_root_hub_lock);
#ifdef CONFIG_PM
- flush_workqueue(ksuspend_usb_wq);
+ cancel_work_sync(hcd-wakeup_work);
#endif
mutex_lock(usb_bus_list_lock);
-
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH 2.6.21.3 1/1] ehci-hub: improved over-current recovery
From: Christian Engelmayer [EMAIL PROTECTED]
According to the USB Specification Revision 2.0 chapter 11.12.5
a hub experiencing an over-current condition must place all
affected ports in the powered-off state. It seems that some hubs
violate this requirement, but need port power to be cycled by
software in order to get back to normal functionality after an
over-current condition.
Signed-off-by: Christian Engelmayer [EMAIL PROTECTED]
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
This fix was tested on an MPC8343E.
--- a/drivers/usb/host/ehci-hub.c.orig 2007-05-29 21:30:35.0 +0200
+++ b/drivers/usb/host/ehci-hub.c 2007-05-29 21:39:48.0 +0200
@@ -389,6 +389,20 @@ ehci_hub_status_data (struct usb_hcd *hc
buf [1] |= 1 (i - 7);
status = STS_PCD;
}
+
+ /*
+* The hub was supposed to disable port power autonomously
+* on over-current. However, not all hubs can be trusted to
+* do this although they need port power disabled in order
+* to recover properly.
+*/
+ if (temp PORT_OCC) {
+ if (HCS_PPC(ehci-hcs_params)){
+ temp = ~(PORT_RWC_BITS | PORT_POWER);
+ writel (temp, ehci-regs-port_status [i]);
+ }
+ }
+
}
/* FIXME autosuspend idle root hubs */
spin_unlock_irqrestore (ehci-lock, flags);
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Dealing with flaky USB storage devices and rootfs
On Tue, 29 May 2007, Dan Aloni wrote: Hello, We have a system where the rootfs is a partition on a USB device, and I've noticed upon a few rare cases where the USB controller loses the connection to the USB device after some uptime (days, weeks...), and the USB device reappears a very short time later. That failure mode is pretty uncommon. More often what happens is the connection remains intact but communication/protocol/firmware/??? errors cause the device to stop working. It never disappears but it can't be used again without unplugging or power-cycling. It doesn't really matter why, I guess that USB controllers and storage devices aren't always of the best quality - let's assume that. The issue is that Linux currently makes it problematic to recover the rootfs for several reasons. If /dev/sda1 is mounted as root and the SCSI device goes into offline mode, it is quite impossible to get out of this situation. At first, I had to disable the usermode helper that sends events to udev since it blocks on the dysfunction /dev/sda1. Afterwards, I noticed that the reappearing device is being assigned with /dev/sdb along with a new SCSI host. I guess the the VFS and block layer still keep a reference to the old scsi_disk and as a result sd doesn't free it. Yes. So, I gave some thoughts about this, I and came up with two main solutions: 1) Improve the USB storage error handling - bind the already existing SCSI host to the USB port that has the device, e.g., if host2 got created for usb 5-3 then keep it that way for the sake of EH. /dev/sda1 should come to life when the USB device recovers, unless a few seconds have passed or some attributes (such as manufactor id or serial) have changed. The difficulty here is that this error is indistinguishable from normal activity -- someone simply unplugs the device and then later on another connection is made. It might be the same device as before or it might be a different one. In other words, it isn't really an error. You would solve this by relying on a few seconds timeout. 2) Block layer hack - Write a special layering block device driver that acts as a proxy to the currently functioning /dev/sd* which gets auto-detected by this block layer driver. md multipath for the 'poor', you might say.. I chose '2' for the time being. It was much easier than hacking around the USB subsystem... Yes, I know rootfs on USB is an uncommon use-case at the moment but I do like to know if there are some improvements planned in this area. Interesting. I've been working on something very much like your 1) for some time. A version of it is now in the USB development tree. It's not meant for situations like the one you describe; instead it is intended for suspend-to-RAM or hibernation. Generally these processes involve loss of power on the USB bus, causing it to appear as though all the devices have been unplugged. In theory the same approach could be used to recover connections even in the absence of an intervening suspend. It would be clumsy in some respects, though. For instance, when a device actually was disconnected, the USB core wouldn't be able to notify the device's driver for a few seconds. In that time lots of unwanted activity and errors could mount up. It also goes against the USB specification. And it is potentially unsafe, in that it is possible for users to change media or make other alterations that the kernel cannot detect. The same would be true of your proposal, assuming that somebody was quick enough to unplug one device and plug in another (or swap memory cards) in the span of a few seconds. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] FW: You Need Money WeH ave Job
Hi Linux-usb-devel!. sehr geehrte Herr/ Frau! Mein Name ist Aleksandr Solomko, ich bin Geschaeftsfuerender Gesellschafte r (SoftJoin Co). Wir spezialisieren uns auf angewandte Entwicklung, Systemintegration, korporativen Netze und andere Software fuer verschiedenen Loesungen der Geschaefts - und Finanzproblemen. Meine Gesellschaft wurde in Ukraine gegruendet, und jetzt oeffnen wir eines neue Buero im Lettland. Wir haben mit vielen europaeschen und nordamerikanischen Gesellschaften im Softwarebereich zusammengearbeitet, Unsere nbs p;Gesellschaft hat einen gute Ruf. Leider haben wir einige Schwierigkeiten mit Zahlungserhalten fuer unseren Service. Gewoehnlich bekommen wir Ihre Zahlungen in 20-30 Tagen. Wir haben keine Zeit, um jede Postanweisung anzunehmen, auch koennen wir keine Bankschecks und Ueberweisungen annehmen. Deswegen suchen wir Partner in Ihrem Land, die uns helfenk oennen und diese Bezahlungen bearbeiten koennen. Wenn Sie einen gute Nebenverdienst suchen, koennen Sie unseren Vertreter in Ihrem Land werden. Als unsere Partner bek ommen Sie 8% von jede ausfuerenden Arbeit. Unsere Partner muessen Postanweisungen, Ueberweisungen und Banksscheks annehmen und diese uns schicken. Unseer Vertreter haben bequemen Arbeitsablauf-plan und einen gute Nebenverdienst. Wir planen auch eine Eroeffnung des Bueros in absehbarer Zukunft in Ihrem Land, und Sie haben einige Vorrechte, hauptamtliche Arbeit bekommen. Das muessen Sie entscheiden. Wir freuen uns, wenn Sies ich fuer unsere Business interessieren. Setzen Sie sich bitte in Verbindung mit mir fuer nbsp;zusaetzliche Information. mailto:[EMAIL PROTECTED] Senden Sie bitte folgende Information: 1.Vorname, Name ( fuer ihre Zusammenfassung ). 2.Bildung. 3.Ihre Adresse. 4.Kontaktstelefonnummer/ Fax. 5.Ihre Beschaeftigung momentan . 6.Alter. Antworten Sie bitte uns, und wir gweaehren zusaetzliche Einzelheiten und Information ueber unsere Gesellschaft und wie Sie unsere Vertreter sein koennen. Diese Eingliederung zu uns und zu unseres Business ist heutzutage kostenlos, aber Sie bekommen eine Moeglichkeit Geld zu verdienen. Rasch und muehelos! WennS ie verschiedenartige Fragen haben, sind Sie bitte nicht verlege n. Schreiben Sie uns, und wir antworten sehr gerne. Mit besten Gruessen! Hochachtungsvoll, Aleksandr Solomko. Tue, 29 May 2007 16:09:33 -0600 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Fix OTG HNP for hub.c (USB OTG HNP (can you find any other appropriate TLAs?)
* David Brownell [EMAIL PROTECTED] [070529 16:04]: On Tuesday 29 May 2007, Tony Lindgren wrote: snip snip snip snip - Enable HNP early (later would be OK too); - Offer to do HNP if the peripheral wants to use it Host doesn't know anything about peripheral wants; from its perspective, this is an blind offer to go down the peripheral #2 path. (Peripheral maintains _both_ b_hnp_enable set by a_host and user preference on b_device on using b_hnp_enable) That user preference is problematic. What do you end up with if that requirement for a user choice is removed ... ? How else do you tell when to use HNP then? It's the b-device that needs to have that configured in, and having HNP always enabled on b-device make sense either. I think it's designed to as a ways for b-device to request being a host, so it's not supposed to be automatic. If you want automatic host mode, then just use a-cable, right? Anyways, I'll play with an OPT and send patches in few weeks, no need to do anything meanwhile unless somebody else is also working on HNP stuff. ... deletia ... Glad to know the mechanisms are working. But right now I'm puzzled why musb_hdrc is misbehaving in host mode ... it's mangling descriptors as it reads them in. Which hardware? DaVinci or H4 with TUSB6010? At least on N800 the host mode can go through testusb -a. Tony - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Fix OTG HNP for hub.c (USB OTG HNP (can you find any other appropriate TLAs?)
On 5/30/07, Tony Lindgren [EMAIL PROTECTED] wrote: * David Brownell [EMAIL PROTECTED] [070529 16:04]: On Tuesday 29 May 2007, Tony Lindgren wrote: snip snip snip snip - Enable HNP early (later would be OK too); - Offer to do HNP if the peripheral wants to use it Host doesn't know anything about peripheral wants; from its perspective, this is an blind offer to go down the peripheral #2 path. (Peripheral maintains _both_ b_hnp_enable set by a_host and user preference on b_device on using b_hnp_enable) That user preference is problematic. What do you end up with if that requirement for a user choice is removed ... ? How else do you tell when to use HNP then? It's the b-device that needs to have that configured in, and having HNP always enabled on b-device make sense either. I think it's designed to as a ways for b-device to request being a host, so it's not supposed to be automatic. If you want automatic host mode, then just use a-cable, right? Yeah.. that's right... from my understanding it should be a user-request. The natural way for changing roles would be a cable switching... but we're lazy enough to do it.. so the the b-device requests (the user requests) to become host during a small time-slice... we know it will start and finish. Don't we? Anyways, I'll play with an OPT and send patches in few weeks, no need to do anything meanwhile unless somebody else is also working on HNP stuff. ... deletia ... Glad to know the mechanisms are working. But right now I'm puzzled why musb_hdrc is misbehaving in host mode ... it's mangling descriptors as it reads them in. Which hardware? DaVinci or H4 with TUSB6010? At least on N800 the host mode can go through testusb -a. Tony -- Best Regards, Felipe Balbi [EMAIL PROTECTED] - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Fix OTG HNP for hub.c (USB OTG HNP (can you find any other appropriate TLAs?)
On Tuesday 29 May 2007, Tony Lindgren wrote:
* David Brownell [EMAIL PROTECTED] [070529 12:18]:
On Friday 25 May 2007, Tony Lindgren wrote:
+
So it'd be best to see a minimal patch just fixing any bugs...
Those substantive changes unfortunately include inserting
bugs ... which would have been easier to see if they were
not interspersed with cleanups!
Yes, I tried, but the nesting was getting too deep :)
Even so. Been there, done that ... in this case, changing
two things at once was not a win. :)
+ /* If B-device wants to do HNP, it will do it after we suspend */
+ if (bus-b_hnp_enable) {
+ dev_err(udev-dev, trying HNP, suspending bus\n);
+ err = __usb_port_suspend(udev, udev-bus-otg_port);
No, it shouldn't suspend at this point. If the device is in
the targeted peripherals list, the host must continue to try
using the device ... using the normal code paths.
Here, you've changed it to immediately try HNP, even when
the host wants to handle the targeted device (that is, when
A_BUS_REQ is true).
Hmm, in the USB_OTG_1-3.pdf it says the host must offer HNP to
peripherals that support HNP during the session. In my patch
we offer it right away if the peripheral wants to use it.
Quoting few sentences from USB_OTG_1-3.pdf 6.4.1.4 a_host:
If the SetFeature(b_hnp_enable) command is sent and accepted
during the session, then the A-device shall exit to the a_suspend
state and wait for the B-device to start a session (See Section 6.5.2)
So the way I understand sent and accepted above, it's up to the
b_device to use or not use the HNP session offered.
Right, but as I pointed out elsewhere: that applies to the exit
path. What you did here was remove the startup path, by
completely eliminating the essential let the host actually
use the peripheral first logic ... before hitting the exit path.
+ if (err 0) {
+ dev_err(udev-dev, suspend for HNP failed\n);
+ return -ENODEV;
+ }
+
+ /* TB_ASE0_BRST, minimum 3.125 ms */
+ mdelay(4);
The assumption was that lower level code would manage
T(A/SE0 -- B/RST) as part of triggering HNP in the root
hub ... the root hub can always tell if it's triggering
HNP, so that timeout applies. Since that timeout tends
to have hardware support, I'd rather not see it here.
Sorry, I don't understand how you prefer the 3.125 ms
timeout handled, can you please clarify? Just leave it out?
Leave it out here. Any HNP-aware root hub can msleep
if necessary ... that's often handled by the hardware.
This modified code sequence skips that primary usage:
the peripheral can't be used as a peripheral, since
it immediately jumps into host mode.
Yes, but as I understand it's up to the peripheral to use
the HNP or not when offered. So unless b_host is enabled
on peripheral, HNP does not get used.
The current Linux-USB OTG support expects to always take
advantage of HNP if it's offered, even if just to check
whether there is anything the B-default device should do
in host mode.
I see your point though with autoidle, but that's after
the devices have enumerated the wrong way, right?
You want me to look at that code again? Aargh!
Originally there was no autoidle, so the logic was:
the only way Linux will *EVER* trigger suspend at
runtime was to try HNP. Devices that don't pass the
whitelist test would enumerate no further.
Now we have working auto-idle, so other logic could
be applied. I think you're suggesting that maybe
they could proceed through enumeration, fail that,
and then autosuspend to trigger HNP ... ? That might
be workable.
The behavioral difference would be that WHEN (not 'IF')
the whitelist (which is very easily checked against product
documentation) diverges from the list of configured drivers
(no easy way to crosscheck that and docs) things would not
act the same.
If on
the b_device user selects b_host mode, it can start
right away when the devices are connected.
I don't know about this user selects B_HOST mode step.
Previously such a step did not exist. The goal was to
require as little user interface support as possible.
Maybe we should offer HNP early and every autoidle?
I'm a minimalist here ... unless someone has a new use
case for HNP, avoid kicking it in. Most folk feel it's
a bit of a solution in search of problem, other than the
very basic hooked cable up the wrong way scenario.
Of course, an updated N800 with full OTG support sure
ought to be able to trigger some creativity in that
area ... :)
We may need to avoid kicking in HNP on autoidle, since
that seems to imply a disconnect of that session. But
that boils down to: either HNP at the start, for a
device that's not whitelisted ... or HNP way later.
A single do HNP now routine would be useful; it
could be used in any of those scenarios.
Re: [linux-usb-devel] [PATCH] Fix OTG HNP for hub.c (USB OTG HNP (can you find any other appropriate TLAs?)
* David Brownell [EMAIL PROTECTED] [070529 16:04]: On Tuesday 29 May 2007, Tony Lindgren wrote: I see your point though with autoidle, but that's after the devices have enumerated the wrong way, right? You want me to look at that code again? Aargh! Originally there was no autoidle, so the logic was: the only way Linux will *EVER* trigger suspend at runtime was to try HNP. Devices that don't pass the whitelist test would enumerate no further. Now we have working auto-idle, so other logic could be applied. I think you're suggesting that maybe they could proceed through enumeration, fail that, and then autosuspend to trigger HNP ... ? That might be workable. Sorry, in my snip frenzy I forgot to reply to some parts:) Yes, well I'll see what happens with OPT and post some results. The behavioral difference would be that WHEN (not 'IF') the whitelist (which is very easily checked against product documentation) diverges from the list of configured drivers (no easy way to crosscheck that and docs) things would not act the same. I guess HNP should be offered for peripherals even if not on whitelist, but only peripherals on whitelist (with HNP or not) should be allowed. This is more or less what you were trying to achieve, yes? But it leads to surprising behavior in cases like: * hook up non-OTG peripheral #1 ... acts just the way you'd normally expect * hook up OTG peripheral #2 ... surprise! it refuses to act as a peripheral at first. The principle of least astonishment argues that the peripheral #1 model should be followed for as long as possible. Customer service calls would be a lot simpler too... Yeh I guess in that case it needs to wait for autosuspend until #1 is done. But if #2 is not on whitelist and can do HNP, then it just gets rejected and never gets it's HNP opportunity. Hmmm... Tony - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Fix OTG HNP for hub.c (USB OTG HNP (can you find any other appropriate TLAs?)
snip The behavioral difference would be that WHEN (not 'IF') the whitelist (which is very easily checked against product documentation) diverges from the list of configured drivers (no easy way to crosscheck that and docs) things would not act the same. I guess HNP should be offered for peripherals even if not on whitelist, but only peripherals on whitelist (with HNP or not) should be allowed. Or maybe we run a set_feature (b_hnp_enabled) just before the suspend... can we do that dave?? It doesn't seem really correct when typing... but... If I'm not wrong... every device can accept a b_hnp_enable set_feature command... if the controller doesn't support it just return a stall.. or something like that... so... we could just forget about the whitelist for now.. can't we? If the device supports HNP it will get the b_hnp_enable command and after a_host enters in suspend mode... it will try to do HNP (if the user wants...) This is more or less what you were trying to achieve, yes? But it leads to surprising behavior in cases like: * hook up non-OTG peripheral #1 ... acts just the way you'd normally expect * hook up OTG peripheral #2 ... surprise! it refuses to act as a peripheral at first. The principle of least astonishment argues that the peripheral #1 model should be followed for as long as possible. Customer service calls would be a lot simpler too... Yeh I guess in that case it needs to wait for autosuspend until #1 is done. But if #2 is not on whitelist and can do HNP, then it just gets rejected and never gets it's HNP opportunity. Hmmm... Tony -- Best Regards, Felipe Balbi [EMAIL PROTECTED] - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Fix OTG HNP for hub.c (USB OTG HNP (can you find any other appropriate TLAs?)
* Felipe Balbi [EMAIL PROTECTED] [070529 16:34]: snip The behavioral difference would be that WHEN (not 'IF') the whitelist (which is very easily checked against product documentation) diverges from the list of configured drivers (no easy way to crosscheck that and docs) things would not act the same. I guess HNP should be offered for peripherals even if not on whitelist, but only peripherals on whitelist (with HNP or not) should be allowed. Or maybe we run a set_feature (b_hnp_enabled) just before the suspend... can we do that dave?? It doesn't seem really correct when typing... but... If I'm not wrong... every device can accept a b_hnp_enable set_feature command... if the controller doesn't support it just return a stall.. or something like that... so... we could just forget about the whitelist for now.. can't we? If the device supports HNP it will get the b_hnp_enable command and after a_host enters in suspend mode... it will try to do HNP (if the user wants...) AFAIK, all OTG devices need to support b_hnp_enable, but it's just a way to tell it that host supports HNP, it does not mean HNP should enabled. Enabling HNP should be done by the user on the b-device. This is more or less what you were trying to achieve, yes? But it leads to surprising behavior in cases like: * hook up non-OTG peripheral #1 ... acts just the way you'd normally expect * hook up OTG peripheral #2 ... surprise! it refuses to act as a peripheral at first. The principle of least astonishment argues that the peripheral #1 model should be followed for as long as possible. Customer service calls would be a lot simpler too... Yeh I guess in that case it needs to wait for autosuspend until #1 is done. But if #2 is not on whitelist and can do HNP, then it just gets rejected and never gets it's HNP opportunity. Hmmm... I guess the non-whitelisted b-device should sit waiting for HNP mode start when the host autosuspend suspends the bus? Tony - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Dealing with flaky USB storage devices and rootfs
On Tue, May 29, 2007 at 05:50:49PM -0400, Alan Stern wrote: On Tue, 29 May 2007, Dan Aloni wrote: Hello, We have a system where the rootfs is a partition on a USB device, and I've noticed upon a few rare cases where the USB controller loses the connection to the USB device after some uptime (days, weeks...), and the USB device reappears a very short time later. That failure mode is pretty uncommon. More often what happens is the connection remains intact but communication/protocol/firmware/??? errors cause the device to stop working. It never disappears but it can't be used again without unplugging or power-cycling. Yes this is also what I assume happening. i.e. more likely a USB flash disk firmware bug than a controller bug (there are lots of crappy USB flash drives out there). So, I gave some thoughts about this, I and came up with two main solutions: 1) Improve the USB storage error handling - bind the already existing SCSI host to the USB port that has the device, e.g., if host2 got created for usb 5-3 then keep it that way for the sake of EH. /dev/sda1 should come to life when the USB device recovers, unless a few seconds have passed or some attributes (such as manufactor id or serial) have changed. The difficulty here is that this error is indistinguishable from normal activity -- someone simply unplugs the device and then later on another connection is made. It might be the same device as before or it might be a different one. In other words, it isn't really an error. You would solve this by relying on a few seconds timeout. [...] It also goes against the USB specification. And it is potentially unsafe, in that it is possible for users to change media or make other alterations that the kernel cannot detect. The same would be true of your proposal, assuming that somebody was quick enough to unplug one device and plug in another (or swap memory cards) in the span of a few seconds. The specific use case I refer to is with a flash drive embedded inside a locked and closed chassis of a dedicated server. So, anyone repluging it must know what they are doing anyway. -- Dan Aloni XIV LTD, http://www.xivstorage.com da-x (at) monatomic.org, dan (at) xiv.co.il - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Fix OTG HNP for hub.c (USB OTG HNP, ... other TLAs?)
On Tuesday 29 May 2007, Tony Lindgren wrote: (Peripheral maintains _both_ b_hnp_enable set by a_host and user preference on b_device on using b_hnp_enable) That user preference is problematic. What do you end up with if that requirement for a user choice is removed ... ? How else do you tell when to use HNP then? It's the b-device that needs to have that configured in, and having HNP always enabled on b-device make sense either. I don't see why it wouldn't. In fact, I what's always puzzled me is the notion of HNP under program control. (And it's puzzled most everyone else I've asked about it too. At this year's embedded systems conference the show floor had a lot more people who actually knew OTG ... a first. But nobody had a better use case for HNP than fixing the hook cable up wrong scenario.) Think of it this way: USB has had a *LOT* of effort put into its design to avoid the need for user error. Cables are keyed so there's no way to insert them the wrong way. Autoconfiguration. (A notion that Microsoft abhors, but that's their bug ... they want people to ship driver disks.) Power is delivered over the bus, so it's routine not to need a power brick (or batteries). And more. One of the basic design constraints of OTG is no silent errors; one part of that is exposing diagnostics, but another is minimizing even the potential for errors which need for them. Question: where would *needing* any user choice for HNP enter that picture? Answer: It doesn't. The *primary* purpose of HNP is to cope with a potential error: user connected the wrong end of an OTG cable into a device, for the particular task they intended to perform. Example: a handheld device knows how to print (as host), but the printer only knows how to grab pictures from a camera ... but the user hooked them up wrong (printer is host), HNP fixes that error up pronto, handheld device can print as expected once it assumest that host role. I think it's designed to as a ways for b-device to request being a host, so it's not supposed to be automatic. If you want automatic host mode, then just use a-cable, right? And *WHEN* you hook up the other way around (maybe one end of your OTG cable was already hooked up), it should still work painlessly ... without the end user needing to care. Without needing to eyeball the connector to try and figure out which end is which. (I suspect a lot of OTG cables consist of MiniA adapters and standard A-to-MiniB cables, which will make it easier.) Remember that with OTG, end users aren't necessarily going to be aware of host vs peripheral. They'll just hook up an OTG cable the usual way -- whatever works! Then they'll expect their documents to start printing, or whatever. Anyways, I'll play with an OPT and send patches in few weeks, no need to do anything meanwhile unless somebody else is also working on HNP stuff. ... deletia ... Glad to know the mechanisms are working. But right now I'm puzzled why musb_hdrc is misbehaving in host mode ... it's mangling descriptors as it reads them in. Which hardware? DaVinci or H4 with TUSB6010? At least on N800 the host mode can go through testusb -a. H4/TUSB. I've not fired up DaVinci in a while. - Dave Tony - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Fix OTG HNP for hub.c (USB OTG HNP and other TLAs?)
On Tuesday 29 May 2007, Tony Lindgren wrote: * Felipe Balbi [EMAIL PROTECTED] [070529 16:34]: snip The behavioral difference would be that WHEN (not 'IF') the whitelist (which is very easily checked against product documentation) diverges from the list of configured drivers (no easy way to crosscheck that and docs) things would not act the same. I guess HNP should be offered for peripherals even if not on whitelist, but only peripherals on whitelist (with HNP or not) should be allowed. Yes. The original HNP logic in Linux was structured to work just that way ... ISTR the original OTG spec was not as clear as it should have been on when to HNP. The logic is: If device is on whitelist, anything goes: normal connection, or (later) HNP. Otherwise, normal connection *must* never happen. But we might be on that device's whitelist, so try HNP. Or maybe we run a set_feature (b_hnp_enabled) just before the suspend... can we do that dave?? It doesn't seem really correct when typing... but... Yes, that can work. That's the original path for blacklisted devices, in fact... If I'm not wrong... every device can accept a b_hnp_enable set_feature command... if the controller doesn't support it just return a stall.. or something like that... so... we could just forget about the whitelist for now.. can't we? If the device supports HNP it will get the b_hnp_enable command and after a_host enters in suspend mode... it will try to do HNP (if the user wants...) AFAIK, all OTG devices need to support b_hnp_enable, but it's just a way to tell it that host supports HNP, it does not mean HNP should enabled. Keep the terminology straight please. Yes, OTG devices will by definition support HNP and thus B_HNP_ENABLE. So they can always have HNP enabled, but setting it up so it's not used isn't the same thing ... Enabling HNP should be done by the user on the b-device. No. By definition B_HNP_ENABLE is set by the host. The peripheral option is the B_BUS_REQ (see otg 1.2 spec, section 6.6.1.9). If that's false, HNP won't be used. Conceptually, everything's a lot simpler if that's always treated as true. And the gadget stack doesn't have any interface to request that it be anything else... I happen to have a hard time thinking about why it should ever be anything else ... Linux won't _know_ if it has any work for that particular device until it knows what's hooked up, and it can't know that until HNP kicks in and then the B_HOST can tell what's there. It's a printer, and I have print jobs queued ... great!; or It's a disk drive, let the user see if they want to copy files; or darn, I need to print these pictures in color but that printer is b/w; too bad, disconnect/die. This is more or less what you were trying to achieve, yes? But it leads to surprising behavior in cases like: * hook up non-OTG peripheral #1 ... acts just the way you'd normally expect * hook up OTG peripheral #2 ... surprise! it refuses to act as a peripheral at first. The principle of least astonishment argues that the peripheral #1 model should be followed for as long as possible. Customer service calls would be a lot simpler too... Yeh I guess in that case it needs to wait for autosuspend until #1 is done. But if #2 is not on whitelist and can do HNP, then it just gets rejected and never gets it's HNP opportunity. Hmmm... I guess the non-whitelisted b-device should sit waiting for HNP mode start when the host autosuspend suspends the bus? For simplicity, treat non-whitelist as blacklisted... easier to think that way. Then: however it's done, the blacklisted device isn't going to know it's blacklisted except by inference: if it never gets a SET_CONFIGURATION, and only gets a chance to HNP, it was probably blacklisted. (Not that it has any reason to care about that.) I'd prefer to just keep the existing logic: if it's blacklisted, dive immediately into HNP and don't let enumeration go any further. As I said earlier, any other course is error prone ... because the official list can disagree with the list of drivers that have been configured. - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
