Hello All Can anybody tell me how this usbmouse works?? that is in linux/drivers/usb directory. I want to write a usb driver for my usb ADC card how i will proceed... Any suggation will be helpful for me. Thanks Pankaj. On Mon, 10 Dec 2001 [EMAIL PROTECTED] wrote : > Send linux-usb-devel mailing list submissions to > [EMAIL PROTECTED] > > To subscribe or unsubscribe via the World Wide Web, > visit > https://lists.sourceforge.net/lists/listinfo/linux-usb-- > devel > or, via email, send a message with subject or body > 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is > more specific > than "Re: Contents of linux-usb-devel digest..." > > > Today's Topics: > > 1. Re: Re: Q: device(file) permissions for USB > (David Brownell) > 2. USB-storage: very slow. (Rogier Wolff) > 3. Re: [Linux-usb-users] USB-storage: very slow. > (=?ISO-8859-1?Q?Bj=F6rn_Stenberg?=) > 4. Re: Cleanup storage (Matthew Dharm) > 5. Re: USB-storage: very slow. (Matthew Dharm) > 6. Link status reporting - Take 2 (Brad Hards) > 7. Re: Link status reporting - Take 2 (Vojtech > Pavlik) > 8. Re: [Linux-usb-users] USB-storage: very slow. > (Rogier Wolff) > 9. Re: Re: Q: device(file) permissions for USB > (Oliver Neukum) > 10. Re: 2.4.16 interrupt transfer broken? (Mark > Burazin) > 11. Re: [Linux-usb-users] USB-storage: very slow. > (Rogier Wolff) > 12. Re: Re: [Linux-usb-users] USB-storage: very slow. > (Oliver Neukum) > 13. patch to hpusbscsi to fix error handling (Oliver > Neukum) > 14. Re: Re: Q: device(file) permissions for USB (Alan > Cox) > 15. Re: Re: [Linux-usb-users] USB-storage: very slow. > (Greg KH) > 16. Re: Re: Q: device(file) permissions for USB (Greg > KH) > 17. Re: patch to hpusbscsi to fix error handling > (Greg KH) > > --__--__-- > > Message: 1 > Date: Sat, 08 Dec 2001 21:10:47 -0800 > From: David Brownell <[EMAIL PROTECTED]> > Subject: Re: [linux-usb-devel] Re: Q: device(file) > permissions for USB > To: Greg KH <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > > > > > I don't know of anyone using the usbdevfs > interface on devices that have > > > > a kernel driver associated with it. Does anyone > else? > > > > > > Well, it's the clean way to construct the device > tree in userland. > > > Parsing the "devices" file is problematic in > various cases. > > > > What cases? I don't know of cases that aren't just > as hard as parsing > > the device tree by walking the directories. > > Cases like: you're already walking the directories, so > there's no reason to write a parser for "devices" ... :) > > > > Ah, the whole device naming problem, which I see this > thread has spun > > off into. I'm staying away from that topic for now :) > > Can't say I blame you for trying ... I'm just throwing > chum into > the water to see what sort of fish swim around here! > > - Dave > > > > > --__--__-- > > Message: 2 > To: [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED] > Date: Sun, 9 Dec 2001 11:12:37 +0100 (MET) > From: [EMAIL PROTECTED] (Rogier Wolff) > Subject: [linux-usb-devel] USB-storage: very slow. > > > Hi, > > I have a Sony F707 digital camera. A day of shooting > results in about > 95M of pictures. Copying that over to my PC took 25 > minutes. Thats > about 63kbytes per second. > > As USB can do about 12Mbps, (> 1mbyte per second) and > the memory stick > can too, I would like to get about 1Mbyte per second, > and download all > the pictures in around 2 minutes. > > Does anybody have an idea about what can be wrong? > > I currently have a Philips ToUcam on the other port on > that PC. This > shouldn't influence the transferrate, right? (12 Mbps > for each > channel, not shared for both channels). > > I currently have a hub connected, as the cable > > In fact I've tried connecting the camera directly to > another computer, > and gotten a similarly very bad download speed. > > The main question is: what can be wrong with my setup? > (Or is this "to be expected"?) > > > Roger. > > > P.S. sorry for spamming both the user and the devel > list: I don't know > what issue it is... > > -- > ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ > ** +31-15-2137555 ** > *-- BitWizard writes Linux device drivers for any > device you may have! --* > * There are old pilots, and there are bold pilots. > * There are also old, bald pilots. > > > --__--__-- > > Message: 3 > Date: Sun, 9 Dec 2001 11:38:50 +0100 (CET) > From: =?ISO-8859-1?Q?Bj=F6rn_Stenberg?= <[EMAIL PROTECTED]> > To: Rogier Wolff <[EMAIL PROTECTED]> > cc: <[EMAIL PROTECTED]>, > <[EMAIL PROTECTED]>, > <[EMAIL PROTECTED]> > Subject: [linux-usb-devel] Re: [Linux-usb-users] > USB-storage: very slow. > > Rogier Wolff wrote: > > > I have a Sony F707 digital camera. A day of shooting > results in about > > 95M of pictures. Copying that over to my PC took 25 > minutes. Thats > > about 63kbytes per second. > > Details, please. Which HCI driver are you using? > > 63k sounds like what I got when testing usb-storage > with uhci.o. In the sam= > e > test I got >700k with usb-uhci.o so you might want to > try that. > > /Bj=F6rn > > > > --__--__-- > > Message: 4 > Date: Sun, 9 Dec 2001 02:42:35 -0800 > From: Matthew Dharm <[EMAIL PROTECTED]> > To: Martin Diehl <[EMAIL PROTECTED]> > Cc: Pavel Machek <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > Subject: Re: [linux-usb-devel] Cleanup storage > Organization: One Eyed Alien Networks > > > --GvXjxJ+pjyke8COw > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > That does sound reasonable... I'll give it a try on my > systems here and > see what I get. > > Anyone else willing to test? > > Matt > > On Sun, Dec 09, 2001 at 12:55:25AM +0100, Martin Diehl > wrote: > > On Thu, 6 Dec 2001, Pavel Machek wrote: > >=20 > > > - exit_files(current); > > > - current->files =3D init_task.files; > > > - atomic_inc(¤t->files->count); > > > - daemonize(); > >=20 > > what about keeping all this as was pointed out by > Alan and simply add > >=20 > > sigfillset(¤t->blocked); > >=20 > > after daemonize() call. So the thread has all signals > blocked and is > > immune even to SIGKILL (at least if raised from > userland IMHO). > >=20 > > Martin > > --=20 > Matthew Dharm Home: > mdharm-usb@one-eyed-alien.= > net=20 > Maintainer, Linux USB Mass Storage Driver > > I want my GPFs!!! > -- Stef > User Friendly, 11/9/1998 > > --GvXjxJ+pjyke8COw > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE8E0Abz64nssGU+ykRAt0OAKDamd1mTV9iQ5Kec77uhdOtfj6L- > WwCfYuBF > d46c6lEidGoM6X9P6uWM3VM= > =aGfA > -----END PGP SIGNATURE----- > > --GvXjxJ+pjyke8COw-- > > > --__--__-- > > Message: 5 > Date: Sun, 9 Dec 2001 02:47:08 -0800 > From: Matthew Dharm <[EMAIL PROTECTED]> > To: Rogier Wolff <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], > [EMAIL PROTECTED] > Organization: One Eyed Alien Networks > Subject: [linux-usb-devel] Re: USB-storage: very slow. > > > --UPT3ojh+0CqEDtpF > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Sun, Dec 09, 2001 at 11:12:37AM +0100, Rogier Wolff > wrote: > > I currently have a Philips ToUcam on the other port > on that PC. This > > shouldn't influence the transferrate, right? (12 Mbps > for each > > channel, not shared for both channels).=20 > > 12Mbps for each _bus_. Both ports are likely on the > same bus, and thus > sharing that bandwidth. > > Bjorn has already answered your speed issues, it looks > like. > > Matt > > --=20 > Matthew Dharm Home: > mdharm-usb@one-eyed-alien.= > net=20 > Maintainer, Linux USB Mass Storage Driver > > I need a computer? > -- Customer > User Friendly, 2/19/1998 > > --UPT3ojh+0CqEDtpF > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD4DBQE8E0Esz64nssGU+ykRAqRfAKCZKnMwTVX2sXhejFnHDDtShmkO- > 5wCUCxGI > BtNDWUeTlWV4QNEpiTVZcg== > =sYHN > -----END PGP SIGNATURE----- > > --UPT3ojh+0CqEDtpF-- > > > --__--__-- > > Message: 6 > Date: Sun, 09 Dec 2001 21:56:38 +1100 > From: Brad Hards <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], > [EMAIL PROTECTED] > CC: [EMAIL PROTECTED] > Subject: [linux-usb-devel] Link status reporting - Take > 2 > > This is a multi-part message in MIME format. > --------------72EC4811D3DE921CA24C4F59 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > G'day all, > > After an abortive previous attempt at providing user > space reporting > (http://marc.theaimsgroup.com/?t=100677748400003&r=1&w=2- > ), I implemented the > ioctl() support for the ethtool user space tool > (http://gkernel.sf.net) in the > catc driver. Here is an example: > [bradh@leon linux]# ethtool eth1 > Settings for eth1: > Link detected: no > [bradh@leon linux]# ethtool eth1 > Settings for eth1: > Link detected: yes > [bradh@leon linux]# ethtool -i eth1 > driver: EL1210A NetMate USB Ethernet > version: v2.8 > firmware-version: > bus-info: usb1:9 > > > Patch is attached, against 2.4.17-pre6. > > Discussion issue: > The CATC device provides link state as interrupt status > bits. So the link > state reporting is only accurate when interrupts are > being delivered. The catc > driver currently only submits the interrupt URB in its > open() routine. All > this means is that it only works if the interface is UP. > Should we try for a sensible handling of link state (by > submitting the > interrupt URB in probe()), even if it means possibly > handling junk interupts? > > Brad > --------------72EC4811D3DE921CA24C4F59 > Content-Type: application/octet-stream; > name="catc-linkstate.patch" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; > filename="catc-linkstate.patch" > > ZGlmZiAtTmF1ciAtWCBkb250ZGlmZiAvbW50L3NtYjIvY2xlYW4vbGlu- > dXgtMi40LjE3LXBy > ZTYvZHJpdmVycy91c2IvY2F0Yy5jIGxpbnV4L2RyaXZlcnMvdXNiL2Nh- > dGMuYwotLS0gL21u > dC9zbWIyL2NsZWFuL2xpbnV4LTIuNC4xNy1wcmU2L2RyaXZlcnMvdXNi- > L2NhdGMuYwlXZWQg > Tm92IDE0IDA0OjE5OjQwIDIwMDEKKysrIGxpbnV4L2RyaXZlcnMvdXNi- > L2NhdGMuYwlTdW4g > RGVjICA5IDIxOjMxOjQwIDIwMDEKQEAgLTM4LDcgKzM4LDkgQEAKICNp- > bmNsdWRlIDxsaW51 > eC9ldGhlcmRldmljZS5oPgogI2luY2x1ZGUgPGxpbnV4L3NrYnVmZi5o- > PgogI2luY2x1ZGUg > PGxpbnV4L3NwaW5sb2NrLmg+CisjaW5jbHVkZSA8bGludXgvZXRodG9v- > bC5oPgogI2luY2x1 > ZGUgPGFzbS9iaXRvcHMuaD4KKyNpbmNsdWRlIDxhc20vdWFjY2Vzcy5o- > PgogCiAjdW5kZWYg > REVCVUcKIApAQCAtNDgsOSArNTAsMTAgQEAKICAqIFZlcnNpb24gaW5m- > b3JtYXRpb24uCiAg > Ki8KIAotI2RlZmluZSBEUklWRVJfVkVSU0lPTiAidjIuNyIKKyNkZWZp- > bmUgRFJJVkVSX1ZF > UlNJT04gInYyLjgiCiAjZGVmaW5lIERSSVZFUl9BVVRIT1IgIlZvanRl- > Y2ggUGF2bGlrIDx2 > b2p0ZWNoQHN1c2UuY3o+IgogI2RlZmluZSBEUklWRVJfREVTQyAiQ0FU- > QyBFTDEyMTBBIE5l > dE1hdGUgVVNCIEV0aGVybmV0IGRyaXZlciIKKyNkZWZpbmUgU0hPUlRf- > RFJJVkVSX0RFU0Mg > IkVMMTIxMEEgTmV0TWF0ZSBVU0IgRXRoZXJuZXQiCiAKIE1PRFVMRV9B- > VVRIT1IoRFJJVkVS > X0FVVEhPUik7CiBNT0RVTEVfREVTQ1JJUFRJT04oRFJJVkVSX0RFU0Mp- > OwpAQCAtMjU5LDEx > ICsyNjIsMTUgQEAKIAkJfSAKIAl9CiAKLQlpZiAoZGF0YVsxXSAmIDB4- > NDApCisJaWYgKGRh > dGFbMV0gJiAweDQwKSB7CisJCW5ldGlmX2NhcnJpZXJfb24oY2F0Yy0+- > bmV0ZGV2KTsKIAkJ > ZGJnKCJsaW5rIG9rIik7CisJfQogCi0JaWYgKGRhdGFbMV0gJiAweDIw- > KSAKKwlpZiAoZGF0 > YVsxXSAmIDB4MjApIHsKKwkJbmV0aWZfY2Fycmllcl9vZmYoY2F0Yy0+- > bmV0ZGV2KTsKIAkJ > ZGJnKCJsaW5rIGJhZCIpOworCX0KIH0KIAogLyoKQEAgLTU2NCw2ICs1- > NzEsNTQgQEAKIH0K > IAogLyoKKyAqIGlvY3RsJ3MKKyAqLworc3RhdGljIGludCBuZXRkZXZf- > ZXRodG9vbF9pb2N0 > bChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCB2b2lkICp1c2VyYWRkcikK- > K3sKKyAgICAgICAg > c3RydWN0IGNhdGMgKmNhdGMgPSBkZXYtPnByaXY7CisgICAgICAgIHUz- > MiBjbWQ7CisJY2hh > ciB0bXBbNDBdOworICAgICAgICAKKyAgICAgICAgaWYgKGdldF91c2Vy- > KGNtZCwgKHUzMiAq > KXVzZXJhZGRyKSkKKyAgICAgICAgICAgICAgICByZXR1cm4gLUVGQVVM- > VDsKKworICAgICAg > ICBzd2l0Y2ggKGNtZCkgeworICAgICAgICAvKiBnZXQgZHJpdmVyIGlu- > Zm8gKi8KKyAgICAg > ICAgY2FzZSBFVEhUT09MX0dEUlZJTkZPOiB7CisgICAgICAgICAgICAg- > ICAgc3RydWN0IGV0 > aHRvb2xfZHJ2aW5mbyBpbmZvID0ge0VUSFRPT0xfR0RSVklORk99Owor- > ICAgICAgICAgICAg > ICAgIHN0cm5jcHkoaW5mby5kcml2ZXIsIFNIT1JUX0RSSVZFUl9ERVND- > LCBFVEhUT09MX0JV > U0lORk9fTEVOKTsKKyAgICAgICAgICAgICAgICBzdHJuY3B5KGluZm8u- > dmVyc2lvbiwgRFJJ > VkVSX1ZFUlNJT04sIEVUSFRPT0xfQlVTSU5GT19MRU4pOworCQlzcHJp- > bnRmKHRtcCwgInVz > YiVkOiVkIiwgY2F0Yy0+dXNiZGV2LT5idXMtPmJ1c251bSwgY2F0Yy0+- > dXNiZGV2LT5kZXZu > dW0pOworICAgICAgICAgICAgICAgIHN0cm5jcHkoaW5mby5idXNfaW5m- > bywgdG1wLEVUSFRP > T0xfQlVTSU5GT19MRU4pOworICAgICAgICAgICAgICAgIGlmIChjb3B5- > X3RvX3VzZXIodXNl > cmFkZHIsICZpbmZvLCBzaXplb2YoaW5mbykpKQorICAgICAgICAgICAg- > ICAgICAgICAgICAg > cmV0dXJuIC1FRkFVTFQ7CisgICAgICAgICAgICAgICAgcmV0dXJuIDA7- > CisgICAgICAgIH0K > KyAgICAgICAgLyogZ2V0IGxpbmsgc3RhdHVzICovCisgICAgICAgIGNh- > c2UgRVRIVE9PTF9H > TElOSzogeworICAgICAgICAgICAgICAgIHN0cnVjdCBldGh0b29sX3Zh- > bHVlIGVkYXRhID0g > e0VUSFRPT0xfR0xJTkt9OworICAgICAgICAgICAgICAgIGVkYXRhLmRh- > dGEgPSBuZXRpZl9j > YXJyaWVyX29rKGRldik7CisgICAgICAgICAgICAgICAgaWYgKGNvcHlf- > dG9fdXNlcih1c2Vy > YWRkciwgJmVkYXRhLCBzaXplb2YoZWRhdGEpKSkKKyAgICAgICAgICAg- > ICAgICAgICAgICAg > IHJldHVybiAtRUZBVUxUOworICAgICAgICAgICAgICAgIHJldHVybiAw- > OworICAgICAgICB9 > CisJfQorICAgICAgICAKKyAgICAgICAgcmV0dXJuIC1FT1BOT1RTVVBQ- > OworfQorCitzdGF0 > aWMgaW50IGNhdGNfaW9jdGwoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwg- > c3RydWN0IGlmcmVx > ICpycSwgaW50IGNtZCkKK3sKKyAgICAgICAgc3dpdGNoKGNtZCkgewor- > ICAgICAgICBjYXNl > IFNJT0NFVEhUT09MOgorICAgICAgICAgICAgICAgIHJldHVybiBuZXRk- > ZXZfZXRodG9vbF9p > b2N0bChkZXYsICh2b2lkICopIHJxLT5pZnJfZGF0YSk7CisgICAgICAg- > IGRlZmF1bHQ6Cisg > ICAgICAgICAgICAgICAgcmV0dXJuIC1FT1BOT1RTVVBQOworICAgICAg- > ICB9Cit9CisKKwor > LyoKICAqIE9wZW4sIGNsb3NlLgogICovCiAKQEAgLTYyOSw2ICs2ODQs- > NyBAQAogCW5ldGRl > di0+dHhfdGltZW91dCA9IGNhdGNfdHhfdGltZW91dDsKIAluZXRkZXYt- > PndhdGNoZG9nX3Rp > bWVvID0gVFhfVElNRU9VVDsKIAluZXRkZXYtPnNldF9tdWx0aWNhc3Rf- > bGlzdCA9IGNhdGNf > c2V0X211bHRpY2FzdF9saXN0OworCW5ldGRldi0+ZG9faW9jdGwgPSBj- > YXRjX2lvY3RsOwog > CW5ldGRldi0+cHJpdiA9IGNhdGM7CiAKIAljYXRjLT51c2JkZXYgPSB1- > c2JkZXY7Cg== > --------------72EC4811D3DE921CA24C4F59-- > > > > --__--__-- > > Message: 7 > Date: Sun, 9 Dec 2001 12:04:09 +0100 > From: Vojtech Pavlik <[EMAIL PROTECTED]> > To: Brad Hards <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], > [EMAIL PROTECTED] > Subject: [linux-usb-devel] Re: Link status reporting - > Take 2 > > On Sun, Dec 09, 2001 at 09:56:38PM +1100, Brad Hards > wrote: > > > After an abortive previous attempt at providing user > space reporting > > (http://marc.theaimsgroup.com/?t=100677748400003&r=1&w- > =2), I implemented the > > ioctl() support for the ethtool user space tool > (http://gkernel.sf.net) in the > > catc driver. Here is an example: > > [bradh@leon linux]# ethtool eth1 > > Settings for eth1: > > Link detected: no > > [bradh@leon linux]# ethtool eth1 > > Settings for eth1: > > Link detected: yes > > [bradh@leon linux]# ethtool -i eth1 > > driver: EL1210A NetMate USB Ethernet > > version: v2.8 > > firmware-version: > > bus-info: usb1:9 > > Nice. Send it to Greg KH, when you want to have > included it in the > kernel, it's OK with me. > > > Patch is attached, against 2.4.17-pre6. > > > > Discussion issue: > > The CATC device provides link state as interrupt > status bits. So the link > > state reporting is only accurate when interrupts are > being delivered. The catc > > driver currently only submits the interrupt URB in > its open() routine. All > > this means is that it only works if the interface is > UP. > > Should we try for a sensible handling of link state > (by submitting the > > interrupt URB in probe()), even if it means possibly > handling junk interupts? > > I think it is fairly OK, the only problem is that it'll > eat a slice out > of the available USB bandwith. The interrupt is polled > in every USB > frame. > > -- > Vojtech Pavlik > SuSE Labs > > > --__--__-- > > Message: 8 > To: "[Bj_rn Stenberg]" <[EMAIL PROTECTED]> > Date: Sun, 9 Dec 2001 12:17:14 +0100 (MET) > CC: Rogier Wolff <[EMAIL PROTECTED]>, > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED] > From: [EMAIL PROTECTED] (Rogier Wolff) > Subject: [linux-usb-devel] Re: [Linux-usb-users] > USB-storage: very slow. > > [Bj_rn Stenberg] wrote: > [Charset ISO-8859-1 unsupported, filtering to ASCII...] > > Rogier Wolff wrote: > > > > > I have a Sony F707 digital camera. A day of > shooting results in about > > > 95M of pictures. Copying that over to my PC took 25 > minutes. Thats > > > about 63kbytes per second. > > > > Details, please. Which HCI driver are you using? > > > 63k sounds like what I got when testing usb-storage > with uhci.o. In > > the same test I got >700k with usb-uhci.o so you > might want to try > > that. > > Bjorn, > > Thanks for the tip! Now I'm getting about 6.5Mb per 10 > seconds > now. Downloaded the whole bunch (95Mb) of images in 2.5 > minutes. That's more like it. :-) > > Roger. > > -- > ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ > ** +31-15-2137555 ** > *-- BitWizard writes Linux device drivers for any > device you may have! --* > * There are old pilots, and there are bold pilots. > * There are also old, bald pilots. > > > --__--__-- > > Message: 9 > From: [EMAIL PROTECTED] (Oliver Neukum) > Reply-To: [EMAIL PROTECTED] > To: David Brownell <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > Subject: Re: [linux-usb-devel] Re: Q: device(file) > permissions for USB > Date: Sun, 9 Dec 2001 12:32:10 +0100 > > Am Sonntag, 9. Dezember 2001 05:46 schrieb David > Brownell: > > > > Today that's a two level action. Devices' "true > names" are > > > > triples {char or block, major, minor}, which make > a finite > > > > set of names (16 bits today, 32 bits soonish) > exposed > > > > as "dev_t" to userland ... for some devices, but > not all > > > > (consider network interfaces). In some cases > "devfs" > > > > might assign those "true names" for you. > > > > > > Where is the sense of having these, if you can't > keep them stable anyway > > > ? (Except for backwards compatibility) > > > > That topic has been discussed on LKML from time to > time. > > Linus is currently talking about abolishing them in > the 2.5 > > series, as you may know. Radical change is in the > air. > > Any further comment on that is like discussing religion > ;-) > > [..] > > > What for ? What's wrong with using a name the > kernel provides ? > > > If you really, really want other names, symlinks > can be used. > > > > The issue is that it "chooses" the name (a policy > function) > > and thereby complicates things. Since there's got to > be a > > policy stage in userland anyway, why not have it make > the > > WHOLE policy choice instead just "what symlink?". > > > > That is, turn it around. Why should the kernel do > this at all? > > Because it allows the system to work under rough > conditions. > If the kernel chooses, publishes and recognises names > on its own, the system > retaines some function in emergency, after the user > space support has crashed. > > If the policy demon chooses a name, there needs to be > some sort of callback > or a mknod. That is a brittle scheme which requires > tight synchronisation > between kernel and demon to avoid race conditions. > The stages of device detection and device configuration > should be as divorced > as possible. > > > Those policies have always been in userland -- except > for > > networking devices, where problems come up because the > > interface names are so sensitive to how the kernel is > linked > > and configured. Hotplugging only adds one new > requirement: > > that the choices must be "dynamic", rather than > "static" when > > distributions create their /dev/* device trees. > (That "static" > > model started when UNIX had eight bit UIDs and no > GIDs...) > > > > The exception is "devfs", which hasn't been widely > popular; > > in part that's because of the names it chose. > > And in part due to some races. > > > > > If the hotplug events were reported at that level, > I could imagine > > > > several modes of hotplugging: one where all > "function level" > > > > name bindings were chosen by user mode policy > actions, > > > > another where they were chosen by kernel policy > and then > > > > maybe tweaked later (as today, even with devfs), > and perhaps > > > > more ideally one where there was some degree of > cooperation > > > > to get rid of that "tweak it later" race. > > > > > > It seems to me that this scheme introduces > unnecessarily complex > > > callbacks to kernel space into the picture. > > > > Which one, why? Clearly not that second mode, since > it's basically > > what happens today. I didn't describe how the other > modes might work. > > What design were you thinking of? Sounds like it can > be improved ... :) > > Chosing names. > > > > There is an issue with the logical name depending > on the drivers loaded. > > > So indeed a two level scheme would serve better. > > > > Or in fact, "which driver is selected", and (as maybe > you meant) > Yes > > "what other modules got to initialize first". > > > > But to repeat, today Linux (all UNIXes) works with > such a two level > > scheme for device naming -- my question is how > hotplugging should > > benefit from changes coming in 2.5, since we know > that some some > > changes in those areas are on the way. > > Firstly we are not yet sure what the Alpha Penguin will > do, > and secondly IMHO we should first discuss needs and > consequences. > > What we know is that the kernel is not planed to work > with major:minor. > It'll just publish unique, but variable numbers to user > space. If we decide > that we need stable names, we have implicitely decided > that we need a system > to assign those to unstable numbers. > I just don't see how we can make a truly robust system > with this scheme. > > Regards > Oliver > > > --__--__-- > > Message: 10 > From: Mark Burazin <[EMAIL PROTECTED]> > Organization: Lemna d.o.o. > To: Martin Diehl <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > Subject: Re: [linux-usb-devel] 2.4.16 interrupt > transfer broken? > Date: Sun, 9 Dec 2001 12:21:48 +0100 > > On Nedjelja 09 Prosinac 2001 00:51, Martin Diehl wrote: > > > With usb-uhci i receive -ECONNABORTED while > submitting urbs. (currently > > > the > > > > During submitting? Strange. For me, the > usb_submit_usb succeeds (like it > > always did without the patch). And the completion > handler gets called with > > urb->status=0. However, with further testing I'm able > now to reproduce > > the status gets changed to ECONNABORTED _after_ the > completion handler > > returned (but already before doing anything else like > an additional > > unlink). Even width additional 10ms sleep the status > never changes from > > ECONNABORTED - and I tend to believe the URB never > gets completely removed > > from the schedule. > > Yes I believe that could be the problem why all > aditional urbs fail (only the > first goes through). > Maybe I should call usb_unlink_urb in the completion > handler?? Maybe it would > cause it to be ok? I use a one-shot interrupt urb, but > maybe the error of the > usb-uhci is that he doesn't correctly handle the > one-shot urbs? So I must do > it manually? > > > PS: > > > if ( usb_submit_urb( outurb ) ) > > > { > > > err( DRIVER_NAME ": Failed(%d) submit > urb!\n", outurb->status ); > > > spin_unlock ( &global_usb_nepp->io_lock ); > > > > so you have this spinlock still acquired in the > submit-succeed case > > > > > return -EIO; > > > } > > > interruptible_sleep_on_timeout ( > &global_usb_nepp->write_wait, 1500 * > > > HZ/1000 ); > > > > ... but go sleeping here? > > And sleep_on and friends are really deprecated due to > races. > > ;-) I noticed the problems on a SMP, I have rewritten > the driver three times > in the meantime, now it's ok :) > (it's very simple only some 500 lines of code) > > With regards, > Mark > -- > Mark Burazin > [EMAIL PROTECTED] > ---<>---<>---<>---<>---<>---<>---<>---<>---<> > Lemna d.o.o. > http://www.lemna.biz - [EMAIL PROTECTED] > <>---<>---<>---<>---<>---<>---<>---<>---<>--- > > > > --__--__-- > > Message: 11 > To: Rogier Wolff <[EMAIL PROTECTED]> > Date: Sun, 9 Dec 2001 13:44:16 +0100 (MET) > CC: "[Bj_rn Stenberg]" <[EMAIL PROTECTED]>, > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED] > From: [EMAIL PROTECTED] (Rogier Wolff) > Subject: [linux-usb-devel] Re: [Linux-usb-users] > USB-storage: very slow. > > Rogier Wolff wrote: > > [Bj_rn Stenberg] wrote: > > [Charset ISO-8859-1 unsupported, filtering to > ASCII...] > > > Rogier Wolff wrote: > > > > > > > I have a Sony F707 digital camera. A day of > shooting results in about > > > > 95M of pictures. Copying that over to my PC took > 25 minutes. Thats > > > > about 63kbytes per second. > > > > > > Details, please. Which HCI driver are you using? > > > > > 63k sounds like what I got when testing usb-storage > with uhci.o. In > > > the same test I got >700k with usb-uhci.o so you > might want to try > > > that. > > > > Bjorn, > > > > Thanks for the tip! Now I'm getting about 6.5Mb per > 10 seconds > > now. Downloaded the whole bunch (95Mb) of images in > 2.5 > > minutes. That's more like it. :-) > > OK Guys, I now have a script running that will > automatically slurp my > camera once it is connected: > > tail -0f /var/log/messages | \ > awk '/Manufacturer: Sony DSC/ {system > ("/home/wolff/bin/handle_sony")}' & > > and: > > ----------------------------------------------- > #!/bin/sh > mnt=/mnt/sony > dst=/home/wolff/dsc/newimages/ > > (beep) > /dev/console & > > mount /dev/sda1 $mnt > for i in $mnt/*/*/ > do > rsync -avv --progress $i $dst > done > > umount $mnt > > (beep; sleep 1 ; beep) > /dev/console & > ----------------------------------------------- > > The thing I don't like about this is that the "sda1" > has to be > guessed. Besides "usb-storage" I have 2 more SCSI > interfaces in this > machine, and the day that I'll add a permanent scsi > disk (or something > that looks like one) on one of them will come > eventually. > > So my feature request is: can the usb-storage driver > spew out which > sdX it got: that way I can make my script a bit more > robust. > > I just realized, there is probably a "usbmgr" program > that can replace > my "tail -f / awk" trick. I just searched the web a bit > but couldn't > find anything easy / that can launch my other script. > If it's trivial, > please enlighten me... ;-) > > Roger. > > -- > ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ > ** +31-15-2137555 ** > *-- BitWizard writes Linux device drivers for any > device you may have! --* > * There are old pilots, and there are bold pilots. > * There are also old, bald pilots. > > > --__--__-- > > Message: 12 > From: [EMAIL PROTECTED] (Oliver Neukum) > Reply-To: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] (Rogier Wolff) > Subject: Re: [linux-usb-devel] Re: [Linux-usb-users] > USB-storage: very slow. > Date: Sun, 9 Dec 2001 14:02:46 +0100 > Cc: [EMAIL PROTECTED] > > > > So my feature request is: can the usb-storage driver > spew out which > > sdX it got: that way I can make my script a bit more > robust. > > Welcome to the wonderful world of Linux SCSI ! > No, it can't. It doesn't know itself. > > Regards > Oliver > > > --__--__-- > > Message: 13 > From: [EMAIL PROTECTED] (Oliver Neukum) > Reply-To: [EMAIL PROTECTED] > To: Greg KH <[EMAIL PROTECTED]> > Date: Sun, 9 Dec 2001 14:12:32 +0100 > Cc: [EMAIL PROTECTED] > Subject: [linux-usb-devel] patch to hpusbscsi to fix > error handling > > Hi, > > this should fix a bug with error handling visible on > the Sacn Dual II > > Regards > Oliver > > --- hpusbscsi.h.alt Sun Oct 7 19:12:48 2001 > +++ hpusbscsi.h Sun Dec 9 13:58:14 2001 > @@ -50,7 +50,8 @@ > static int hpusbscsi_scsi_detect (struct SHT * sht); > static void simple_command_callback(struct urb *u); > static void scatter_gather_callback(struct urb *u); > -static void simple_payload_callback (struct urb *u); > +static void simple_payload_callback(struct urb *u); > +static void request_sense_callback(struct urb *u); > static void control_interrupt_callback (struct urb *u) > ; > static void simple_done (struct urb *u); > static int hpusbscsi_scsi_queuecommand (Scsi_Cmnd *srb, > scsi_callback callback); > --- hpusbscsi.c.alt Tue Oct 9 19:17:54 2001 > +++ hpusbscsi.c Sun Dec 9 13:58:09 2001 > @@ -270,7 +270,12 @@ > /* Now we need to decide which callback to give to > the urb we send the command with */ > > if (!srb->bufflen) { > - usb_callback = simple_command_callback; > + if (srb->cmnd[0] != REQUEST_SENSE) { > + usb_callback = simple_command_callback; > + } else { /* transfer into an internal buffer */ > + usb_callback = request_sense_callback; > + hpusbscsi->current_data_pipe = > usb_rcvbulkpipe(hpusbscsi->dev, hpusbscsi->ep_in); > + } > } else { > if (srb->use_sg) { > usb_callback = scatter_gather_callback; > @@ -517,3 +522,39 @@ > } > } > > +static void request_sense_callback (struct urb *u) > +{ > + struct hpusbscsi * hpusbscsi = (struct hpusbscsi *) > u->context; > + int res; > + > + if (u->status<0) { > + handle_usb_error(hpusbscsi); > + return; > + } > + > + FILL_BULK_URB( > + u, > + hpusbscsi->dev, > + hpusbscsi->current_data_pipe, > + hpusbscsi->srb->sense_buffer, > + SCSI_SENSE_BUFFERSIZE, > + simple_done, > + hpusbscsi > + ); > + > + res = usb_submit_urb(u); > + if (res) { > + handle_usb_error(hpusbscsi); > + return; > + } > + TRACE_STATE; > + if (hpusbscsi->state != HP_STATE_PREMATURE) { > + hpusbscsi->state = HP_STATE_WORKING; > + TRACE_STATE; > + } else { > + if (hpusbscsi->scallback != NULL) > + hpusbscsi->scallback(hpusbscsi->srb); > + hpusbscsi->state = HP_STATE_FREE; > + TRACE_STATE; > + } > +} > > > > --__--__-- > > Message: 14 > Subject: Re: [linux-usb-devel] Re: Q: device(file) > permissions for USB > To: [EMAIL PROTECTED] (David Brownell) > Date: Sun, 9 Dec 2001 16:31:37 +0000 (GMT) > Cc: [EMAIL PROTECTED], > [EMAIL PROTECTED] > From: Alan Cox <[EMAIL PROTECTED]> > > > The exception is "devfs", which hasn't been widely > popular; > > in part that's because of the names it chose. > > devfs is a seperate issue because you can also run > everything off hotplug. > Its fine whether devfs creates nodes or the hotplug > scripts get told > > "a konica camera serial 1141551 mass storage device > just appared on device > node 0x14253959" > > and do the work themselves > > > --__--__-- > > Message: 15 > Date: Sun, 9 Dec 2001 09:23:30 -0800 > From: Greg KH <[EMAIL PROTECTED]> > To: Rogier Wolff <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], > [EMAIL PROTECTED] > Subject: Re: [linux-usb-devel] Re: [Linux-usb-users] > USB-storage: very slow. > > On Sun, Dec 09, 2001 at 01:44:16PM +0100, Rogier Wolff > wrote: > > > > I just realized, there is probably a "usbmgr" program > that can replace > > my "tail -f / awk" trick. I just searched the web a > bit but couldn't > > find anything easy / that can launch my other script. > If it's trivial, > > please enlighten me... ;-) > > Take a look at the linux-hotplug package at > http://linux-hotplug.sf.net/ > It should keep you from having to 'tail' the syslog. > > Or you can just place your script at /sbin/hotplug > (checking to make > sure it was your camera that just got plugged in.) > > thanks, > > greg k-h > > > --__--__-- > > Message: 16 > Date: Sun, 9 Dec 2001 09:27:30 -0800 > From: Greg KH <[EMAIL PROTECTED]> > To: David Brownell <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: [linux-usb-devel] Re: Q: device(file) > permissions for USB > > On Sat, Dec 08, 2001 at 09:10:47PM -0800, David > Brownell wrote: > > > > > > What cases? I don't know of cases that aren't just > as hard as parsing > > > the device tree by walking the directories. > > > > Cases like: you're already walking the directories, > so > > there's no reason to write a parser for "devices" ... > :) > > As you walk the directory tree, a device could be > removed giving you > interesting problems :) > > The "devices" file _should_ provide a snapshot in time > of the tree > (which it does quite well, if you have less than 4k in > the file.) > > It is also much easier to use scripting languages with > the "devices" > file (see Randy's small perl scripts to display the usb > bus topology for > an example of this.) > > thanks, > > greg k-h > > > --__--__-- > > Message: 17 > Date: Sun, 9 Dec 2001 09:31:22 -0800 > From: Greg KH <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [linux-usb-devel] Re: patch to hpusbscsi to > fix error handling > > On Sun, Dec 09, 2001 at 02:12:32PM +0100, Oliver Neukum > wrote: > > Hi, > > > > this should fix a bug with error handling visible on > the Sacn Dual II > > Which kernel tree do you want this applied to? > > thanks, > > greg k-h > > > > --__--__-- > > _______________________________________________ > [EMAIL PROTECTED] > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-d- > evel > > > End of linux-usb-devel Digest
_______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
