[linux-usb-devel] $BNY$N!{!{$G$9!!!(B
$Bv!!yL5NAEPO?%-%c%s%Z!%sCf!y!v(B $B!!$d$C$Q$j=P0)$$J$i$46a=j$G2q$($kAjj$,$$$k$H(B [EMAIL PROTECTED](B(^$B(B^*)$B!?%o!A%$$G$9%M%'!A(B $B!!Ev%5%$%H$OA49qCO0hJL$N;TD.BC10L$G6a$/$NM'C#C5$7$,$G$-$^$9!#(B $B(Bhttp://www.jumpb2.net/?imasugu $B!!%3%3$K%%I8x3+$GBT$C$F$$$k$46a=jL$,$$$C$Q$$(B(o^$BO(B^o)[EMAIL PROTECTED]!(B $BEPO?8e(B5$BJ,0JFb$K$46a=j$G2q$([EMAIL PROTECTED]R2pCW$7$^$9!#(B $B$^$:$O$*;n$7L5NAEPO?$+$i(B $B!!--(B $B(Bhttp://www.jumpb2.net/?imasugu $B(B $B!!(B $B%U%j!%a!%kBP1~$G$9!*(B $B5qH](B [EMAIL PROTECTED] --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ 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] laptop sleep on iBook G4 panics ehci_hcd in 2.6.12-rc4 with hub attached
On Sun, 2005-05-08 at 13:13 -0700, David Brownell wrote: On Sunday 08 May 2005 5:26 am, John Steele Scott wrote: Hi, Today I tried kernel 2.6.12-rc4 on my iBook G4 to check whether sleep works properly yet. I found that it panics if my USB hub is attached to the iBook when I try to sleep the machine. ... I took a photo of the panic and enhanced it for readability, it's at http://www.toojays.net/portal/Members/toojays/ibook-g4-sleep-crash-2.6.12-rc4.jpg. Hmm, curious. Looks like the watchdog timer isn't getting stopped; I'm surprised nobody else has ever noticed that one! See if this patch solves the problem for you. Just to follow up on this, I just recently had the following oops: Oops: kernel access of bad area, sig: 11 [#1] NIP: DA50DEE8 LR: DA4A2498 SP: D3173D90 REGS: d3173ce0 TRAP: 0300Not tainted MSR: 0200b032 EE: 1 PR: 0 FP: 1 ME: 1 IR/DR: 11 DAR: 18A8, DSISR: 4000 TASK = d7ae4110[4325] 'pbbuttonsd' THREAD: d3172000 Last syscall: 54 GPR00: D3173D90 D7AE4110 0010 0001 C0330F4C C0330DDC GPR08: DA518850 D54216D8 28000482 10026C18 100C 100A GPR16: 100D7408 28222482 100C 100D6F28 100D6AE8 10001180 1000BF7C GPR24: C02B C02DAF5C C02E C02E C02DAF54 D5421768 C02B5648 D54216D8 NIP [da50dee8] hid_resume+0x20/0x48 [usbhid] LR [da4a2498] usb_generic_resume+0x78/0x88 [usbcore] Call trace: [da4a2498] usb_generic_resume+0x78/0x88 [usbcore] [c0173230] resume_device+0x44/0x4c [c0173368] dpm_resume+0x130/0x148 [c01733b8] device_resume+0x38/0x78 [c031214c] pmac_wakeup_devices+0xc0/0xe0 [c0312648] powerbook_sleep_Core99+0x224/0x2bc [c0312e78] pmu_ioctl+0xfc/0x300 [c0077c58] do_ioctl+0x68/0x8c [c0077ea8] vfs_ioctl+0x88/0x2a8 [c007810c] sys_ioctl+0x44/0x78 [c0004660] ret_from_syscall+0x0/0x44 I've had it twice, but am not quite sure how to reproduce it. I thought it was to do with my hub being powered-off while my laptop wakes up, but have tried various combinations of plugging and switching things, and I can't get the oops to happen again. The oops happened during wakeup. Whatever it did to the wakeup process stopped the terminal from switching back to Xorg. I was able to ssh into the machine and restart X, but when X came back, the keyboard wouldn't function, although the trackball which was plugged into the hub did work (I forgot to try the laptop trackpad). cheers, John signature.asc Description: This is a digitally signed message part
Re: [linux-usb-devel] gadget hotplug
David Brownell wrote:
On Friday 06 May 2005 9:15 pm, mike lee wrote:
David Brownell wrote:
On Wednesday 04 May 2005 7:34 pm, mike lee wrote:
I just finish my draft version gadget controller driver on imx
platform,
Great! If that'll be generally available, I'll mention i.MX on
the webpage.
It still need to debug more, and only support PIO control and bulk.
Int endpoint is now under debug.
Bulk and interrupt can be identical ... though maybe the hardware
cuts some corners on interrupt endpoints, like limiting FIFO size
and not supporting double buffering. DMA should be a big win on
something like an i.MX though.
yes, i am working hard on the dma part.
Also i found that there is a bcddevice no in all gadget drivers. Do
i need to register officially?
That is, to fit into blocks of code like:
} else if (gadget_is_omap (gadget)) {
device_desc.bcdDevice = __constant_cpu_to_le16 (0x0208);
} else if (gadget_is_lh7a40x(gadget)) {
device_desc.bcdDevice = __constant_cpu_to_le16 (0x0209);
...
} else if (gadget_is_at91(gadget)) {
device_desc.bcdDevice = __constant_cpu_to_le16 (0x0213);
Why don't you use 0x214, and send me the patch for gadget.h and all
the gadget drivers. You can do that before you post the driver, and
having that stuff merged now will simplify things later.
(Those blocks of code have two purposes. One is that sometimes they
need to do chip-specific things, usually to cope with chips trying
to dictate things like endpoint or altsetting numbers, or to handle
limitations in endpoint type or number. The other is so that the
host side has a hook to do similar things.)
Actually, i have taken bcddevice 0x212 which doesn't obtain by
anyone in kernel 2.6.10. May be i change to use 0x214,
I will send you the patch later.
but how can i benefit from the hotplug function provided from
kernel? Do i need to provide the hotplug function in my driver, and
example for hotplugging gadget?
The gadget framework itself doesn't currently use hotplug for anything,
though of course layers above it can certainly do so. There's been no
reported need for hot reconfiguration.
What were you thinking hotplug should do?
Actually, upgrading the firmware and backup storage functions are
the main purposes to use usb. My idea to upgrading firmware is that
firmware download thought backup storage gadget and when the cable
unplug or press a key, a daemon copy the file to my flash.
It might be better to look at using the DFU class spec; that's something
that can reasonably be done with a simple gadgetfs driver writing to
the relevant /dev/mtd/N partition for the kernel, rootfs, or whatever.
Of course the really tricky bit about firmare updates is that you need
to have some way to prevent bricking your device ... end users are
not going to have JTAG access to reprogram things in case the write to
that MTD partition breaks, and turns the device (cell phone or whatever)
into a brick.
I don't know DFU class before, but is there any standard driver in
window? Frankly speaking, it is important for common users. Also, i
trend to use button/led solution, DFU class should be the next phase.
So, i wanna know if there is a method or example on how to signal
hotplugging to the daemon
You can just call_usermodehelper() directly if you really want that,
but it doesn't seem to me like hotplug is a good match for what you've
described. In particular, unplugging a cable can happen at any time;
it shouldn't be treated the same as an affirmative user direction
that it's now _safe_ to do something potentially dangerups.
- Dave
I do have many questions on gadget subsystem. May be i start another
post.
Thanks for your helps ,Dave.
best regard
Mike,Lee
---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
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] Urgent help for handling USB OHCI related IRQs without effect at Interrupt control register masking
Hi everyone, After tuning up the irq probing approach of the kernel for ms7751rcp01 board. I am able to use USB gadgets and mass storage using imask irq model. I am trying to develop custom irq model (which doesnt modify CPU register like it is done in imask model), and many of the devices like UART/Touchscreen of this board are working fine with this approach. The only problem is related to USB ohci controller irqs. With the custom irq handling model, kernel is able to grab the IRQ no, but the action is not being performed. I need to tweak IRQ disable/enable logic, want to make it on device (ie. host controller) side. Is there any trick, which can be played to achieve following goals!? a) Notify the OHCI tree routines that IRQ has occured from USB device. b) Enabling/Disabling stays either mock or happens on device level, so kernel does'nt touch interrupt control register of SH 7751R registers. P.S.: I tried things with MIE of NEC usb. but it didnt work. Thanks in advance, Lara --- [EMAIL PROTECTED] wrote: Send linux-usb-devel mailing list submissions to linux-usb-devel@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/linux-usb-devel or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of linux-usb-devel digest... Today's Topics: 1. Re: [PATCH] USB: Spelling fixes for drivers/usb. (Steven Cole) --__--__-- Message: 1 From: Steven Cole [EMAIL PROTECTED] To: David Brownell [EMAIL PROTECTED] Subject: Re: [linux-usb-devel] [PATCH] USB: Spelling fixes for drivers/usb. Date: Fri, 6 May 2005 20:26:00 -0600 Cc: linux-usb-devel@lists.sourceforge.net, Greg K-H [EMAIL PROTECTED] On Friday 06 May 2005 09:21 am, David Brownell wrote: On Wednesday 04 May 2005 12:44 am, Greg KH wrote: [PATCH] USB: Spelling fixes for drivers/usb. Here are some spelling corrections for drivers/usb. cancelation - cancellation For the record, cancelation (one l not two ll) is correct, though recently I've found some dictionaries listing cancellation (two ll) as an option. - Dave If anyone feels strongly about a particular word pair, I can delete that pair from my correction list. I have checked all the good spellings vs the bad spellings using gnu aspell, and blushMS Word/blush. Some of the scripts I use are located here: http://www.kegel.com/kerspell/ I have an expanded spell-fix.txt which I'm using, but I don't have it available this weekend. Steven --__--__-- ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel End of linux-usb-devel Digest __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ 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] [2.6.12-rc4] network wlan connection goes down
Hi, I upgraded to 2.6.12-rc4, and noticed something strange after that. After a few hours, the network connection goes down. The network connectivity is done via a USB wifi stick driven by zd1201. After that, nothing gets through, not even a ping. ifconfig wlan0 shows the interface UP and configured; iwconfig shows the Wifi is correctly associated with the access point (and the access point's client list shows the zd1201's MAC as associated). The LED on the stick is lit as usual (when associated). The kernel log doesn't show anything useful. The connection comes back when running my network configuration script again. The script issues four commands: iwconfig wlan0 essid foo channel 11 key xx:xx...:xx ifconfig wlan0 192.168.0.11 route del default route add default gw 192.168.0.100 (I have to find out which of the four commands reenables the connection, didn't try yet) Everything was fine using 2.6.12-rc3; the only zd1201 patch that went in 2.6.12-rc4 is USB: drivers/usb/net/zd1201.c: make some code static by Adrian Bunk, which I think can't be harmful at all. Would anyone have any hint about what could have changed in the usb subsystem (ohci driver) or in the network subsystem, that might cause that? Thanks, -- Colin --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ 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.12-rc4] network wlan connection goes down
On Monday 09 May 2005 7:24 am, Colin Leroy wrote: Hi, I upgraded to 2.6.12-rc4, and noticed something strange after that. After a few hours, the network connection goes down. The network connectivity is done via a USB wifi stick driven by zd1201. After that, nothing gets through, not even a ping. ... Would anyone have any hint about what could have changed in the usb subsystem (ohci driver) or in the network subsystem, that might cause that? The OHCI code shouldn't have changed either, unless you're maybe using an old Compaq-brand chipset. However, if you enable CONFIG_USB_DEBUG and send the async and registers files from the relevant /sys/class/usb_host/usbN directory, it should be easy to tell whether there's an issue at that particular level. - Dave --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ 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] OHCI and suspend/resume problems
On Sunday 08 May 2005 7:29 pm, Alan Stern wrote: On Sun, 8 May 2005, David Brownell wrote: Oh, it's definitely INTR_RD. This happens when I have explicitly suspended the root hub via sysfs but left the controller running, and then plug/unplug a device. So it's yet another case where the /sys/.../power/state attributes facilitate breaking things... :) No other IRQ makes sense. Try the attached patch, on the theory that the problem is INTR_RD. (If this is really the issue, then I'm surprised it's not appeared before.) Your patch solves the hang-up problem. Maybe the issue hasn't appeared before because no one has tried using sysfs to suspend the root hub and not the controller. The code still isn't quite right because the root hub doesn't automatically resume. I haven't tried to track down the reason, but maybe replacing the schedule_work() call with usb_hcd_resume_root_hub() would help. (That replacement should be made in any case.) And that might also explain part of why I've never seen this. Last time I tested this stuff out, there was no such usb_hcd_*() call .. I suspect adding it changed a few assumptions. - Dave --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ 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] USB: Spelling fixes for drivers/usb.
On Sun, May 08, 2005 at 10:25:24PM -0500, Dmitry Torokhov wrote: AFAIK cancelled is British English while canceled is American. FWIW (not much), I'm American, and canceled looks very wrong to me. -- Glenn Maynard --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ 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] OHCI and suspend/resume problems
On Mon, 9 May 2005, David Brownell wrote: So it's yet another case where the /sys/.../power/state attributes facilitate breaking things... :) I prefer to think of it as a case where the debugging advantages of those attributes have helped turn up a mistake in a driver. :-) The code still isn't quite right because the root hub doesn't automatically resume. I haven't tried to track down the reason, but maybe replacing the schedule_work() call with usb_hcd_resume_root_hub() would help. (That replacement should be made in any case.) And that might also explain part of why I've never seen this. Last time I tested this stuff out, there was no such usb_hcd_*() call .. I suspect adding it changed a few assumptions. No, the usb_hcd_* stuff is completely unrelated to the original problem of that INTR_RD hanging the system. And adding it didn't change any assumptions -- it was a very simple addition of the what you don't know won't hurt you sort. (Basically just a new flag plus a routine to set it and some code to make khubd resume the root hub when the flag was set; if a driver ignored the flag then nothing unexpected would happen.) Alan Stern --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ 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] USB: Spelling fixes for drivers/usb.
On Monday 09 May 2005 22:13, Glenn Maynard wrote: On Sun, May 08, 2005 at 10:25:24PM -0500, Dmitry Torokhov wrote: AFAIK cancelled is British English while canceled is American. FWIW (not much), I'm American, and canceled looks very wrong to me. FWIW (even less), I'm Danish, and canceled looks very wrong to me too. -- Regards, Christian Iversen pgpEvRqsB7D9z.pgp Description: PGP signature
[linux-usb-devel] HID-compliant mouse detected as joystick
Hey all- I've tried asking around for help, but maybe I haven't been doing it in the right place. I'm really stuck and could use a hand! I have a USB touchscreen (by Nextwindow) which I'm trying to get to work with Linux. Plugged in under Windows it gets detected as a HID- compliant mouse and works without any special drivers. Plugged in under Linux, three device entries are created under /sys/bus/usb/devices, one for the Mouse, one for Comms and one for Keyboard - so it appears as a multi-device adapter. I'm only interested in mouse functionality. I'm trying to understand how this all hangs together, any help would be appreciated. OS: Fedore Core 3 Kernel: kernel2.6.10-1.770_14.rhfc3.at (ATrpms patches to stock FC3 kernel) Four udev devices are created when I plug in the device: Mouse: /dev/input/event2 /dev/input/js0 Keyboard: /dev/usbhid0 /dev/input/event3 Comparing to when I plug in a USB microsoft intellimouse, I get two devices: /dev/input/mouse0 /dev/input/event4 Now if I try to read the raw device output via gpm (using the event device created for the microsoft mouse): #gpm -D -m /dev/input/event4 -Rraw I get: *** info [startup.c(95)]: Started gpm successfully. Entered daemon mode. *** debug [console.c(125)]: Screen size: 80 - 25 *** debug [gpm.c(159)]: x 10, y 20 ...to standard out which stays like that until I move the mouse. Once I move the mouse I endlessly get: *** err [gpm.c(89)]: Error in read()ing first: No such file or directory *** debug [gpm.c(533)]: selected 1 times ...to standard error. The *identical* thing happens if I try to read the raw output from the event device created by the touchscreen: # gpm -D -m /dev/input/event2 -Rraw ...with the looping error messages not appearing until I touch the screen somewhere. So there's definitely a form of interaction going on. It seems that Linux is creating a /dev/input/js0 (joystick) device for the mouse portion of the touchscreen, instead of creating /dev/input/mouse0 like it knows to do with the Intellimouse. I can't get any useful feedback from trying to directly talk to the js0 device, even using the joystick mouse setting under gpm. Surely its a matter of telling hotplug's input.agent (or similar) to recognize the screen as a mouse instead of a joystick? Is the correct file to modify: /lib/modules/kernel version/modules.inputmap (?) and if so is there a reference for how to determine the correct values? Thanks heaps for any help! Steve Castellotti PS: Technical details USB Chipset (lspci -v): 00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) (prog-if 00 [UHCI]) Subsystem: Dell: Unknown device 0160 Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at ff80 [size=32] 00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) (prog-if 00 [UHCI]) Subsystem: Dell: Unknown device 0160 Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at ff60 [size=32] -- Diff to /proc/bus/usb/devices after device insertion: B: Alloc=110/900 us (12%), #Int= 2, #Iso= 0 T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 11 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor= ProdID= Rev= 1.00 S: Manufacturer=Nextwindow S: Product=Nextwindow Touchscreen C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=02 Driver=usbhid E: Ad=81(I) Atr=03(Int.) MxPS= 5 Ivl=10ms I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid E: Ad=82(I) Atr=03(Int.) MxPS= 64 Ivl=10ms I: If#= 2 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=01 Driver=usbhid E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=10ms --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click ___ 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] OHCI and suspend/resume problems
On Monday 09 May 2005 2:22 pm, Alan Stern wrote:
The code still isn't quite right because the root hub doesn't
automatically resume. I haven't tried to track down the reason, but maybe
replacing the schedule_work() call with usb_hcd_resume_root_hub() would
help. (That replacement should be made in any case.)
I was just looking at that in conjunction with a different issue,
and I noticed a glitch: it's conditionalized for USB_SUSPEND
(which implies PM) not just PM, but autosuspend kicks in with PM.
This patch does that conversion, and it also has the other tweak.
Worked for me ... you?
- Dave
This updates OHCI to use the new usbcore resume_root_hub() mechanism,
and fixes that mechanism so it's available with CONFIG_PM. It also
continues getting rid of some #ifdefs of the form (PM || USB_SUSPEND);
they're superfluous: USB_SUSPEND is a strict superset of PM.
Signed-off-by: David Brownell [EMAIL PROTECTED]
--- g26.orig/drivers/usb/core/hcd.c 2005-05-09 18:17:30.0 -0700
+++ g26/drivers/usb/core/hcd.c 2005-05-09 18:18:56.0 -0700
@@ -1420,7 +1420,7 @@
/*-*/
-#ifdef CONFIG_USB_SUSPEND
+#ifdef CONFIG_PM
static int hcd_hub_suspend (struct usb_bus *bus)
{
@@ -1460,13 +1460,9 @@
usb_resume_root_hub (hcd-self.root_hub);
spin_unlock_irqrestore (hcd_root_hub_lock, flags);
}
+EXPORT_SYMBOL_GPL(usb_hcd_resume_root_hub);
-#else
-void usb_hcd_resume_root_hub (struct usb_hcd *hcd)
-{
-}
#endif
-EXPORT_SYMBOL_GPL(usb_hcd_resume_root_hub);
/*-*/
@@ -1519,7 +1515,7 @@
.buffer_alloc = hcd_buffer_alloc,
.buffer_free = hcd_buffer_free,
.disable = hcd_endpoint_disable,
-#ifdef CONFIG_USB_SUSPEND
+#ifdef CONFIG_PM
.hub_suspend = hcd_hub_suspend,
.hub_resume = hcd_hub_resume,
#endif
--- g26.orig/drivers/usb/host/ohci-hub.c 2005-05-09 18:17:30.0 -0700
+++ g26/drivers/usb/host/ohci-hub.c 2005-05-09 18:18:56.0 -0700
@@ -36,7 +36,7 @@
/*-*/
-#if defined(CONFIG_USB_SUSPEND) || defined(CONFIG_PM)
+#ifdef CONFIG_PM
#define OHCI_SCHED_ENABLES \
(OHCI_CTRL_CLE|OHCI_CTRL_BLE|OHCI_CTRL_PLE|OHCI_CTRL_IE)
@@ -277,24 +277,7 @@
return 0;
}
-static void ohci_rh_resume (void *_hcd)
-{
- struct usb_hcd *hcd = _hcd;
-
- usb_lock_device (hcd-self.root_hub);
- (void) ohci_hub_resume (hcd);
- usb_unlock_device (hcd-self.root_hub);
-}
-
-#else
-
-static void ohci_rh_resume (void *_hcd)
-{
- struct ohci_hcd *ohci = hcd_to_ohci (_hcd);
- ohci_dbg(ohci, rh_resume ??\n);
-}
-
-#endif /* CONFIG_USB_SUSPEND || CONFIG_PM */
+#endif /* CONFIG_PM */
/*-*/
@@ -553,7 +536,7 @@
temp = RH_PS_POCI;
if ((ohci-hc_control OHCI_CTRL_HCFS)
!= OHCI_USB_OPER)
-schedule_work (ohci-rh_resume);
+usb_hcd_resume_root_hub(hcd);
break;
case USB_PORT_FEAT_C_SUSPEND:
temp = RH_PS_PSSC;
--- g26.orig/drivers/usb/host/ohci-mem.c 2005-05-09 18:18:25.0 -0700
+++ g26/drivers/usb/host/ohci-mem.c 2005-05-09 18:18:56.0 -0700
@@ -28,7 +28,6 @@
ohci-next_statechange = jiffies;
spin_lock_init (ohci-lock);
INIT_LIST_HEAD (ohci-pending);
- INIT_WORK (ohci-rh_resume, ohci_rh_resume, ohci_to_hcd(ohci));
ohci-reboot_notifier.notifier_call = ohci_reboot;
}
--- g26.orig/drivers/usb/host/ohci.h 2005-05-09 18:18:25.0 -0700
+++ g26/drivers/usb/host/ohci.h 2005-05-09 18:18:56.0 -0700
@@ -389,7 +389,6 @@
unsigned long next_statechange; /* suspend/resume */
u32 fminterval; /* saved register */
- struct work_struct rh_resume;
struct notifier_block reboot_notifier;
unsigned long flags; /* for HC bugs */
--- g26.orig/drivers/usb/host/ohci-hcd.c 2005-05-09 18:18:25.0 -0700
+++ g26/drivers/usb/host/ohci-hcd.c 2005-05-09 18:18:56.0 -0700
@@ -747,7 +747,10 @@
if (ints OHCI_INTR_RD) {
ohci_vdbg (ohci, resume detect\n);
if (hcd-state != HC_STATE_QUIESCING)
- schedule_work(ohci-rh_resume);
+ usb_hcd_resume_root_hub(hcd);
+ /* in case root is autosuspended */
+ ohci_writel (ohci, OHCI_INTR_RD, regs-intrstatus);
+ ints = ~OHCI_INTR_RD;
}
if (ints OHCI_INTR_WDH) {
--- g26.orig/drivers/usb/core/hub.c 2005-05-09 18:17:30.0 -0700
+++ g26/drivers/usb/core/hub.c 2005-05-09 18:24:35.0 -0700
@@ -1971,14 +1971,6 @@
return 0;
}
-void usb_resume_root_hub(struct usb_device *hdev)
-{
- struct usb_hub *hub = hdev_to_hub(hdev);
-
- hub-resume_root_hub = 1;
- kick_khubd(hub);
-}
-
#else /* !CONFIG_USB_SUSPEND */
int usb_suspend_device(struct usb_device *udev, pm_message_t state)
@@ -2000,6 +1992,17 @@
EXPORT_SYMBOL(usb_suspend_device);
EXPORT_SYMBOL(usb_resume_device);
+#ifdef CONFIG_PM
+
+void usb_resume_root_hub(struct usb_device *hdev)
+{
+ struct usb_hub *hub =
Re: [linux-usb-devel] OHCI and suspend/resume problems
On Thursday 05 May 2005 8:16 am, Alan Stern wrote: On Wed, 4 May 2005, David Brownell wrote: ohci-hub.c:ohci_hub_suspend(): if (status == 0) hcd-state = HC_STATE_SUSPENDED; I think I remember why that's there. It pairs the earlier line in the same function to set hcd-state to QUIESCING. And the reason for that is because hcd-state is the only hook we have for, erm, quiescing the traffic going into the HCD. ... We have no other way to throttle down traffic just now... Do we really need to throttle down traffic from within usbcore? Sure looked like it last time I checked this issue out in detail. Won't it be enough to rely on the HCDs to reject submissions when they are unable to accept them? (Plus the fact that thanks to all the cleanups made in the last couple of years, hardly any submissions are made at inappropriate times.) Thing is there can be a window of around 10 msec there, unless this is the autosuspend case. During those 10 msec, something needs to prevent other code from using that device (e.g. on SMP). For now, that something is hcd-state. Maybe it can be improved, but I don't have timte to do it. I think a better way of looking at this is that the two notions may not yet been fully teased apart. If you really want to do this from within usbcore, consider restricting hcd-state to only three possible values: Okay to submit and unlink (running normally); Okay to unlink but not to submit (quiescing); Not okay to unlink or submit (any other state). That is, two bits to control submit and unlink capabilities, rather than the various other ones that now compose hcd-state? Sounds plausible. No part of usbcore outside of hcd-pci.c should care about anything else. And while we're at it, make it clear who owns hcd-state -- either the HCD or usbcore does, and the other shouldn't write to it at all. Any additional information needed by hcd-pci.c or the HCDs (such as whether IRQs are enabled) can be stored in a separate new field. Sounds plausible. As I recall, the reason usbcore touches hcd-state is primarily since the HCDs couldn't previously be relied on to do it right in all the relevant cases. However, it seems I've been interpreting hcd-state as representing the parts of root hub suspended that are a superset of what the root_hub-state == USB_STATE_SUSPENDED means. And leaving the other parts to bus-specific logic. One complication is that there's _also_ a need to represent the state of the HC itself. Including cases like: snip There's also the struct device dev-power.power_state field, which has always been problematic (vergin on useless) since the PM core doesn't manage it coherently. It's never really been usable as anything other than a boolean ... not powerful enough to distinguish cases like [4] in current kernels, either. Apart from the PCI bus glue, all of that stuff is private to the HCDs. It shouldn't be folded in along with a field used elsewhere in usbcore. Most of that superset is the root hub timer, and after your timer updates get merged (post-2.6.12) it becomes more reasonable for those bits to be managed that way. Re the [1]..[4] cases, I'd have to look up the snipped bits to see if I agree with applying that argument. And even the PCI glue info should be kept separate from things used only by HCDs. Right now hcd-state mixes all these different categories together in a confusing and error-prone way. It's called evolution in action. ;) Those two host controller suspend/resume calls are effectively there only for the PCI based controllers, and nothing they currently do seems HC-specific. (Other than the PMAC hooks, which seem to reflect deficiencies in the PCI suspend/resume framework... that stuff should be handled using generic PCI platform hooks.) I'd be happy to see those hooks vanish. You mean the suspend/resume routines in hcd-pci.c? Once a suitable generic PCI power driver is available they shouldn't be needed. We're nearly there already, in fact. - Dave --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click ___ 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] USB: Spelling fixes for drivers/usb.
On Saturday 07 May 2005 06:42 pm, Andries Brouwer wrote: On Sat, May 07, 2005 at 01:40:42PM -0700, David Brownell wrote: Here are some spelling corrections for drivers/usb. cancelation - cancellation For the record, cancelation (one l not two ll) is correct, though recently I've found some dictionaries listing cancellation (two ll) as an option. It'd be nice to do that ... fixes should really not change things that started out correct! At work a few years ago we actually did some research on this issue and, as a result of finding that the ll usage was not very widely accepted (in several dictionaries and quite a few CS research papers), we switched everything to use the single l usage. Which is why USB has so far been consistent about that form. Funny. I would have used -ll-. Let me see. - My Webster has -ll- and does not recognize -l-. - Cambridge Advanced Learner's dictionary has only -ll- - Merriam-Webster online says that -l- is a variant of -ll- - American Heritage says the same - Encarta says -l-: see -ll- - Webster 1828 has only -l- This quick test seems to show a strong preference for -ll- Let us ask Google. -ll-: about 22,100,000 -l-: about 205,000 and the question did you mean cancellation? (And what about the technical USB context? Again Google: -ll- + usb: about 251,000 -l- + usb: about 667.) So, I will not contradict your statement that cancelation is correct, but it certainly looks like cancellation is preferred, and that is also what the USB specs talk about. Andries Its seems that linux kernel coders are an odd lot when it comes to this particular spelling variation. Even with the recent conversion of seven instances of -l- to -ll- in drivers/usb, we still have: [EMAIL PROTECTED] linux-2.6.12-rc4]$ find . -type f | xargs grep -i cancellation | wc -l 29 [EMAIL PROTECTED] linux-2.6.12-rc4]$ find . -type f | xargs grep -i cancelation | wc -l 4 [EMAIL PROTECTED] linux-2.6.12-rc4]$ find . -type f | xargs grep -i cancelled | wc -l 117 [EMAIL PROTECTED] linux-2.6.12-rc4]$ find . -type f | xargs grep -i canceled | wc -l 91 David, I've cancelled the cancelation conversion in my local copy of this file: http://www.kegel.com/kerspell/spell-fix.txt See, no color/colour or buses/busses substitutions. Sorry for all the noyze. Steven --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click ___ 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] [RFC as507] Remove recursion in USB suspend/resume
On Friday 22 April 2005 11:52 am, Alan Stern wrote:
David:
Please take a look at this proposed patch and see what you think. It
removes the recursion from the usbcore suspend/resume routines.
Well, as I said it resembled one I'd been working on. I merged what
I think are the best parts of the two patches, and limited it to
suspend side changes; here it is.
Since the only remaining point of that second usb_suspend_device()
parameter was to support the recursion, I removed it. By analogy
to pci_set_power_state(), it doesn't need the parameter ... USB
hardware only has one suspend state, and resume() is separate.
Also the software-only state (interface-dev.power.power_state)
stays as SUSPENDED whenever the driver is unbound, simplifying
the logic to test when a device can be suspended and getting
ready to kick in device-level autosuspend.
There's
just a couple of small exceptions; the big one is that resuming a device
will cause all its interfaces to be resumed as well, and the small one is
that before suspending a device all the interfaces are checked to make
sure they are already suspended.
The former is basically keep current behavior; in this patch I took
it a step further and just didn't touch the resume path. (Later!)
The latter was something I'd done too.
I've tested this only lightly since merging things from your patch,
and there are various should not matter things I removed from the
version I'd been working on, but this version is similar to your patch,
or what's there now, that I don't think it'll make trouble.
- Dave
This is a net code shrink, mostly affecting CONFIG_USB_SUSPEND code:
* When suspending a device, insist all its interfaces already be
suspended rather than trying to suspend them directly. That is,
remove recursion during device-level suspend. (This is an issue
pmcore should handle; it only does so for whole-system suspend.)
* Generic USB suspend code now has the more featureful code to
suspend interfaces from usb_suspend_device() ... verifying that
any suspend method behaves, and issuing warnings for drivers that
don't yet provide suspend methods. (Eventually the warning should
be removed, once that pmcore self-deadlock is removed.)
* Generic hub suspend code now just insists that child devices be
already suspended. So do the PCI suspend paths for EHCI and OHCI.
* Get rid of the now-pointless extra parameter to usb_suspend_device().
Unlike pci_set_power_state(), there's no need for a parameter:
USB hardware only has one suspend state. If the hardware isn't
supposed to suspend, don't call this routine. Later we can define
some separate routine to power down a device's port.
* Unbound interfaces are always marked as suspended, since there's
no driver to handshake with about shutting it down and in any
case this never relates to hardware state.
Accordingly, these suspend paths must now return error codes in cases
where preconditions like children are already suspended fail. This
means suspend requests through sysfs won't just work any more; some
agent must manually do the recursion (hoping wakeups don't kick in).
These changes are not visible without CONFIG_USB_SUSPEND, except for
the warnings for drivers without suspend() methods.
(This incorporates pieces from a related patch from Alan Stern.)
Signed-off-by: David Brownell [EMAIL PROTECTED]
--- g26.orig/drivers/usb/core/hub.c 2005-05-09 18:24:35.0 -0700
+++ g26/drivers/usb/core/hub.c 2005-05-09 18:29:52.0 -0700
@@ -452,6 +452,7 @@
{
/* stop khubd and related activity */
hub-quiescing = 1;
+ hub-activating = 0;
usb_kill_urb(hub-urb);
if (hub-has_indicators)
cancel_delayed_work(hub-leds);
@@ -1243,10 +1244,9 @@
*/
if (udev-bus-b_hnp_enable || udev-bus-is_b_host) {
static int __usb_suspend_device (struct usb_device *,
- int port1, pm_message_t state);
+ int port1);
err = __usb_suspend_device(udev,
- udev-bus-otg_port,
- PMSG_SUSPEND);
+ udev-bus-otg_port);
if (err 0)
dev_dbg(udev-dev, HNP fail, %d\n, err);
}
@@ -1452,7 +1452,7 @@
/* FIXME let caller ask to power down the port:
* - some devices won't enumerate without a VBUS power cycle
* - SRP saves power that way
- * - usb_suspend_device(dev, PMSG_SUSPEND)
+ * - ... new call, TBD ...
* That's easy if this hub can switch power per-port, and
* khubd reactivates the port later (timer, SRP, etc).
* Powerdown must be optional, because of reset/DFU.
@@ -1539,8 +1539,7 @@
* Linux (2.6) currently has NO mechanisms to initiate that: no khubd
* timer, no SRP, no requests through sysfs.
*/
-static int __usb_suspend_device (struct usb_device *udev, int port1,
- pm_message_t state)
+static int __usb_suspend_device (struct usb_device *udev, int port1)
{
int status;
@@ -1553,67 +1552,23 @@
return 0;
}
- /* suspend interface drivers; if this is a hub, it
- *
[linux-usb-devel] [PATCH] hid-core: add Earthmate lt-20 productid to blacklist table
Hello,
This patch adds the DeLorme Earthmate lt-20 productid to the hid blacklist
table. This patch ensures the lt-20 can be claimed by the appropriate driver
(cypress_m8).
Thank you,
Lonnie Mendez
--
Adds the product id 0x200, of the DeLorme Earthmate lt-20, to the hid
blacklist table.
Signed-off-by: Lonnie Mendez [EMAIL PROTECTED]
--- a/drivers/usb/input/hid-core.c 2005-05-09 13:58:46.547431248 -0500
+++ b/drivers/usb/input/hid-core.c 2005-05-09 14:02:43.692379736 -0500
@@ -1401,6 +1401,7 @@
#define USB_VENDOR_ID_DELORME 0x1163
#define USB_DEVICE_ID_DELORME_EARTHMATE 0x0100
+#define USB_DEVICE_ID_DELORME_EM_LT20 0x0200
#define USB_VENDOR_ID_MCC 0x09db
#define USB_DEVICE_ID_MCC_PMD1024LS 0x0076
@@ -1437,6 +1438,7 @@
{ USB_VENDOR_ID_CODEMERCS, USB_DEVICE_ID_CODEMERCS_IOW28, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_HIDCOM, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EARTHMATE, HID_QUIRK_IGNORE },
+ { USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_ESSENTIAL_REALITY, USB_DEVICE_ID_ESSENTIAL_REALITY_P5, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_GLAB, USB_DEVICE_ID_4_PHIDGETSERVO_30, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_GLAB, USB_DEVICE_ID_1_PHIDGETSERVO_30, HID_QUIRK_IGNORE },
[linux-usb-devel] [PATCH] cypress_m8: add support for the DeLorme Earthmate lt-20
Hello,
This patch adds support for the DeLorme Earthmate lt-20 to the cypress_m8
driver. The device was tested and found to be compatible with the cypress_m8
driver.
Thank you,
Lonnie Mendez
--
Adds support for the DeLorme Earthmate lt-20 to the cypress_m8 driver.
Signed-off-by: Lonnie Mendez [EMAIL PROTECTED]
--- a/drivers/usb/serial/cypress_m8.c 2005-05-09 14:04:53.935579760 -0500
+++ b/drivers/usb/serial/cypress_m8.c 2005-05-09 14:13:20.503569720 -0500
@@ -89,6 +89,7 @@
static struct usb_device_id id_table_earthmate [] = {
{ USB_DEVICE(VENDOR_ID_DELORME, PRODUCT_ID_EARTHMATEUSB) },
+ { USB_DEVICE(VENDOR_ID_DELORME, PRODUCT_ID_EARTHMATEUSB_LT20) },
{ } /* Terminating entry */
};
@@ -99,6 +100,7 @@
static struct usb_device_id id_table_combined [] = {
{ USB_DEVICE(VENDOR_ID_DELORME, PRODUCT_ID_EARTHMATEUSB) },
+ { USB_DEVICE(VENDOR_ID_DELORME, PRODUCT_ID_EARTHMATEUSB_LT20) },
{ USB_DEVICE(VENDOR_ID_CYPRESS, PRODUCT_ID_CYPHIDCOM) },
{ } /* Terminating entry */
};
Re: [linux-usb-devel] laptop sleep on iBook G4 panics ehci_hcd in 2.6.12-rc4 with hub attached
On Mon, 2005-05-09 at 07:31 -0700, David Brownell wrote:
On Monday 09 May 2005 2:25 am, John Steele Scott wrote:
On Sun, 2005-05-08 at 13:13 -0700, David Brownell wrote:
Just to follow up on this, I just recently had the following oops:
Oops: kernel access of bad area, sig: 11 [#1]
NIP: DA50DEE8 LR: DA4A2498 SP: D3173D90 REGS: d3173ce0 TRAP: 0300Not
tainted
MSR: 0200b032 EE: 1 PR: 0 FP: 1 ME: 1 IR/DR: 11
DAR: 18A8, DSISR: 4000
TASK = d7ae4110[4325] 'pbbuttonsd' THREAD: d3172000
Last syscall: 54
GPR00: D3173D90 D7AE4110 0010 0001 C0330F4C
C0330DDC
GPR08: DA518850 D54216D8 28000482 10026C18 100C
100A
GPR16: 100D7408 28222482 100C 100D6F28 100D6AE8 10001180
1000BF7C
GPR24: C02B C02DAF5C C02E C02E C02DAF54 D5421768 C02B5648
D54216D8
NIP [da50dee8] hid_resume+0x20/0x48 [usbhid]
And what's at that location? Presumably it doesn't happen if you
disconnect the HID device before suspend? Is this with or without
CONFIG_USB_SUSPEND?
hid_resume+0x20 would be something like:
static int hid_resume(struct usb_interface *intf)
{
struct hid_device *hid = usb_get_intfdata (intf);
int status;
intf-dev.power.power_state = PMSG_ON;
---if (hid-open)
status = usb_submit_urb(hid-urbin, GFP_NOIO);
else
status = 0;
dev_dbg(intf-dev, resume status %d\n, status);
return status;
}
It tries to dereference 0x18A8 which is a bogus pointer, _BUT_ is also
the offset of open in hid (looking at the disassembly). So basically,
the problem here is that hid is NULL (race race race ?)
Ben.
---
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
