[linux-usb-devel] [PATCH] USB speedtouch: cosmetic comment changes
speedtouch.c | 53 ++---
1 files changed, 14 insertions(+), 39 deletions(-)
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/usb/misc/speedtouch.c Tue Mar 18 09:51:58 2003
+++ b/drivers/usb/misc/speedtouch.c Tue Mar 18 09:51:58 2003
@@ -690,15 +690,9 @@
}
-/
-** ATM **
-/
-
-/***
-*
-* init functions
-*
-/
+/**
+** ATM **
+**/
static void udsl_atm_dev_close (struct atm_dev *dev)
{
@@ -718,13 +712,6 @@
dev-dev_data = NULL;
}
-
-/***
-*
-* ATM helper functions
-*
-/
-
static int udsl_atm_proc_read (struct atm_dev *atm_dev, loff_t *pos, char *page)
{
struct udsl_instance_data *instance = atm_dev-dev_data;
@@ -778,13 +765,6 @@
return 0;
}
-
-/***
-*
-* SAR driver entries
-*
-/
-
static int udsl_atm_open (struct atm_vcc *vcc, short vpi, int vci)
{
struct udsl_instance_data *instance = vcc-dev-dev_data;
@@ -866,9 +846,9 @@
}
-/
-** USB **
-/
+/**
+** USB **
+**/
static int udsl_usb_ioctl (struct usb_interface *intf, unsigned int code, void
*user_data)
{
@@ -1180,11 +1160,9 @@
}
-/***
-*
-* Driver Init
-*
-/
+/***
+** init **
+***/
static int __init udsl_usb_init (void)
{
@@ -1215,13 +1193,11 @@
MODULE_LICENSE (GPL);
-#ifdef DEBUG_PACKET
-/***
-*
-* Debug
-*
-***/
+/
+** debug **
+/
+#ifdef DEBUG_PACKET
static int udsl_print_packet (const unsigned char *data, int len)
{
unsigned char buffer [256];
@@ -1237,5 +1213,4 @@
}
return i;
}
-
-#endif /* PACKETDEBUG */
+#endif
---
This SF.net email is sponsored by: Does your code think in ink?
You could win a Tablet PC. Get a free Tablet PC hat just for playing.
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH]fix to synchronous API regarding memory allocation
Hi,
some part of the synchronous API is used in the block io error handling
code paths. Therefore it may use only GFP_NOIO, not GFP_KERNEL.
Greg, please apply.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===
[EMAIL PROTECTED], 2003-03-18 10:08:40+01:00, [EMAIL PROTECTED]
- avoid deadlock due to wrong memory allocation in block io path
message.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -Nru a/drivers/usb/core/message.c b/drivers/usb/core/message.c
--- a/drivers/usb/core/message.c Tue Mar 18 10:21:55 2003
+++ b/drivers/usb/core/message.c Tue Mar 18 10:21:55 2003
@@ -88,7 +88,7 @@
int retv;
int length;
- urb = usb_alloc_urb(0, GFP_KERNEL);
+ urb = usb_alloc_urb(0, GFP_NOIO);
if (!urb)
return -ENOMEM;
@@ -131,7 +131,7 @@
int usb_control_msg(struct usb_device *dev, unsigned int pipe, __u8 request, __u8 requesttype,
__u16 value, __u16 index, void *data, __u16 size, int timeout)
{
- struct usb_ctrlrequest *dr = kmalloc(sizeof(struct usb_ctrlrequest), GFP_KERNEL);
+ struct usb_ctrlrequest *dr = kmalloc(sizeof(struct usb_ctrlrequest), GFP_NOIO);
int ret;
if (!dr)
===
This BitKeeper patch contains the following changesets:
1.1469
## Wrapped with gzip_uu ##
begin 664 bkpatch19037
M'XL(`#/E=CX``ZU584_;,!#]7/^*D_@8TWLV'33IV`L3'$-HF/J,DOJ91
[EMAIL PROTECTED]/WY.BLJH6C0ZJJA-GO[^Z]7O;@ND(S[.EY8[,%775EWB:4N
MT9OJ!Z+LO[E:9.[X)[EMAIL PROTECTED](7-(XL=D47*P:]IC'
M5W?LPRT.U?SZZ_'5\1,[EMAIL PROTECTED]))T=J1KGWLSH9-H^KUF%FX!2
[EMAIL PROTECTED]JJ,235,[EMAIL PROTECTED]LSO7ASBEG$:4B$F%#9PB
M@K,8T+0+GO#A8!HT,:#04]IQ(*2P;/-HTC@,H$_)[EMAIL PROTECTED]
MH#!1YW-PU7!O=)G#`A?:/$`R=Z'$%KJ$HH2TRRLTW[EMAIL PROTECTED]`C)\F
M2OJO_!!$TH^;NCHI+`7B+=.:[297^2E-KC'!=AS!L1#C*14E0JB@:1R^-
MOL4JF8RI`WDDDN'*DU995I83O+^9DK\Q=854F.7M8!%0ZB%`()AMI8B;
MB0P=S0*G+0/'[EMAIL PROTECTED]:\,_*F7C9[O=AKMM[^_P%C$II.!-$NY
M='H0//Y'(;\7WS.WM+GQTJA[EMAIL PROTECTED];J(C\.;%Y5UMEX:
MX!+ZYKX[G$_'Z[EMAIL PROTECTED]/'[EMAIL PROTECTED];[EMAIL PROTECTED]9_Q()#.A['DGI\
ML)O*;IL%;[EMAIL PROTECTED],OXYOOE^66KZ]IV*R9MAGI:8VB,-N`I1RGW,G_;'6
M5-\^CQVT/XU;Z[EMAIL PROTECTED]/4^?;_JX.`#.65M/G+GUYE39W9
MKB*S9F[P9XV5A7?*.)S9HD/9KXK?J?[FW,/GLO7I'9%+-952]BH4LD`S)
)'[EMAIL PROTECTED]
`
end
[linux-usb-devel] reading 'count' bytes, or less?
Hello, I'm writing a driver for a data aquisition device based on the FX2. The device is generating packets of different sizes. I'd like to have a function that reads all data that's available and return as quickly as possible (something like recv() for socket operations actually, ideally it should return after the first NAK of the device). I can do this at the moment by doing a usb_submit_urb() for 512 bytes repeatedly, but then you only get to transfer one packet per microframe even if the device has more than that in it's internal buffers, so this is not the most efficient method. Would there be a better method of doing this? The data returned is structured in 16-byte packets, so I don't need to know the packet boundaries. Thanks in advance, Wim Heirman. --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] e400: host controller halted. very bad
This is with latest Linus BK. From the system log, during boot: kernel: drivers/usb/class/usblp.c: usblp0: nonzero read/write bulk status received: -104 kernel: drivers/usb/class/usblp.c: usblp0: error -104 reading from printer kernel: drivers/usb/host/uhci-hcd.c: e400: host controller process error. something bad happened kernel: drivers/usb/host/uhci-hcd.c: e400: host controller halted. very bad ptal-mlcd: ERROR at ExMgr.cpp:2844, dev=mlc:usb:PSC_750xi@/dev/usb/lp0, pid=512, e=4 llioService: llioWrite returns -1, expected=6! ptal-mlcd: ERROR at ExMgr.cpp:902, dev=mlc:usb:PSC_750xi@/dev/usb/lp0, pid=512, e=4 exClose(reason=0x0011) lspci: 00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333] 00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP] 00:06.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 00:06.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) 00:07.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01) 00:0a.0 USB Controller: VIA Technologies, Inc. USB (rev 04) 00:10.0 USB Controller: VIA Technologies, Inc. USB (rev 80) 00:10.1 USB Controller: VIA Technologies, Inc. USB (rev 80) 00:10.2 USB Controller: VIA Technologies, Inc. USB (rev 80) 00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586/B/686A/B PIPC Bus Master IDE (rev 06) 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233 AC97 Audio Controller (rev 50) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon 7500] /proc/bus/usb/devices (using 2.4): T: Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB UHCI-alt Root Hub S: SerialNumber=e000 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB UHCI-alt Root Hub S: SerialNumber=e400 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=ff(vend.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=06b9 ProdID=4061 Rev= 0.00 S: Manufacturer=ALCATEL S: Product=Speed Touch USB S: SerialNumber=0090D02C2C5A C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbdevfs E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=50ms I: If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch I: If#= 1 Alt= 1 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I: If#= 1 Alt= 2 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch E: Ad=06(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I: If#= 1 Alt= 3 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch E: Ad=06(O) Atr=02(Bulk) MxPS= 16 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 16 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbdevfs E: Ad=05(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB UHCI-alt Root Hub S: SerialNumber=e800 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB UHCI-alt Root Hub S: SerialNumber=ec00 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 6 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 2.04 S: Manufacturer=Linux 2.4.21-pre5 ehci-hcd S: Product=VIA
Re: [linux-usb-devel] [PATCH]fix to synchronous API regarding memoryallocation
On Tue, 18 Mar 2003, Oliver Neukum wrote: Hi, some part of the synchronous API is used in the block io error handling code paths. Therefore it may use only GFP_NOIO, not GFP_KERNEL. Greg, please apply. Oliver, is this meant to refer to the usb-storage module or to something else? For usb-storage it's true that the synchronous API is used in the I/O error handling code paths. But those code paths always execute in the context of a kernel thread -- the SCSI error-handler thread -- with no semaphores held, so it's perfectly okay for them to use GFP_KERNEL. Alan Stern --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Synchronous API changes (was Asynch)
On Mon, 17 Mar 2003, David Brownell wrote: Indeed there is a problem. Yet we cannot simply change them all to use interruptible sleep. You cannot stop in the middle of usb_reset_device() or similar calls. Only done by SCSI EH handler threads for now though, yes? Those could have a block all signals policy if it wants; maybe it does so already. Yes it does. (Unless it has changed since I last looked at it.) The same kind of thing holds true for khubd and enumeration. Any task doing a config change (like set_interface) should block signals, but otherwise I suspect all synchronous calls should be interruptible by default ... though someone ought to look for other cases where that's not true. Should we simply add a flag to the synchronous calls or add interruptible versions? Aren't those two options identical? Both are API syntax changes. :) I agree with David's proposal above; just make usb_bulk_msg() and usb_control_msg() interruptible. But what about synchronous usb_unlink_urb()? Alan Stern --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH]fix to synchronous API regarding memoryallocation
Am Dienstag, 18. März 2003 16:12 schrieb Alan Stern: On Tue, 18 Mar 2003, Oliver Neukum wrote: Hi, some part of the synchronous API is used in the block io error handling code paths. Therefore it may use only GFP_NOIO, not GFP_KERNEL. Greg, please apply. Oliver, is this meant to refer to the usb-storage module or to something else? For usb-storage it's true that the synchronous API is used in the Mainly usb-storage, but there's no reason a network driver used by nfs might not suffer from a stall needing to be cleared. I/O error handling code paths. But those code paths always execute in the context of a kernel thread -- the SCSI error-handler thread -- with no semaphores held, so it's perfectly okay for them to use GFP_KERNEL. How can that be? The SCSI layer guarantees that no further requests are issued while the error handler is running. Regards Oliver --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Synchronous API changes (was Asynch)
Should we simply add a flag to the synchronous calls or add interruptible versions? Aren't those two options identical? Both are API syntax changes. :) I agree with David's proposal above; just make usb_bulk_msg() and usb_control_msg() interruptible. But what about synchronous usb_unlink_urb()? IMHO that's not a good idea. If we change behaviour without syntax we'll spend weeks chasing signal handling bugs. For usb_bulk_msg() the issue is easy, but for control messages it is not. Regards Oliver --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Synchronous API changes (was Asynch)
The same kind of thing holds true for khubd and enumeration. Any task doing a config change (like set_interface) should block signals, but otherwise I suspect all synchronous calls should be interruptible by default ... though someone ought to look for other cases where that's not true. Should we simply add a flag to the synchronous calls or add interruptible versions? Aren't those two options identical? Both are API syntax changes. :) I agree with David's proposal above; just make usb_bulk_msg() and usb_control_msg() interruptible. But what about synchronous usb_unlink_urb()? That wasn't exactly my proposal, for the reason Oliver mentioned: we'd destabilize drivers that don't behave as they should. Better to define a new call and selectively convert drivers to use it. And implemenation-wise ... we can use the newish linux/wait.h macros wait_event_interruptible, although that mis-accounts for tasks in I/O wait. - Dave --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Synchronous API changes (was Asynch)
Alan Stern wrote: If you mean that nobody has ever needed to cancel just a single synchronous message except as part of cancelling all of them for a disconnect, I agree. Yes. Same is true when the driver uses asynchronous models too. Surely you don't mean to say that drivers call usb_unlink_urb() with the URB_ASYNC_UNLINK flag set only during disconnect()? No. But when would it be appropriate to unlink one request from the middle of an endpoint's queue? At best that's an esoteric and very error-prone case. And a good rule of thumb for designs is to get rid of all such models. I see. You mean that whenever an unlink occurs, whether synchronous or not, the driver really wants to unlink all the urbs queued for that endpoint. But remember that, unlikely though it may be, it is possible for more than one driver to have requests queued for ep 0 at the same time. If one needs to cancel its request, you're still stuck with all the problems of unlinking a request from the middle of an output queue. Since control endpoints (like ep0) are the only non-stream endpoints in USB, it's perhaps no surprise to find that they might be the (only?) example of a case where an unlink one request is really the appropriate model ... all other endpoints involve uni-directional data streaming. How does your patch know which interface a request is intended for? Looks at the endpoint addressing information. Again, what about requests for endpoint 0? Again, see above. In the rare cases that matters, we have a simple solution that'll work in most cases. How will your simple solution work in the situation where two drivers are bound to different interfaces on the same device and one of the drivers is rmmod'ed? How does your patch prevent the core from accepting urbs for ep 0 from the driver being unloaded while still allowing submissions from the other driver? Or is this something that has never yet come up and will be dealt with when it really matters? It's never come up and could be dealt with if it turns out to matter. - Dave --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH]fix to synchronous API regardingmemoryallocation
On Tue, 18 Mar 2003, Oliver Neukum wrote: Am Dienstag, 18. März 2003 16:12 schrieb Alan Stern: On Tue, 18 Mar 2003, Oliver Neukum wrote: Hi, some part of the synchronous API is used in the block io error handling code paths. Therefore it may use only GFP_NOIO, not GFP_KERNEL. Greg, please apply. Oliver, is this meant to refer to the usb-storage module or to something else? For usb-storage it's true that the synchronous API is used in the Mainly usb-storage, but there's no reason a network driver used by nfs might not suffer from a stall needing to be cleared. I suppose that it might. But if the network driver isn't executing in a context where it can sleep then it shouldn't be using the synchronous API in the first place. In short, since the synchronous calls are allowed and expected to block, there's no reason for them not to use GFP_KERNEL. I/O error handling code paths. But those code paths always execute in the context of a kernel thread -- the SCSI error-handler thread -- with no semaphores held, so it's perfectly okay for them to use GFP_KERNEL. How can that be? The SCSI layer guarantees that no further requests are issued while the error handler is running. Yes. The synchronous API calls you are concerned about are made from a subroutine that is called directly by the error handler and that runs in the context of the error handler thread. During the time this happens, the SCSI layer guarantees that no further requests are issued, either for block I/O or other error-handler stuff. Alan Stern --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Synchronous API changes (was Asynch)
On Tue, 18 Mar 2003, Oliver Neukum wrote: I agree with David's proposal above; just make usb_bulk_msg() and usb_control_msg() interruptible. But what about synchronous usb_unlink_urb()? IMHO that's not a good idea. If we change behaviour without syntax we'll spend weeks chasing signal handling bugs. For usb_bulk_msg() the issue is easy, but for control messages it is not. I'm not convinced there will be so many bugs. usb_bulk_msg() and usb_control_msg() both can fail already, in several different ways with several different error codes. This would just add another failure mode, in which the error code happens to be -EINTR. But the drivers should treat it much like any other error. That is, unless they try to do some sort of error recovery based on the return code -- then this would have to fall under the default unknown error case. Alan Stern --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] reading 'count' bytes, or less?
On Tue, Mar 18, 2003 at 11:39:42AM +0100, Wim Heirman wrote: Hello, I'm writing a driver for a data aquisition device based on the FX2. The device is generating packets of different sizes. I'd like to have a function that reads all data that's available and return as quickly as possible (something like recv() for socket operations actually, ideally it should return after the first NAK of the device). I can do this at the moment by doing a usb_submit_urb() for 512 bytes repeatedly, but then you only get to transfer one packet per microframe even if the device has more than that in it's internal buffers, so this is not the most efficient method. Would there be a better method of doing this? The data returned is structured in 16-byte packets, so I don't need to know the packet boundaries. Have you tried submitting more than one read urb? That might work out for you. greg k-h --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] reading 'count' bytes, or less?
Greg KH wrote: On Tue, Mar 18, 2003 at 11:39:42AM +0100, Wim Heirman wrote: Hello, I'm writing a driver for a data aquisition device based on the FX2. The device is generating packets of different sizes. I'd like to have a function that reads all data that's available and return as quickly as possible ... Have you tried submitting more than one read urb? That might work out for you. In fact, if it doesn't, let us know ... I'd say that'd be the right way to solve this problem! Each endpoint has a queue of requests; when one completes, the next starts. Your device should be NAKing if there's no more data available, and otherwise satisfying the request. Just make sure to keep a deep enough queue. And there might be some OS differences to pay attention to. The 2.5 kernels queue all transfer types, but on 2.4 some HCDs won't queue interrupt or control transfers (and for UHCI you need to use a special URB flag). - Dave --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] reading 'count' bytes, or less?
... (and for UHCI you need to use a special URB flag). For bulk. Duncan. --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Synchronous API changes (was Asynch)
Am Dienstag, 18. März 2003 20:03 schrieb Alan Stern: On Tue, 18 Mar 2003, Oliver Neukum wrote: I agree with David's proposal above; just make usb_bulk_msg() and usb_control_msg() interruptible. But what about synchronous usb_unlink_urb()? IMHO that's not a good idea. If we change behaviour without syntax we'll spend weeks chasing signal handling bugs. For usb_bulk_msg() the issue is easy, but for control messages it is not. I'm not convinced there will be so many bugs. usb_bulk_msg() and usb_control_msg() both can fail already, in several different ways with several different error codes. This would just add another failure mode, in which the error code happens to be -EINTR. But the drivers should treat it much like any other error. That is, unless they try to do some Nope, they must not. There are specific things to do in this case. You have to determine the number of bytes already transfered and either return that or EINTR. So you have to fix every single call if you change behaviour. And of course there could be very hard cases very transfers have to be in specific order and simply aborting isn't an option. Regards Oliver --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH]fix to synchronous API regardingmemoryallocation
How can that be? The SCSI layer guarantees that no further requests are issued while the error handler is running. Yes. The synchronous API calls you are concerned about are made from a subroutine that is called directly by the error handler and that runs in the context of the error handler thread. During the time this happens, the SCSI layer guarantees that no further requests are issued, either for block I/O or other error-handler stuff. But what happens if the vm subsystem waits for this IO to complete as is entirely legal with GFP_KERNEL allocations ? Regards Oliver --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH]fix to synchronous API regardingmemoryallocation
On Tue, 18 Mar 2003, Oliver Neukum wrote: How can that be? The SCSI layer guarantees that no further requests are issued while the error handler is running. Yes. The synchronous API calls you are concerned about are made from a subroutine that is called directly by the error handler and that runs in the context of the error handler thread. During the time this happens, the SCSI layer guarantees that no further requests are issued, either for block I/O or other error-handler stuff. But what happens if the vm subsystem waits for this IO to complete as is entirely legal with GFP_KERNEL allocations ? You mean, what if the VM subsystem is blocked because it can't fulfill the error-handler's GFP_KERNEL allocation request until the I/O is completed and the I/O can't complete until the error-handler fixes things up? I don't know. How do other subsystems handle this? Alan Stern --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Belkin Compact Flash card reader
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I've recently bought a USB Compact Flash card reader from Belkin on the recommendation of a friend who had no problem getting his working under Linux. Of course, Belkin seem to have changed something and I'm having trouble getting going. Initially I just couldn't get any sensible response from the reader. A single read operation worked ok (I could dd if=/dev/scsi/... of=temp and get an image of the whole disk) but any subsequent ops would fail, and attempts to read the partition table also fail since this apparently takes two reads. After some poking around I discovered that the failure was coming from a flag byte in a DMA buffer (bcs-Status or the 13th byte of urb-transfer_buffer depending on scope). I deduced the OS is sending commands which confuse the reader and making it flag an error. Comparing my model with my friend's, I discovered his was reporting 04e6:000a for manufacturer:model and mine is 55aa:b000. Also /proc/scsi/scsi reports mine as Vendor OCI-USB and his eUSB. There are other differences which I will post if you think they might be helpful but this is going to be long as it is... 04e6:000a appears in the list of unusual devices for the usb-storage module, where the unusualness is US_SC_8020 and US_PR_CB. Copying these settings over for 55aa:b000 didn't help in the slightest, but a bit of experimentation has got me further using US_SC_SCSI, US_PR_BULK (the defaults) and US_FL_START_STOP. Now I can sometimes mount a disk, read stuff, write stuff and generally have fun until it all grinds to a halt. This is what the end of my logs look like (at this point I was trying to umount but this is what it looks like in general): usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096 usb-storage: usb_stor_transfer_partial(): transfer complete (repeated ad nauseam) usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096 usb-storage: usb_stor_transfer_partial(): transfer complete usb-storage: usb_stor_transfer_partial(): xfer 1536 bytes usb-storage: command_abort() called usb-storage: usb_stor_bulk_msg() returned -104 xferred 64/1536 usb-storage: usb_stor_transfer_partial(): unknown error usb-storage: Bulk data transfer result 0x2 usb-storage: Attempting to get CSW... uhci.c: uhci_submit_urb: urb not available to submit (status = -104) usb-storage: Bulk status result = -22 usb-storage: -- transport indicates error, resetting usb-storage: Bulk reset requested usb_control/bulk_msg: timeout usb-storage: Bulk soft reset failed -110 usb-storage: scsi cmd done, result=0x7 usb-storage: *** thread sleeping. That's it. The umount process hangs so deeply I cannot kill it and I'm stuck until (horror!) I reboot. The problem is more severe using a 1Gb Microdrive (which has longer seek times) but I haven't managed to umount my 32Mb CF card after writing a file to it either. I wonder if something is timing out and failing to recover? I'm way out of my depth at this point and could do with some help. TIA, Dave - -- Dave Turner [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- iD8DBQE+d6nceFNVJYkmfV8RAkH8AJ93bn20syf1OR8/xyelLdCqXWWUcgCeL4MO tZflbixHNkReYxvgJh+TRVU= =c2TA -END PGP SIGNATURE- --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH]fix to synchronous API regardingmemoryallocation
On Tue, 18 Mar 2003, Alan Stern wrote: On Tue, 18 Mar 2003, Oliver Neukum wrote: How can that be? The SCSI layer guarantees that no further requests are issued while the error handler is running. Yes. The synchronous API calls you are concerned about are made from a subroutine that is called directly by the error handler and that runs in the context of the error handler thread. During the time this happens, the SCSI layer guarantees that no further requests are issued, either for block I/O or other error-handler stuff. But what happens if the vm subsystem waits for this IO to complete as is entirely legal with GFP_KERNEL allocations ? You mean, what if the VM subsystem is blocked because it can't fulfill the error-handler's GFP_KERNEL allocation request until the I/O is completed and the I/O can't complete until the error-handler fixes things up? I don't know. How do other subsystems handle this? I just went back and re-read the kerneldoc explanation for the memory flags in usb_submit_urb(). You are correct. I withdraw my objection to the patch. Alan Stern --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
