Re: [linux-usb-devel] [PATCH] limit power budget on spitz
On Thu, 2006-06-08 at 10:34 +0200, Pavel Machek wrote:
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index acde886..1d8b58c 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -185,6 +185,13 @@ int usb_hcd_pxa27x_probe (const struct h
/* Select Power Management Mode */
pxa27x_ohci_select_pmm(inf-port_mode);
+ if (machine_is_spitz()) {
+ /* Warning, not coming from any official docs. But
+ * spitz is unable to properly power wireless card
+ * claiming 500mA -- usb interface work but wireless
+ * does not. */
+ hcd-power_budget = 250;
+ }
ohci_hcd_init(hcd_to_ohci(hcd));
retval = usb_add_hcd(hcd, pdev-resource[1].start, SA_INTERRUPT);
Should this value not be specified by the platform in the platform data
rather than a set of machine_is_xxx statements in the driver itself? I
already put most of the infrastructure for that into place.
I also strongly suspect the power supply on the device is limited to
150mA.
Richard
___
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] limit power budget on spitz
Hi,
On Thu, 2006-06-08 at 11:02 +0200, Pavel Machek wrote:
+ if (machine_is_spitz()) {
+ /* Warning, not coming from any official docs. But
+ * spitz is unable to properly power wireless card
+ * claiming 500mA -- usb interface work but wireless
+ * does not. */
+ hcd-power_budget = 250;
+ }
Should this value not be specified by the platform in the platform data
rather than a set of machine_is_xxx statements in the driver itself? I
already put most of the infrastructure for that into place.
Well, it has quite few users now, and this is how it works in
ohci-omap. Yes, if we get more of such hooks, it probably needs to be
moved to platform data...
Just because the omap does it that way, doesn't mean it can't be done
better ;-). I've also just realised the above doesn't account for akita
or borzoi. Since the hardware is identical in this area, the same
changes should be applied for those machines. If we use the platform
device/data approach, we don't have this problem as they all use the
same platform device :)
I can't create a patch at the moment but I can have a look at this
later...
Cheers,
Richard
___
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] Problems with isp116x driver on IXP425
Hi, I have the isp116x running fine on my ixp425 platform under kernel 2.4.27-uc1, where it maps to IXP425_EXP_BUS_CS4_BASE_VIRT = 0xf400 (the 2.4.27 driver does not perform ioremap). However with kernel - 2.6.12, (same platform and settings as in the 2.4.27 case) I provide the physical address IXP425_EXP_BUS_CS4_BASE_PHYS = 0x5400 which is then ioremap'd (togther with 0x5402 for addr) after which I am unable to read/write from/to the chip (all registers when read come with the same value of 0x1000)? Is it a mem mapping problem or is it maybe an issue with the read/write procedures (or maybe something else that I hvent thought about)? Using: uClinux kernel - 2.6.12-uc0 ixp425 (with MMU on) isp116x-2.6.12.patch.bz2 --Danny ___ 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] No EHCI IRQ reported when device is connected
Hi , i am testing the ehci-hcd river for ARC HS OTG controller. I have the following observations when i try connecting devices. After the probe, the POTRSCx values are 0x8c001000 for ARC controller whcih is EHCI complaint. COMMAND: 0x80b01 MODE: 0x7 STATUS: 0x88 INTERRUPT: 0x37 SET INTR ARE (INTR_MASK): 0x37 PORT 0 STATUS: 0x8c001000 SEGMENT = 0x0 FRAME LIST = 0x63ff4000 ASYNC LIST = 0x63ff2000 TTCTRL = 0x0 CONFIGURE FLAG = 0x1 OTGSC = 0x313120 PORT STATUS CONTROL REGISTERS PORTSC[0] = 0x8c001000 1) When a OTG hard disk(Self Powered) was connected, there was no interrupt and my ehci_irq interrupt handler was not invoked. When i power on the device i get a DISCONNECT event from the device and the PORTSCx value changes to 0x8c001002 (CCS = 0,CSC =1) and IRQ IS GENERATED . STATUS register shows Port Change Detect Interrupt (STS = 0x8C). So when the hub_events() tries to do a GetPortStatus, it does not find connection(CCS =0) and the hub_port_connect_change() function returns. Also PORT-ENABLE bit in PORTSCx is not 1. That means that even though a device was connected, the port is not enabled. 2) When a USB2.0 HS speed device(thumb drive or Camera) was connected to the board, there is no interrupt genearated. This is visible from cat /proc/interrupts. How can interpret the above 2 observations. I am getting PCD interrupts for disconnect event from a device(OTG) , after that was connected and powered on. For other devices i am not getting interrupt. Please help me debug this problem. The probe function before returning dumps the following register values DUMP of /sys/class/usb_host/usb_host/register after the OTG device was connected and powered on. bus platform, device ab301_ehci_usb.0 (driver 10 Dec 2004) EHCI Host Controller EHCI 1.00, hcd state 1 structural params 0x00010011 capability params 0x0006 status 0088 FLR command 080b01 park=3 ithresh=8 period=1024 RUN intrenable 37 IAA FATAL PCD ERR INT uframe 22e0 port 1 status 8c001000 POWER sig=se0 irq normal 0 err 0 reclaim 0 (lost 0) complete 0 unlink 0 Thanks Rak ___ 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] Make Microsoft wireless optical desktop
feladó: Alan Stern On Wed, 7 Jun 2006, Zoltan Karcagi wrote: If you apply this patch instead of yours: http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-04-usb/usbhid-remove-unneeded-blacklist-entries.patch does the device then work? Alan, I think you meant this one instead: http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-04-usb/usbhid-automatically-set-hid_quirk_noget-for-keyboards-and-mice.patch My mistake. Yes, I meant that one instead. The device still fails with that one applied: bInterfaceProtocol on the second interface is 0, so it does not trigger the special case. I noticed that in your original submission. Do you know what the second interface is for? Just guessing here: all the mouse related stuff (that's for sure), wireless link quality and battery level monitoring, and maybe all the extra buttons (for multimedia, application quicklaunch) and the zoom slider. I can post the output of lsusb with all the reports if that helps. Do you want me to do that? (Warning - size is around 30k - lots of reports on that second interface. ) (Trying to repost, spamassasin killed my first attempt...) ___ 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] limit power budget on spitz
Hi!
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index acde886..1d8b58c 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -185,6 +185,13 @@ int usb_hcd_pxa27x_probe (const struct h
/* Select Power Management Mode */
pxa27x_ohci_select_pmm(inf-port_mode);
+ if (machine_is_spitz()) {
+ /* Warning, not coming from any official docs. But
+* spitz is unable to properly power wireless card
+* claiming 500mA -- usb interface work but wireless
+* does not. */
+ hcd-power_budget = 250;
+ }
ohci_hcd_init(hcd_to_ohci(hcd));
retval = usb_add_hcd(hcd, pdev-resource[1].start, SA_INTERRUPT);
Should this value not be specified by the platform in the platform data
rather than a set of machine_is_xxx statements in the driver itself? I
already put most of the infrastructure for that into place.
Well, it has quite few users now, and this is how it works in
ohci-omap. Yes, if we get more of such hooks, it probably needs to be
moved to platform data...
I also strongly suspect the power supply on the device is limited to
150mA.
Thanks!
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
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] usbkb - does not work
Hi, We have a Cypress based usb keyboard software that enumerates as a USB Keyboard and works properly in Windows 32 / 64 bit platforms. When it is connected to Linux, the device enumerates as a keyboard with proper configurations. But whatever keystrokes we send to the host are lost. I have attached the dmesg and some more information in the attached log. Do you have any suggestions for it ? Thanks, Jayaprakash. usbkb.log Description: Binary data ___ 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 devices fail unnecessarily on unpowered hubs
Hi! If that does the job we need to somehow inherit the power supply maximum from PCI when we allocate the root hub's device structure. I don't think there is such a convention that's generic for PCI. There might be ACPI-specific tables holding that value, but on embedded hardware the model is often that the arch/.../board-ZZZ.c file just knows things like how much power the regulator powering that port can provide, and arranges bus_mA to match. Just like it knows all sorts of other details about how that board works. Yes, I am afraid it cannot be done on the fly. But we might use a symbolic define which a subarch can override instead of a literal 500. If it turns out that this problem is one of power and not some other deficiency of this system's root hub. That's bad... because we don't know exact model until runtime (ARM tries to support many machines with single binary kernel, AFAICS), and this is very likely going to be model-dependend. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ 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] Probe function not called (Linux 2.6.16)
Hi,
I am writing a Linux USB driver and got stuck trying to get the probe function
working.
The driver is for a USB 1.1 device with 2 interrupt endpoints (in/out). I have
several of these devices attached (they are controlling one gyroscope and 8
motors on a mobile robot platform), and working with libusb seems to slow.
They have a fixed vendor id (0x400) and each a different product id (jumper
settings). The output of lsusb (usbutils) is attached.
The driver is based on the usb-skeleton.c from 2.6.16, but for debugging
purposes I built a minimal driver that just tries to match the device (and
produces dmesg output). When using vendor/product ids of another usb device (a
joystick), the probe function does get called, provided that i rmmod the usbhid
driver first. The source is attached.
I am suspecting another driver gets probed and claims the device, but have no
idea which. I tried to rmmod as many drivers as possible, an lsmod of the
remaining drivers is attached.
Can I find out which drivers might claim a certain device (e.g. vendor/product
id combination)?
Is there a way to manually trigger a probe (without reattaching)?
Is there an accurate description of the usb probe cycle (except digging through
the linux source itself - which is what I am doing now)?
I'm using a stock debian kernel btw (2.6.16-1-686). My next step will be to
compile a kernel with all of the unnecessary USB parts removed.
Thanks in advance,
Sven Moellers
$ lsusb
Bus 001 Device 014: ID 0400:0007 National Semiconductor Corp.
Bus 001 Device 013: ID 0400:000d National Semiconductor Corp.
Bus 001 Device 012: ID 0400:000c National Semiconductor Corp.
Bus 001 Device 011: ID 0451:2046 Texas Instruments, Inc. TUSB2046 Hub
Bus 001 Device 002: ID 06a3:0464 Saitek PLC
Bus 001 Device 010: ID 0400:000e National Semiconductor Corp.
Bus 001 Device 009: ID 0400:000f National Semiconductor Corp.
Bus 001 Device 008: ID 0400:000b National Semiconductor Corp.
Bus 001 Device 007: ID 0451:2046 Texas Instruments, Inc. TUSB2046 Hub
Bus 001 Device 006: ID 0400:0009 National Semiconductor Corp.
Bus 001 Device 005: ID 0400:0008 National Semiconductor Corp.
Bus 001 Device 004: ID 0400:000a National Semiconductor Corp.
Bus 001 Device 003: ID 0451:2046 Texas Instruments, Inc. TUSB2046 Hub
Bus 001 Device 001: ID :
$ lsmod
Module Size Used by
floppy 55628 0
ext3 115880 1
jbd46932 1 ext3
mbcache 7652 1 ext3
ide_generic 1120 0 [permanent]
ide_disk 14528 3
piix8932 0 [permanent]
generic 4164 0 [permanent]
uhci_hcd 26640 0
ide_core 111440 4 ide_generic,ide_disk,piix,generic
usbcore 110560 2 uhci_hcd
e100 31044 0
mii 5056 1 e100
processor 21376 0
// source of the driver (minimal version for probe debugging)
#include linux/config.h
#include linux/kernel.h
#include linux/errno.h
#include linux/usb.h
#define USB_GYRO_VENDOR_ID 0x0400
#define USB_GYRO_PRODUCT_ID 0x0007
#define JS_VENDOR 0x06a3
#define JS_PRODUCT 0x0464
static struct usb_device_id gyro_table [] = {
{ USB_DEVICE(USB_GYRO_VENDOR_ID, USB_GYRO_PRODUCT_ID) },
// not working
{ .match_flags = USB_DEVICE_ID_MATCH_VENDOR, .idVendor=USB_GYRO_VENDOR_ID },
// not working
//{ .match_flags = 0, .driver_info = 123 },
// matches everything - working for joystick
//{ USB_DEVICE(JS_VENDOR, JS_PRODUCT) },
// working
//{ .match_flags = USB_DEVICE_ID_MATCH_VENDOR, .idVendor=JS_VENDOR },
// working
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE (usb, gyro_table);
static int gyro_probe(struct usb_interface *interface, const struct
usb_device_id *id)
{
err(* PROBE ***\n);
return 0;
}
static void gyro_disconnect(struct usb_interface *interface)
{
err(*** DISCONNECT \n);
}
static struct usb_driver gyro_driver = {
.name = gyroscope,
.probe = gyro_probe,
.disconnect = gyro_disconnect,
.id_table = gyro_table,
//.no_dynamic_id = 0 // doesnt make a difference (concerning probe) if
enabled/disabled
};
static int __init usb_gyro_init(void)
{
int result;
err(* INIT *\n);
result = usb_register(gyro_driver);
if (result)
err(usb_register failed. Error number %d, result);
return result;
}
static void __exit usb_gyro_exit(void)
{
err(* EXIT *\n);
[linux-usb-devel] [PATCH] limit power budget on spitz
This limits power budget on spitz to 250mA. I'm not sure if it is the
right value, but it is certainly better than default 500mA, and
prevents nasty failure mode with zd1201.
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
PATCH FOLLOWS
KernelVersion: 2.6.17-rc6-git
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index acde886..1d8b58c 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -185,6 +185,13 @@ int usb_hcd_pxa27x_probe (const struct h
/* Select Power Management Mode */
pxa27x_ohci_select_pmm(inf-port_mode);
+ if (machine_is_spitz()) {
+ /* Warning, not coming from any official docs. But
+* spitz is unable to properly power wireless card
+* claiming 500mA -- usb interface work but wireless
+* does not. */
+ hcd-power_budget = 250;
+ }
ohci_hcd_init(hcd_to_ohci(hcd));
retval = usb_add_hcd(hcd, pdev-resource[1].start, SA_INTERRUPT);
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
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] Make Microsoft wireless optical desktop
On Thu, 8 Jun 2006, Zoltan Karcagi wrote: I noticed that in your original submission. Do you know what the second interface is for? Just guessing here: all the mouse related stuff (that's for sure), wireless link quality and battery level monitoring, and maybe all the extra buttons (for multimedia, application quicklaunch) and the zoom slider. I can post the output of lsusb with all the reports if that helps. Do you want me to do that? (Warning - size is around 30k - lots of reports on that second interface. ) No thank you, I was just curious. Alan Stern ___ 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] Probe function not called (Linux 2.6.16)
On Thu, 8 Jun 2006 12:21:14 +0200, Sven Moellers [EMAIL PROTECTED] wrote: I am suspecting another driver gets probed and claims the device [...] Make sure your old usbfs based app wasn't running. Other than this the source looks perfect, it must work. Look at /proc/bus/usb/devices, it shows the currently bound driver. -- Pete ___ 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] limit power budget on spitz
On Thu, Jun 08, 2006 at 10:22:50AM +0100, Richard Purdie wrote:
Hi,
On Thu, 2006-06-08 at 11:02 +0200, Pavel Machek wrote:
+ if (machine_is_spitz()) {
+ /* Warning, not coming from any official docs. But
+* spitz is unable to properly power wireless card
+* claiming 500mA -- usb interface work but wireless
+* does not. */
+ hcd-power_budget = 250;
+ }
Should this value not be specified by the platform in the platform data
rather than a set of machine_is_xxx statements in the driver itself? I
already put most of the infrastructure for that into place.
Well, it has quite few users now, and this is how it works in
ohci-omap. Yes, if we get more of such hooks, it probably needs to be
moved to platform data...
Just because the omap does it that way, doesn't mean it can't be done
better ;-). I've also just realised the above doesn't account for akita
or borzoi. Since the hardware is identical in this area, the same
changes should be applied for those machines. If we use the platform
device/data approach, we don't have this problem as they all use the
same platform device :)
So what do folk want me to do? Blindly merge the patch (hint: it's still
in the incoming queue...)
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
___
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] limit power budget on spitz
On Thursday 08 June 2006 10:09 am, Russell King wrote:
On Thu, Jun 08, 2006 at 10:22:50AM +0100, Richard Purdie wrote:
Hi,
On Thu, 2006-06-08 at 11:02 +0200, Pavel Machek wrote:
+ if (machine_is_spitz()) {
+ /* Warning, not coming from any official docs. But
+ * spitz is unable to properly power wireless card
+ * claiming 500mA -- usb interface work but wireless
+ * does not. */
+ hcd-power_budget = 250;
+ }
Should this value not be specified by the platform in the platform data
rather than a set of machine_is_xxx statements in the driver itself? I
already put most of the infrastructure for that into place.
Well, it has quite few users now, and this is how it works in
ohci-omap. Yes, if we get more of such hooks, it probably needs to be
moved to platform data...
Just because the omap does it that way, doesn't mean it can't be done
better ;-).
Agreed that platform_data is a better approach overall for holding that
power budget. OMAP and AT91 should do so too.
I've also just realised the above doesn't account for akita
or borzoi. Since the hardware is identical in this area, the same
changes should be applied for those machines. If we use the platform
device/data approach, we don't have this problem as they all use the
same platform device :)
So what do folk want me to do? Blindly merge the patch (hint: it's still
in the incoming queue...)
Sounds like someone should update the patch to (a) use a 150 mA budget,
and (b) test for those other machines. As a near term patch, anyway.
Unless there's a patch to provide and use platform_data ... but that'd
be much more involved, since ISTR the PXA platforms don't yet have a
mechanism to provide board-specific platform_data. (I'll suggest the
AT91 code as a model there; it's simpler hardware than OMAP, so the
code is more straightforward.)
- Dave
___
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: [Bugme-new] [Bug 6667] New: usb keyboard (vendor: E5) doesn't work
Begin forwarded message: Date: Thu, 8 Jun 2006 11:39:33 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug 6667] New: usb keyboard (vendor: E5) doesn't work http://bugzilla.kernel.org/show_bug.cgi?id=6667 Summary: usb keyboard (vendor: E5) doesn't work Kernel Version: 2.6.16-gentoo-r9 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: 2.6.16-gentoo-r9 Distribution: gentoo 2006.0 Hardware Environment: usb keyboard from e5world.com Software Environment: Problem Description: when i plug in keyboard kernel logs many messages like that: drivers/usb/input/hid-core.c: input irq status -32 received (keyboard doesn't work, replug doesn't help, i tried on windows xp environment and there keyboard works good) Steps to reproduce: use this keyboard;) cat /proc/bus/usb/devices (...) T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=062a ProdID=0201 Rev= 1.00 S: Product=USB-compliant keyboard C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid E: Ad=82(I) Atr=03(Int.) MxPS= 4 Ivl=10ms --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ 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] [linux-pm] Remote wake up not working
On Thursday 08 June 2006 5:21 am, [EMAIL PROTECTED] wrote: Hi, [ don't cc digest lists ... and avoid ccing multiple lists! ] I am using ACER Aspire 3003LC laptop. Linux version: 2.6.15.4. I my Host Controller supports Power Management. That's with a SIS southbridge, right? With both EHCI and OHCI? I tried selective suspend/resume and it worked properly. Also my Host Controller supports remote wake up. So i tried testing remote wake up. But it did not work. Then i tried the same with the standard ( OHCI controller of my laptop ). It did not work as wel. You should include specifics of how you tested, and the failure mode... Also the lspci -vv output, and the relevant parts of kernel config. (Presumably CONFIG_PM is defined, also CONFIG_USB_SUSPEND...) And to be most useful, the lsusb -v output for the devices you're using as wakeup event sources. (Not all USB devices behave yet for suspend/resume, or issue wakeup events.) Note that remote wakeup -- from e.g. a system standby or suspend-to-RAM state -- on x86 hardware probably involves ensuring that /proc/acpi/wakeup lists the USB controllers as wakeup sources. Then i changed my laptop and tried testing remote wakeup and it worked properly with the OHCI controller and also with my Host Controller. That is, using a different southbridge? And different BIOS, with different ACPI support? Again, you'd need to provide specifics. Congratulations!! So far, every time I've tested remote wakeup on Linux, the ACPI code broke during the resume process ... that is, if it managed to enter a standby or suspend-to-ram state in the first place (again, ACPI problems). I know that USB was doing the right thing, since that can be unit tested outside of system sleep states. So does this mean that there is something wrong with the ACER Aspire 3003LC laptop ? Or is there something on which remote wake up depends on besides the Host Controller and the device ( supporting remote wake up ) ? My first guess would be you're seeing ACPI breakage, or perhaps you're not setting things up correctly. If you really did the same tests on both laptops, I'd be more inclined to suspect ACPI ... especially since that's where the problems have always been in my testing. - Dave ___ 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] Fix disconnect race in usbnet
Hi David, I'm currently working on fixing possible disconnect races in a USB-WLAN driver, and to start with I'm trying to convince myself that such races don't exist in other USB networking drivers (and why). I had a quick look at usbnet, and decided that one such possible race could occur if usbnet_start_xmit() is in progress while the user yanks out the device. That particular function uses the usbnet struct for that device, which is stored inside the net_device struct, which is freed during disconnect(). The most sensible approach to fixing this is to ensure that all current transmissions have completed before freeing the structures. And it looks like someone might have tried to implement this: disconnect() implicitly calls usbnet_stop(), which calls netif_stop_queue(). However, netif_stop_queue() may return with transmissions still running on other CPUs - I think netif_tx_disable() is what is needed, which guarantees that no transmissions are active when it returns. Do you agree that this is a potential race? Signed-off-by: Daniel Drake [EMAIL PROTECTED] Index: linux/drivers/usb/net/usbnet.c === --- linux.orig/drivers/usb/net/usbnet.c +++ linux/drivers/usb/net/usbnet.c @@ -534,7 +534,7 @@ static int usbnet_stop (struct net_devic DECLARE_WAIT_QUEUE_HEAD (unlink_wakeup); DECLARE_WAITQUEUE (wait, current); - netif_stop_queue (net); + netif_tx_disable (net); if (netif_msg_ifdown (dev)) devinfo (dev, stop stats: rx/tx %ld/%ld, errs %ld/%ld, ___ 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] limit power budget on spitz
On Thu, 2006-06-08 at 11:26 -0700, David Brownell wrote: On Thu, Jun 08, 2006 at 10:22:50AM +0100, Richard Purdie wrote: Just because the omap does it that way, doesn't mean it can't be done better ;-). Agreed that platform_data is a better approach overall for holding that power budget. OMAP and AT91 should do so too. Sounds like someone should update the patch to (a) use a 150 mA budget, and (b) test for those other machines. As a near term patch, anyway. Unless there's a patch to provide and use platform_data ... but that'd be much more involved, since ISTR the PXA platforms don't yet have a mechanism to provide board-specific platform_data. (I'll suggest the AT91 code as a model there; it's simpler hardware than OMAP, so the code is more straightforward.) The PXA platform does have an existing mechanism to pass platform data (I added it a while back). I've added http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3547/1 into the patch system replacing Pavel's version. Cheers, Richard ___ 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] usbserial: fake 0x80 before CR and/or LF.
On Wed, 7 Jun 2006 15:40:13 -0700 Greg KH [EMAIL PROTECTED] wrote: | On Wed, Jun 07, 2006 at 04:53:33PM -0300, Luiz Fernando N. Capitulino wrote: | | Hi Sergei, | | On Wed, 07 Jun 2006 21:54:16 +0400 | Sergei Organov [EMAIL PROTECTED] wrote: | | | Would it be a welcome contribution if I try to split the generic into, | | say, usb-serial-core and usb-serial-generic, the latter being really | | tiny at the beginning, and then improve it for speed? I've actually done | | it (speed improvement for bulk transfers) one time for 2.4.x, but at | | that time interface to the tty layer was not suitable for high-speed | | transfers and therefore my code had quite a few ugly kludges and finally | | I wasn't able to match raw USB bulk speeds anyway. Now, AFAIK, the tty | | layer interface has been improved and I hope to have better experience. | | Yes, it was. | | Considering the current design, one thing I'd like to have is the generic | code completely decoupled from the usbserial module, ie, a real | usbserial-generic module. | | This would also force us to kill the fix_up_generic() function. | I don't like the way it works, IMHO, it's C black magic, and it | can lead to trouble. | | How? It works like other kernel functions, if you don't define your own | function pointer, it defaults to the generic one. My theoretical trouble may happen when you're new to the usbserial layer and are hacking a new driver and forget to assign, let's say, open(). Then you run the driver, and realizes that a magical function ran. After some time debugging it, you discover fixup_generic(). Okay, I exaggerated a bit. Maybe it's just a matter of taste. | I created the fix_up_generic() function to make it easier than doing the | check on every test for the different function pointers. One test at | module load time is better than a test for every time write() is called | :) Sure, and that's really good. But I'd check whether it's NULL, if so, I wouldn't load the driver and would print a message, something like open() not assigned. | Would be better to have usbserial-generic only exporting the | generic methods, then driver authors would assign by hand the methods | he (or she) wants to use (yes, nothing automatic). | | What happens if they don't set up the proper functions? We should | default back to the generic ones then, otherwise bad things can | happen. | | Think of it as inheriting from a base C++ class, and it will become more | comfortable :) :) -- Luiz Fernando N. Capitulino ___ 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] usbserial: fake 0x80 before CR and/or LF.
On Thu, 08 Jun 2006 09:16:17 +0400 Sergei Organov [EMAIL PROTECTED] wrote: | Hi Luiz, | | Luiz Fernando N. Capitulino [EMAIL PROTECTED] writes: | Hi Sergei, | [...] | I said 'current design' because the generic code could be merged | with usbserial core with the libata-like design we discussed | some days ago (which is part of my Serial Core port WIP[1]). | | [1] http://distro2.conectiva.com.br/~lcapitulino/patches/usbserial/2.6.17-rc5/serialcore-port-V0/ | | Yeah, I've been following the discussion though I didn't look into the | patches yet. Please, do that if you can, more reviewers the better. | What I'm interested in is high-speed USB bulk driver that | looks like a tty for user-space and can handle any device that provides | at least one pair of raw data bulk endpoints. For those beast doesn't | seem to exist, I think I need either to write one, or to modify the | generic one for higher speeds. As far as I understood from the | announcements, existing drivers are to be ported to the new design | anyway. Do you think I should better implement it on top of your patches | then? I'd say yes only if it's easier for you, otherwise don't. The Serial Core port is highly experimental, and even if it's something that will get merged in the future, people will not get the benefits of your work anytime soon. -- Luiz Fernando N. Capitulino ___ 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] limit power budget on spitz
The PXA platform does have an existing mechanism to pass platform data (I added it a while back). I've added http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3547/1 into the patch system replacing Pavel's version. OK, I see now. Simple enough, better than the original. Go for it. There was a PXA issue I was alluding to that's still open, though. It's the way there's no selectivity about what platform devices are registered ... even kernels running on boards where OHCI isn't hooked up to anything will be registering an OHCI controller, as one of many examples. Won't affect this particular case, but in general that'd be nice to see fixed. - Dave ___ 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] limit power budget on spitz
On Thu, 2006-06-08 at 13:38 -0700, David Brownell wrote:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3547/1
OK, I see now. Simple enough, better than the original. Go for it.
There was a PXA issue I was alluding to that's still open, though.
It's the way there's no selectivity about what platform devices are
registered ... even kernels running on boards where OHCI isn't hooked
up to anything will be registering an OHCI controller, as one of many
examples. Won't affect this particular case, but in general that'd
be nice to see fixed.
As I understood the code, if you don't have platform_data set, it will
abort in the probe function so it depends what you mean by register. An
OHCI controller never gets created without platform_data.
You're right that the PXA platform device is always registered. FWIW,
there is no platform in mainline that doesn't have OHCI present so this
isn't a major problem at the moment.
The easiest solution might be to move the ohci device registration into
pxa_set_ohci_info (in pxa27x.c). I gave in and appended a patch (compile
tested only so far).
Cheers,
Richard
Only register the PXA OHCI platform device on platforms which provide
the platform data.
Signed-off-by: Richard Purdie [EMAIL PROTECTED]
Index: git/arch/arm/mach-pxa/pxa27x.c
===
--- git.orig/arch/arm/mach-pxa/pxa27x.c 2006-06-08 20:50:15.0 +0100
+++ git/arch/arm/mach-pxa/pxa27x.c 2006-06-08 22:08:49.0 +0100
@@ -200,15 +200,5 @@
void __init pxa_set_ohci_info(struct pxaohci_platform_data *info)
{
ohci_device.dev.platform_data = info;
+ platform_device_register(ohci_device);
}
-
-static struct platform_device *devices[] __initdata = {
- ohci_device,
-};
-
-static int __init pxa27x_init(void)
-{
- return platform_add_devices(devices, ARRAY_SIZE(devices));
-}
-
-subsys_initcall(pxa27x_init);
___
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] limit power budget on spitz
On Thursday 08 June 2006 2:22 pm, Richard Purdie wrote: On Thu, 2006-06-08 at 13:38 -0700, David Brownell wrote: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3547/1 OK, I see now. Simple enough, better than the original. Go for it. There was a PXA issue I was alluding to that's still open, though. It's the way there's no selectivity about what platform devices are registered ... even kernels running on boards where OHCI isn't hooked up to anything will be registering an OHCI controller, as one of many examples. Won't affect this particular case, but in general that'd be nice to see fixed. As I understood the code, if you don't have platform_data set, it will abort in the probe function so it depends what you mean by register. An OHCI controller never gets created without platform_data. You're right that the PXA platform device is always registered. FWIW, there is no platform in mainline that doesn't have OHCI present so this isn't a major problem at the moment. Right. OHCI was just an example though ... there are lots of other platform drivers for PXA. I'm not sure they all check for platform_data before succeeding in their probe() methods. The easiest solution might be to move the ohci device registration into pxa_set_ohci_info (in pxa27x.c). I gave in and appended a patch (compile tested only so far). Looked OK to me. That's the kind of approach now used with OMAP and AT91, and which IMO would be appropriate to use for most platform devices ... that is, don't register devices that the board doesn't have. One additional nuance: if the kernel doesn't have that driver configured, that's another reason not to bother registering its device. - Dave ___ 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] limit power budget on spitz
On Thu, 2006-06-08 at 14:40 -0700, David Brownell wrote: Right. OHCI was just an example though ... there are lots of other platform drivers for PXA. I'm not sure they all check for platform_data before succeeding in their probe() methods. The implementations in mainline generally use all the bits or they'd have been fixed by now so its not really a problem. I'm sure Russell would take patches :) The easiest solution might be to move the ohci device registration into pxa_set_ohci_info (in pxa27x.c). I gave in and appended a patch (compile tested only so far). Looked OK to me. That's the kind of approach now used with OMAP and AT91, and which IMO would be appropriate to use for most platform devices ... that is, don't register devices that the board doesn't have. One additional nuance: if the kernel doesn't have that driver configured, that's another reason not to bother registering its device. This is where you start to add ugly ifdefs and generally start making the code look horrible. The device model separated the drivers and the devices to deal with this issue as I see it. Generally I'd say its cleaner just to let the device register, then if a module comes along at some later point, the device is there for it. Cheers, Richard ___ 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 disconnect race in usbnet
On Thursday 08 June 2006 12:18 pm, Daniel Drake wrote: However, netif_stop_queue() may return with transmissions still running on other CPUs - I think netif_tx_disable() is what is needed, which guarantees that no transmissions are active when it returns. Do you agree that this is a potential race? Hmm, most drivers call netif_stop_queue() rather than netif_tx_disable(); a quick conversation with Mr. Grep shows only three uses of the latter. And with no documentation, it's a bit hard for me to agree (without diving deeper into the network stack than I have time for). Maybe it'd be good to ask over on netdev whether that argument shouldn't be applied to pretty much every network driver... That said, I don't see an obvious race there. If the device disconnects, there's now a guarantee that all pending urbs will have completed before the driver disconnect() method is called. (As of maybe 2.6.8 or so. The original 2.4 code of course couldn't rely on such guarantees. The lack of such guarantees meant a seemingly endless supply of oops-on-disconnect bugs.) So there is no way that an URB completion can trigger with an invalid device handle, which is I think the race you implied. Even if one CPU were able to submit an URB after the TX queue stopped, there'd be no trouble. - Dave ___ 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 hangs during small and large file transfer
Hello David Few dumb questions. Where in the driver source code would like to insert the dbg_qh() and dbg_qtd() ? Will turning on the ehci verbose debugging provide the information that you are looking for? Regards Vivek -Original Message- From: David Brownell [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 4:03 PM To: Vivek Dharmadhikari Cc: Alan Stern; USB development list Subject: Re: [linux-usb-devel] Usb hangs during small and large file transfer On Wednesday 07 June 2006 3:23 pm, Vivek Dharmadhikari wrote: How do i dump, QH and its associated QTDs ? Try dbg_qh() and dbg_qtd() ... see ehci-dbg.c for examples of scanning the qtd list. I don't see this happening ... it's not supposed to, and I just looked at how the bits affecting PING are managed in the EHCI driver to verify that it seems to be coded right. Can you elaborate more on the above. I did not understand it. See the EHCI spec and the ehci-q.c file ... the spec will show the bits (search for PING) and the code will show how they're manipulated. ___ 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 disconnect race in usbnet
David Brownell wrote: Hmm, most drivers call netif_stop_queue() rather than netif_tx_disable(); a quick conversation with Mr. Grep shows only three uses of the latter. And with no documentation, it's a bit hard for me to agree (without diving deeper into the network stack than I have time for). My source was LDD3, it has a section on transmission concurrency and states that netif_tx_disable is the same as netif_stop_queue but it additionally ensure that hard_start_xmit is running is not running on any CPU. That makes sense from the implementation too - it relies on taking the lock which is taken over the hard_start_xmit call. Maybe it'd be good to ask over on netdev whether that argument shouldn't be applied to pretty much every network driver... I will ask there. I think it probably depends on the situation, and if there is any danger of race in each case. In this case the danger is that hard_start_xmit is still running when free_netdev is called, maybe this does not apply in other cases. That said, I don't see an obvious race there. If the device disconnects, there's now a guarantee that all pending urbs will have completed before the driver disconnect() method is called. (As of maybe 2.6.8 or so. The original 2.4 code of course couldn't rely on such guarantees. The lack of such guarantees meant a seemingly endless supply of oops-on-disconnect bugs.) That's interesting, thanks for pointing it out (helps me with my WLAN driver a little), but this race isn't related to urbs. So there is no way that an URB completion can trigger with an invalid device handle, which is I think the race you implied. Even if one CPU were able to submit an URB after the TX queue stopped, there'd be no trouble. The issue I am looking at is that usbnet_start_xmit may be running concurrently to the disconnect function. usbnet_start_xmit is not an URB completion, it's a hook into the network layer (hard_start_xmit). The issue is that usbnet_start_xmit uses structures which are freed in the disconnect function. Am I making sense? Daniel ___ 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] limit power budget on spitz
On Thursday 08 June 2006 2:49 pm, Richard Purdie wrote: The easiest solution might be to move the ohci device registration into pxa_set_ohci_info (in pxa27x.c). I gave in and appended a patch (compile tested only so far). Looked OK to me. That's the kind of approach now used with OMAP and AT91, and which IMO would be appropriate to use for most platform devices ... that is, don't register devices that the board doesn't have. One additional nuance: if the kernel doesn't have that driver configured, that's another reason not to bother registering its device. This is where you start to add ugly ifdefs and generally start making the code look horrible. The device model separated the drivers and the devices to deal with this issue as I see it. Enumeration is a separate issue. You wouldn't argue that every potential PCI or USB device must get registered, right? Only the ones that are actually _present_ get registered. But here you argue that platform bus should not work that same way ... it should register devices that can't be present. If nothing else, that's an inconsistent aproach. Plus, consider the common situation that a given pin could potentially be used with several different devices. On a given board, only one of those devices will be wired up. It's counterproductive to register any of the others ... error prone, waste-of-kernel-address-space, etc. Generally I'd say its cleaner just to let the device register, then if a module comes along at some later point, the device is there for it. Whether the device is there or not is a hardware issue. Board schematics will show which devices are relevant ... registering any others is just wastage. Clean is somewhat in the eye of the beholder; in mine, wasting system resources is not clean. - Dave ___ 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] gadget-serial: fix a deadlock when closing the serial device
ping
Franck Bui-Huu wrote:
When closing the device, the driver acquires/release twice the
port lock before/after waiting for the data to be completely
sent.
It also uses the generic scheduler function for waiting for an
event.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
well I'm probably missing something with these macros but don't
see what...
drivers/usb/gadget/serial.c | 87
---
1 files changed, 9 insertions(+), 78 deletions(-)
51b89a6d3912a4bb1cba19ee1e0a3723b5fb2309
diff --git a/drivers/usb/gadget/serial.c b/drivers/usb/gadget/serial.c
index b992546..66285e3 100644
--- a/drivers/usb/gadget/serial.c
+++ b/drivers/usb/gadget/serial.c
@@ -51,82 +51,10 @@ #include linux/usb_gadget.h
#include gadget_chips.h
-/* Wait Cond */
-
-#define __wait_cond_interruptible(wq, condition, lock, flags, ret) \
-do { \
- wait_queue_t __wait;\
- init_waitqueue_entry(__wait, current); \
- \
- add_wait_queue(wq, __wait); \
- for (;;) { \
- set_current_state(TASK_INTERRUPTIBLE); \
- if (condition) \
- break; \
- if (!signal_pending(current)) { \
- spin_unlock_irqrestore(lock, flags);\
- schedule(); \
- spin_lock_irqsave(lock, flags); \
- continue; \
- } \
- ret = -ERESTARTSYS; \
- break; \
- } \
- current-state = TASK_RUNNING; \
- remove_wait_queue(wq, __wait);\
-} while (0)
-
-#define wait_cond_interruptible(wq, condition, lock, flags) \
-({ \
- int __ret = 0; \
- if (!(condition)) \
- __wait_cond_interruptible(wq, condition, lock, flags, \
- __ret); \
- __ret; \
-})
-
-#define __wait_cond_interruptible_timeout(wq, condition, lock, flags,
\
- timeout, ret) \
-do { \
- signed long __timeout = timeout;\
- wait_queue_t __wait;\
- init_waitqueue_entry(__wait, current); \
- \
- add_wait_queue(wq, __wait); \
- for (;;) { \
- set_current_state(TASK_INTERRUPTIBLE); \
- if (__timeout == 0) \
- break; \
- if (condition) \
- break; \
- if (!signal_pending(current)) { \
- spin_unlock_irqrestore(lock, flags);\
- __timeout = schedule_timeout(__timeout);\
- spin_lock_irqsave(lock, flags); \
- continue; \
- } \
- ret = -ERESTARTSYS; \
- break; \
- } \
- current-state = TASK_RUNNING; \
- remove_wait_queue(wq, __wait);\
-} while (0)
-
-#define wait_cond_interruptible_timeout(wq, condition, lock, flags, \
- timeout)\
-({ \
- int __ret =
Re: [linux-usb-devel] [PATCH] limit power budget on spitz
On Thu, 8 Jun 2006, David Brownell wrote: On Thursday 08 June 2006 2:49 pm, Richard Purdie wrote: One additional nuance: if the kernel doesn't have that driver configured, that's another reason not to bother registering its device. This is where you start to add ugly ifdefs and generally start making the code look horrible. The device model separated the drivers and the devices to deal with this issue as I see it. Enumeration is a separate issue. You wouldn't argue that every potential PCI or USB device must get registered, right? Only the ones that are actually _present_ get registered. You are both saying the same thing so far. But here you argue that platform bus should not work that same way ... it should register devices that can't be present. If nothing else, that's an inconsistent aproach. That's not what Richard is saying. He replied to your assertion where you said: if the kernel doesn't have that driver configured, that's another reason not to bother registering its device to which he disagreed, and I disagree too. Plus, consider the common situation that a given pin could potentially be used with several different devices. On a given board, only one of those devices will be wired up. It's counterproductive to register any of the others ... error prone, waste-of-kernel-address-space, etc. No one disagreed with that AFAICS. Generally I'd say its cleaner just to let the device register, then if a module comes along at some later point, the device is there for it. Whether the device is there or not is a hardware issue. Board schematics will show which devices are relevant ... registering any others is just wastage. But you originally talked about _driver_ configuration dictating if a _device_ should be registered or not. The _device_ should indeed be registered based on _hardware_ config, not _driver_ config. Nicolas ___ 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] limit power budget on spitz
On Thursday 08 June 2006 6:25 pm, Nicolas Pitre wrote: You are both saying the same thing so far. Hey, violent agreement is half the fun! :) But here you argue that platform bus should not work that same way ... it should register devices that can't be present. If nothing else, that's an inconsistent aproach. That's not what Richard is saying. He replied to your assertion where you said: if the kernel doesn't have that driver configured, that's another reason not to bother registering its device to which he disagreed, and I disagree too. I see your point. Yes, this is arguable ... there are multiple principles that can be traded off against each other. For example, by default, make design choices that save memory (what I was using) versus: The _device_ should indeed be registered based on _hardware_ config, not _driver_ config. For a kernel without CONFIG_MODULES, that's pure wasted space. Why bother? Those are devices that can't be present, so that's one of the cases where that ignore the driver config policy will indeed register such devices. Similarly, when the driver's not yet written, it can make trouble to try sticking its config into the device tree ... it's very easy to get wrong! It's clear to me there are some cases where software config will reasonably be a subset of the hardware config. Likewise, that memory usage should be one of the factors considered when making design tradeoffs. - Dave ___ 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] No EHCI IRQ reported when device is connected
On Thursday 08 June 2006 12:50 am, rakesh kn wrote: 1) When a OTG hard disk(Self Powered) was connected, there was no interrupt and my ehci_irq interrupt handler was not invoked. When i power on the device i get a DISCONNECT event from the device and the PORTSCx value changes to 0x8c001002 (CCS = 0,CSC =1) and IRQ IS GENERATED . STATUS register shows Port Change Detect Interrupt (STS = 0x8C). So when the hub_events() tries to do a GetPortStatus, it does not find connection(CCS =0) and the hub_port_connect_change() function returns. Also PORT-ENABLE bit in PORTSCx is not 1. That means that even though a device was connected, the port is not enabled. At a guess, this disk was using SRP to wake the host? That's kind of messy in the code today ... OHCI was faking it in the root hub with help from an external OTG transceiver, but I suspect that you'll need a different approach with EHCI and an integrated one. 2) When a USB2.0 HS speed device(thumb drive or Camera) was connected to the board, there is no interrupt genearated. This is visible from cat /proc/interrupts. How can interpret the above 2 observations. I am getting PCD interrupts for disconnect event from a device(OTG) , after that was connected and powered on. For other devices i am not getting interrupt. Is the port powered on? Remember, an OTG host might be kind of aggressive about turning off VBUS. Plus there are at least two different ways to connect a device to an OTG host: - plug cable into B-device, then Mini-A into A-device. -- should get an IRQ for ID pin grounded, which is handled by turning on VBUS and then enumerating - Plug Mini-A into A-device, then Mini-B into B-Device -- ID pin grounded irq will fail enumeration since there's no device. In that case the B-device must use SRP to restart enumeration Some non-OTG devcies will work with both schemes; others won't. ___ 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] ANNOUNCE: Linux UWB and Wireless USB project
On Monday 05 June 2006 1:31 pm, Perez-Gonzalez, Inaky wrote: From: Pavel Machek [mailto:[EMAIL PROTECTED] Is there any hardware available? I think some companies are starting to make PDKs available this summer, but YMMV. Actually ISTR the WUSB team at www.usb.org had press releases talking about rather bulky PDK + radio kits last winter. Since then I think I've heard about at least four teams working on Real Silicon (and I'm not in those loops at all, so I believe there must be others). At one point I saw diagrams showing UWB as the platform over which USB, Bluetooth, Firewire, and network peripheral models would get layered. Home mesh networking, anyone? The notion of authenticating peripherals to Linux will take a bit of getting used to, I expect ... that's part of the wireless USB model. RSA and private key management will be getting a bit of a workout... - Dave ___ 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] limit power budget on spitz
On Thu, 8 Jun 2006, David Brownell wrote: On Thursday 08 June 2006 6:25 pm, Nicolas Pitre wrote: He replied to your assertion where you said: if the kernel doesn't have that driver configured, that's another reason not to bother registering its device to which he disagreed, and I disagree too. I see your point. Yes, this is arguable ... there are multiple principles that can be traded off against each other. For example, by default, make design choices that save memory (what I was using) versus: The _device_ should indeed be registered based on _hardware_ config, not _driver_ config. For a kernel without CONFIG_MODULES, that's pure wasted space. Why bother? Those are devices that can't be present, so that's one of the cases where that ignore the driver config policy will indeed register such devices. But constrained hardware designs for which memory usage is important that have the device available are likely to make use of that device anyway. So in those cases it is pretty unlikely that the kernel config won't include the corresponding driver. The case where the hardware does support a device but someone decided not to use it may have its kernel config exclude the corresponding driver. But since this is most probably not the common case I don't think we should go as far as uglifying the code with conditional device registrations based on #if !defined(CONFIG_MODULE) !defined(CONFIG_FOO) just for the sake of saving as many bytes as possible. That someone may as well comment out that device registration in his own source tree himself. It is more likely that some hardware design that is not expected to use a particular device will simply not register that device in the first place and its default kernel config won't have the driver selected either. In that sense I think Richard's patch is all that is needed for mainline. Nicolas ___ 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] No EHCI IRQ reported when device is connected
On Thursday 08 June 2006 12:50 am, rakesh kn wrote: 1) When a OTG hard disk(Self Powered) was connected, there was no interrupt and my ehci_irq interrupt handler was not invoked. When i power on the device i get a DISCONNECT event from the device and the PORTSCx value changes to 0x8c001002 (CCS = 0,CSC =1) and IRQ IS GENERATED . STATUS register shows Port Change Detect Interrupt (STS = 0x8C). So when the hub_events() tries to do a GetPortStatus, it does not find connection(CCS =0) and the hub_port_connect_change() function returns. Also PORT-ENABLE bit in PORTSCx is not 1. That means that even though a device was connected, the port is not enabled. At a guess, this disk was using SRP to wake the host? That's kind of messy in the code today ... OHCI was faking it in the root hub with help from an external OTG transceiver, but I suspect that you'll need a different approach with EHCI and an integrated one. I am working on an ARM based OTG system. What is the otg disk drive? I have not been able to find otg devices to test the system withany suggestions? Being able to buy cheap consumer hardware for testing implementations is invaluable. Regards, ~Steve ___ 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] No EHCI IRQ reported when device is connected
On Thursday 08 June 2006 7:36 pm, Steve Calfee wrote: I am working on an ARM based OTG system. What is the otg disk drive? I'm not the person who mentioned one of those. When I needed such a beast, I've had to craft one with a Linux development board. There's the USB-IF OTG test suite too. I have not been able to find otg devices to test the system withany suggestions? Being able to buy cheap consumer hardware for testing implementations is invaluable. I don't know of any, but in a few months the AVR USB keys should be more widely available at about $32/each: http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3879 Some time spent with avr-gcc should produce some test devices, cheap modulo that time spent. - Dave ___ 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 disconnect race in usbnet
On Thu, 8 Jun 2006, David Brownell wrote: That said, I don't see an obvious race there. If the device disconnects, there's now a guarantee that all pending urbs will have completed before the driver disconnect() method is called. (As of maybe 2.6.8 or so. The original 2.4 code of course couldn't rely on such guarantees. The lack of such guarantees meant a seemingly endless supply of oops-on-disconnect bugs.) But there's no guarantee that URBs submitted _after_ the disconnect method has returned will fail. (Of course, if the device really has been unplugged then they definitely will fail, but if the driver has merely been unbound from the interface then they might not.) Drivers do need to have sufficient synchronization to avoid this problem. Hmmm, I see that usb-skeleton does _not_ provide the necessary checks. Looks like an opportunity for a patch... Alan Stern ___ 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 disconnect race in usbnet
On Thursday 08 June 2006 8:26 pm, Alan Stern wrote: On Thu, 8 Jun 2006, David Brownell wrote: That said, I don't see an obvious race there. If the device disconnects, there's now a guarantee that all pending urbs will have completed before the driver disconnect() method is called. (As of maybe 2.6.8 or so. The original 2.4 code of course couldn't rely on such guarantees. The lack of such guarantees meant a seemingly endless supply of oops-on-disconnect bugs.) But there's no guarantee that URBs submitted _after_ the disconnect method has returned will fail. Yes there is ... they fail during submit, since the device is marked as gone. Submits start failing even before disconnect() is called. (Of course, if the device really has been unplugged then they definitely will fail, but if the driver has merely been unbound from the interface then they might not.) Drivers do need to have sufficient synchronization to avoid this problem. Well, the specific scenario here was errors on unplug, not rmmod; and I'd call it an error if URBs could be submitted to endpoints that aren't bound to some driver. (Yep, likely we have bugs in that space.) - Dave ___ 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 disconnect race in usbnet
On Thu, 8 Jun 2006, David Brownell wrote: On Thursday 08 June 2006 8:26 pm, Alan Stern wrote: On Thu, 8 Jun 2006, David Brownell wrote: That said, I don't see an obvious race there. If the device disconnects, there's now a guarantee that all pending urbs will have completed before the driver disconnect() method is called. (As of maybe 2.6.8 or so. The original 2.4 code of course couldn't rely on such guarantees. The lack of such guarantees meant a seemingly endless supply of oops-on-disconnect bugs.) But there's no guarantee that URBs submitted _after_ the disconnect method has returned will fail. Yes there is ... they fail during submit, since the device is marked as gone. Submits start failing even before disconnect() is called. Not if the disconnect was for unbind only, as opposed to unplug. (Of course, if the device really has been unplugged then they definitely will fail, but if the driver has merely been unbound from the interface then they might not.) Drivers do need to have sufficient synchronization to avoid this problem. Well, the specific scenario here was errors on unplug, not rmmod; Maybe my memory is going... I thought Daniel said the problem would occur when the disconnect() method runs. In other words during unbind as opposed to during either unplug or rmmod. and I'd call it an error if URBs could be submitted to endpoints that aren't bound to some driver. (Yep, likely we have bugs in that space.) The problem is that the endpoints might indeed be bound -- but to a different driver! That is, driver A is unbound from an interface and driver B is then bound to it. What happens if driver A continues to submit URBs? Alan Stern ___ 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] No EHCI IRQ reported when device is connected
Hi David, Infact i am working on the ARM based board with ARC OTG Contrller and an SMSC USB3000 ULPI Transceiver, which has an mini-AB receptacle. I connected the OTG Hard disk to a linux pc running kernel 2.6.11.10 using a Mini-B to Standard-A USB Cable. I could get the interrupt in the linux pc, which has the Intel USB Host controller. The linux PC could easily recognize the harddisk and finished enumeration.I could mount the hard disk and then copy files in to it. For this ARM board I have configured the USB-OTG controller in to HOST Mode. So when i connect the OTG-hardisk , the hardisk is first disconnecting , which is also the same behaviour when i connect to the linux pc. After this happens, the OTG-device is reconnecting,evident from PORTSCx (CCS =1,CSC =1) in the linux PC, BUT this reconnecting is not happening in the ARM board ARC-OTG controller. The PORTSCx shows PP (VBUS) port power bit is always set. Even when i connect a Thumb Drive using a Mini-A to Standard A convertor cable to the ARM Board, the connection is not generating an interrupt. The PORT POWER bit = 1 when i checked the PORTSCx register. I connected both ways u have mentioned, but there is no change. MY doubt is, ...? Do I have to worry about the ID Pin interrupt when i am in the HOST MODE in the ARC OTG Controller. When i put the CONTROLLER in to HOST MODE, all the PORTSCx registers behave similar to the EHCI controller rt? Thanks, Rak On 6/9/06, David Brownell [EMAIL PROTECTED] wrote: On Thursday 08 June 2006 12:50 am, rakesh kn wrote: 1) When a OTG hard disk(Self Powered) was connected, there was no interrupt and my ehci_irq interrupt handler was not invoked. When i power on the device i get a DISCONNECT event from the device and the PORTSCx value changes to 0x8c001002 (CCS = 0,CSC =1) and IRQ IS GENERATED . STATUS register shows Port Change Detect Interrupt (STS = 0x8C). So when the hub_events() tries to do a GetPortStatus, it does not find connection(CCS =0) and the hub_port_connect_change() function returns. Also PORT-ENABLE bit in PORTSCx is not 1. That means that even though a device was connected, the port is not enabled. At a guess, this disk was using SRP to wake the host? That's kind of messy in the code today ... OHCI was faking it in the root hub with help from an external OTG transceiver, but I suspect that you'll need a different approach with EHCI and an integrated one. 2) When a USB2.0 HS speed device(thumb drive or Camera) was connected to the board, there is no interrupt genearated. This is visible from cat /proc/interrupts. How can interpret the above 2 observations. I am getting PCD interrupts for disconnect event from a device(OTG) , after that was connected and powered on. For other devices i am not getting interrupt. Is the port powered on? Remember, an OTG host might be kind of aggressive about turning off VBUS. Plus there are at least two different ways to connect a device to an OTG host: - plug cable into B-device, then Mini-A into A-device. -- should get an IRQ for ID pin grounded, which is handled by turning on VBUS and then enumerating - Plug Mini-A into A-device, then Mini-B into B-Device -- ID pin grounded irq will fail enumeration since there's no device. In that case the B-device must use SRP to restart enumeration Some non-OTG devcies will work with both schemes; others won't. ___ 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] platform_device.dev.release not getting called under X Windows
Hi all, We are developing a device driver for a PCMCIA based USB Host Controller. We are facing an issue in the operation of the driver under X Windows. In the PCMCIA client driver, we register a platform device. Through this platform device, we are passing the resources to the Host Controller Driver. The HCD is using these resources for driving the Host Controller. The issue arises for the following situation under X Windows. 1. Insert a USB mass storage device 2. Mount the device. 3. While transfer is in progress, remove the PC card. In this situation, we have noted that the platform_device.dev.release function is not getting called. If we do not mount the device, then the release function is getting called. Can anyone please tell why this may be happening? When we operate from console, we are not facing the issue. In that case the release function is getting called properly. Then does the issue have anything to do with X Windows? Looking forward to your suggestions Thank you, With Regards, Kaustav Majumdar ___ 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 disconnect race in usbnet
Am Donnerstag, 8. Juni 2006 23:55 schrieb David Brownell: Maybe it'd be good to ask over on netdev whether that argument shouldn't be applied to pretty much every network driver... Yes That said, I don't see an obvious race there. If the device disconnects, there's now a guarantee that all pending urbs will have completed before the driver disconnect() method is called. (As of maybe 2.6.8 or so. The Even in case of disconnect by sysfs or usbfs? original 2.4 code of course couldn't rely on such guarantees. The lack of such guarantees meant a seemingly endless supply of oops-on-disconnect bugs.) So there is no way that an URB completion can trigger with an invalid device handle, which is I think the race you implied. Even if one CPU were able to submit an URB after the TX queue stopped, there'd be no trouble. Isn't that a memleak? If you can submit it without it completing, how can you free it? Regards Oliver ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
