Re: [linux-usb-devel] [PATCH 1/3] driver for mcs7830 (aka DeLOCK) USB ethernet adapter
On Sat, Oct 07, 2006 at 01:16:44PM -0700, David Brownell wrote: On Saturday 07 October 2006 11:58 am, Arnd Bergmann wrote: On Thursday 28 September 2006 03:28, David Brownell wrote: On Saturday 16 September 2006 4:02 pm, Arnd Bergmann wrote: This driver adds support for the DeLOCK USB ethernet adapter and potentially others based on the MosChip MCS7830 chip. Signed-off-by: Arnd Bergmann [EMAIL PROTECTED] Signed-off-by: David Brownell [EMAIL PROTECTED] David, I was under the assumption that you would submit this version for inclusion in 2.6.19. Do you have it queued somewhere for submission or did you expect me to send it to someone else? I was expecting Greg to do his usual fine job and pick it up for his next set of USB patches. But you could probably speed the process up by resending it to him. 2.6.19 seems right to me. (Hmm, I don't think your other two patches got merged either ...) If I don't get CC:ed, I can miss it at times. Feel free to resend it to me. thanks, greg k-h - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] error to be returned while suspended
Am Sonntag, 8. Oktober 2006 02:03 schrieb David Brownell: The power management functions without timeout are also exported. For other power control features like cpu frequency considerable effort has been made to export them to user space. Yes, and many of us use the much lighter weight kernel based control models by preference. Why waste hundreds of Kbytes of userspace for a daemon when a few hundred bytes of kernel code can implement a better and more reactive kernel policy for cpufreq? That's an important aspect. How about implementing autosuspend first and keeping the sysfs-based suspension for now? If autosuspend is done, we have something to compare too. If a different solution emerges to be advantagous under some conditions we can talk about the interface later. Regards Oliver - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] mos7720 close method
+static void mos7720_close (struct usb_serial_port *port, struct file * filp)
+{
+ for (j = 0; j NUM_URBS; ++j)
+ usb_unlink_urb (mos7720_port-write_urb_pool[j]);
This is asynchronous.
+ /* Freeing Write URBs*/
+ for (j = 0; j NUM_URBS; ++j)
+ {
+if (mos7720_port-write_urb_pool[j])
+{
+if (mos7720_port-write_urb_pool[j]-transfer_buffer)
+
kfree(mos7720_port-write_urb_pool[j]-transfer_buffer);
and might not have finished - potential use after free
Is there a special reason not to use usb_kill_urb?
Regards
Oliver
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb/hid: The HID Simple Driver Interface 0.3.2 (core)
On Sunday 08 October 2006 08:41, Zephaniah E. Hull wrote: 0: If you keep all the ID identical, userspace may have the capabilities cached. This may also cause problems, but if Dmitry or Greg calls that a userspace bug I'll believe them and find a workaround. Yes, I'd consider it a bug. Tearing down and re-creating input device generates proper hotplug notifications and userspace needs to respect them as capabilities may change even if ids stay the same. For example playing with atkbd's scroll attribute will regenerate an input device with[out] scroll capabilities but its input_id structure will stay the same. ... Or were you talking about ids as in inputX? These are ever increasing as new devices get created and will never be reused (as long as atomic_t doesn't wrap around ;) ) -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] error to be returned while suspended
On Sunday 08 October 2006 04:39, Oliver Neukum wrote: Am Sonntag, 8. Oktober 2006 09:20 schrieb David Brownell: If a device is always opened, as mice are, it will not be suspended. Yet they can be without any data to deliver forever. In 2.6.19-rc1 read Documentation/power/devices.txt about runtime suspend states. Then think about how why mouse in a runtime suspend state, with remote wakeup enabled, looks externally ** EXACTLY ** like a mouse that's fully active I've done so. And I've read the HID spec. It just says that a mouse may support remote wakeup, not what should wake it up. A device that wakes only if a button is clicked is within spec. And that's what some devices do. Apologies for a non-USB example, but since we are talking about input devices and it would be nice to have the rules consistent across all hardware interfaces I think it's OK... Synaptics PS/2 touchpad can be put into a sleep mode where it only reacts on button presses. While this behavior is reasonable for system- wide suspend it would hardly work for autosuspend. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] error to be returned while suspended
On Sun, 8 Oct 2006, Oliver Neukum wrote: I've never said that autosuspend is a bad idea. For many devices it is simple and painless. But it is insufficient. Therefore I think removing the ability to explicitely request a suspension from user space is wrong. I tend to agree. And I expect we _will_ end up with a userspace interface for suspending some devices. Other devices, like USB hubs, have no need of such an interface (other than for testing, perhaps). The reason for removing the current interface is just that it is so bad. Look how confused you were when you saw it recently. Values are 0, 2, and 3, 3 automatically gets changed to 2,... There isn't even any way for a driver to tell whether a suspend message is a runtime request from userspace or a system sleep transition notification! If so many people cannot come up with a good design, doesn't that indicate there's no single method that satisfies all needs? Probably. That's why I've been saying all along that these things need to be decided by the individual drivers. No single design will be appropriate for all of them. Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] error to be returned while suspended
On Sun, 8 Oct 2006, Oliver Neukum wrote: That's an important aspect. How about implementing autosuspend first and keeping the sysfs-based suspension for now? If autosuspend is done, we have something to compare too. If a different solution emerges to be advantagous under some conditions we can talk about the interface later. Well, autosuspend for USB is on its way. There are just a few bugs remaining in my changes to ehci-hcd. They should be ironed out soon and then Greg will merge it. The existing sysfs power/state implementation isn't going away immediately. It is deprecated and scheduled for removal in July 2007. Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] 2.6.19-rc1: known regressions (v2)
This email lists some known regressions in 2.6.19-rc1 compared to 2.6.18 that are not yet fixed Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you was declared guilty for a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: SMP x86_64 boot problem References : http://lkml.org/lkml/2006/9/28/330 http://lkml.org/lkml/2006/10/5/289 Submitter : [EMAIL PROTECTED] Status : submitter was asked to git bisect result of bisecting seems to be wrong Subject: snd-hda-intel - forcedeth MSI problem References : http://lkml.org/lkml/2006/10/5/40 Submitter : Prakash Punnoor [EMAIL PROTECTED] Status : unknown Subject: oops in xfrm_register_mode References : http://lkml.org/lkml/2006/10/4/170 Submitter : Steve Fox [EMAIL PROTECTED] Status : unknown Subject: T60 stops triggering any ACPI events References : http://lkml.org/lkml/2006/10/4/425 Submitter : Michael S. Tsirkin [EMAIL PROTECTED] Status : unknown Subject: thinkpad x60: brightness no longer adjustable in 2.6.18-git References : http://lkml.org/lkml/2006/10/2/300 Submitter : Pavel Machek [EMAIL PROTECTED] Status : unknown, related to the issue above? Subject: monitor not active after boot References : http://lkml.org/lkml/2006/10/5/338 Submitter : Olaf Hering [EMAIL PROTECTED] Guilty : Antonino Daplas [EMAIL PROTECTED] commit 346bc21026e7a92e1d7a4a1b3792c5e8b686133d Status : unknown Subject: sata-via doesn't detect anymore disks attached to VIA vt6421 References : http://bugzilla.kernel.org/show_bug.cgi?id=7255 Submitter : Thierry Vignaud [EMAIL PROTECTED] Status : unknown Subject: ueagle-atm Oops References : http://lkml.org/lkml/2006/10/6/390 Submitter : Ernst Herzberg [EMAIL PROTECTED] Handled-By : Matthieu Castet [EMAIL PROTECTED] Status : unknown Subject: DVD drive lost DVD capabilities References : http://lkml.org/lkml/2006/10/1/45 Submitter : Olaf Hering [EMAIL PROTECTED] Guilty : Jens Axboe [EMAIL PROTECTED] commit 4aff5e2333c9a1609662f2091f55c3f6fffdad36 Handled-By : Jens Axboe [EMAIL PROTECTED] Status : Jens is working on a fix Subject: sleep/wakeup on powerbooks apparently busted References : http://lkml.org/lkml/2006/10/5/13 Submitter : Benjamin Herrenschmidt [EMAIL PROTECTED] Handled-By : Benjamin Herrenschmidt [EMAIL PROTECTED] Status : Benjamin will investigate Subject: doesn't boot on iBook G4 References : http://lkml.org/lkml/2006/10/5/305 Submitter : Andreas Schwab [EMAIL PROTECTED] Handled-By : Mel Gorman [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2006/10/6/80 Status : patch available Subject: airo suspend fails References : http://lkml.org/lkml/2006/10/6/3 Submitter : Alex Romosan [EMAIL PROTECTED] Guilty : Sukadev Bhattiprolu [EMAIL PROTECTED] (?) commit 3b4c7d640376dbccfe80fc4f7b8772ecc7de28c5 (?) Handled-By : Dave Kleikamp [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2006/10/7/139 Status : patch available Subject: NFSv4 fails to mount (timeout) References : http://bugzilla.kernel.org/show_bug.cgi?id=7274 Submitter : Torsten Kaiser [EMAIL PROTECTED] Guilty : Trond Myklebust [EMAIL PROTECTED] commit 51b6ded4d9a94a61035deba1d8f51a54e3a3dd86 Handled-By : Trond Myklebust [EMAIL PROTECTED] Patch : http://bugzilla.kernel.org/show_bug.cgi?id=7274 Status : patch available Subject: kexec broken on x86_64 References : http://lkml.org/lkml/2006/10/5/86 Submitter : Magnus Damm [EMAIL PROTECTED] Handled-By : Vivek Goyal [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2006/10/5/199 Status : patch available Subject: strange ieee1394 messages References : http://lkml.org/lkml/2006/10/5/154 Submitter : Alistair John Strachan [EMAIL PROTECTED] Guilty : Stefan Richter [EMAIL PROTECTED] commit d2f119fe319528da8c76a1107459d6f478cbf28c Handled-By : Stefan Richter [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2006/10/6/235 Status : harmless, patch available - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.19-rc1: known regressions (v2)
Cc: Linus Torvalds [EMAIL PROTECTED], Linux Kernel Mailing List linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Prakash Punnoor [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Steve Fox [EMAIL PROTECTED], netdev@vger.kernel.org, Michael S. Tsirkin [EMAIL PROTECTED], [EMAIL PROTECTED], linux-acpi@vger.kernel.org, Pavel Machek [EMAIL PROTECTED], Olaf Hering [EMAIL PROTECTED], Antonino Daplas [EMAIL PROTECTED], [EMAIL PROTECTED], Thierry Vignaud [EMAIL PROTECTED], [EMAIL PROTECTED], linux-ide@vger.kernel.org, Ernst Herzberg [EMAIL PROTECTED], Matthieu Castet [EMAIL PROTECTED], linux-usb-devel@lists.sourceforge.net, Jens Axboe [EMAIL PROTECTED], Benjamin Herrenschmidt [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Andreas Schwab [EMAIL PROTECTED], Mel Gorman [EMAIL PROTECTED], Alex Romosan [EMAIL PROTECTED], Sukadev Bhattiprolu [EMAIL PROTECTED] com, Dave Kleikamp [EMAIL PROTECTED], Torsten Kaiser [EMAIL PROTECTED], Magnus Damm [EMAIL PROTECTED], Vivek Goyal [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Alistair John Strachan [EMAIL PROTECTED], Stefan Richter [EMAIL PROTECTED], [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Network Appliance Inc Date: Sun, 08 Oct 2006 00:43:35 -0400 Message-Id: [EMAIL PROTECTED] Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 On Sat, 2006-10-07 at 23:46 +0200, Adrian Bunk wrote: Subject: NFSv4 fails to mount (timeout) References : http://bugzilla.kernel.org/show_bug.cgi?id=7274 Submitter : Torsten Kaiser [EMAIL PROTECTED] Guilty : Trond Myklebust [EMAIL PROTECTED] commit 51b6ded4d9a94a61035deba1d8f51a54e3a3dd86 Handled-By : Trond Myklebust [EMAIL PROTECTED] Patch : http://bugzilla.kernel.org/show_bug.cgi?id=7274 Status : patch available Thanks... Always nice to hear that you have been judged and found guilty. Now go and reread that fucking bug report... - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.19-rc1: known regressions (v2)
Hi, Adrian Bunk wrote: This email lists some known regressions in 2.6.19-rc1 compared to 2.6.18 that are not yet fixed Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you was declared guilty for a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: ueagle-atm Oops References : http://lkml.org/lkml/2006/10/6/390 Submitter : Ernst Herzberg [EMAIL PROTECTED] Handled-By : Matthieu Castet [EMAIL PROTECTED] Status : unknown Guilty : http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e7ccdfec087f02930c5cdc81143d4a045ae8d361 Patch available at https://mail.gna.org/public/ueagleatm-dev/2006-10/msg00022.html , but some cleaning is need (I wasn't aware of USB: fix __must_check warnings in drivers/usb/atm/ patch). Matthieu - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb/hid: The HID Simple Driver Interface 0.3.2 (core)
(I didn't get Dmitry's original mail, so replying here) [EMAIL PROTECTED] wrote: Dmitry Torokhov wrote: Then there is issue with automatic loading of these sub-drivers. How do they get loaded? Or we force everything to be built-in making HID module very fat (like psmouse got pretty fat, but with HID prtential for it to get very fat is much bigger). The better way would be to split hid-input into a library module that parses hid usages and reports and is shared between device-specific modules that are real drivers (usb-drivers, not hid-sub-drivers). One possibility is to do that with symbol_request() and friends. That would not be pretty though, imho. DVB subsystem uses that currently to load frontend modules dynamically, see dvb_attach() and dvb_frontend_detach() in drivers/media/dvb/dvb-core/dvbdev.h and drivers/media/dvb/dvb-core/dvb_frontend.c. -- Anssi Hannula - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] Mitsumi USB FDD 061M: UNUSUAL_DEV multilun fix
Hi, this fixes multiple lun detection on the new Mitsumi USB Floppy drive. Bye, Toby Here are the infos about the device: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 8 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=03ee ProdID=6901 Rev= 2.00 S: Manufacturer=MITSUMI S: Product=MITSUMI USB FDD 061M C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=04 Prot=00 Driver=usb-storage E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 2 Ivl=127ms This is the patch: --- unusual_devs.h 2006-09-20 05:42:06.0 +0200 +++ /tmp/unusual_devs.h 2006-10-08 20:58:18.0 +0200 @@ -61,6 +61,13 @@ US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_SINGLE_LUN ), +/* Reported by Tobias Lorenz [EMAIL PROTECTED] */ +UNUSUAL_DEV( 0x03ee, 0x6901, 0x, 0x0002, + MITSUMI, + MITSUMI USB FDD 061M, + US_SC_DEVICE, US_PR_DEVICE, NULL, + US_FL_SINGLE_LUN ), + /* Reported by Rodolfo Quesada [EMAIL PROTECTED] */ UNUSUAL_DEV( 0x03ee, 0x6906, 0x0003, 0x0003, VIA Technologies Inc., - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] Mitsumi USB FDD 061M: UNUSUAL_DEV multilun fix
On Sun, 8 Oct 2006 21:03:49 +0200, Tobias Lorenz [EMAIL PROTECTED] wrote: this fixes multiple lun detection on the new Mitsumi USB Floppy drive. This looks good, but whatever has happened to making all devices with UFI-protocol to report 1 LUN? I checked 2.6.18, and that code doesn't seem to be present. In the absense of it, the patch looks good (only in the future please make it with -p1 nesting, Tobias) -- Pete - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] error to be returned while suspended
Hi!
OK, let me state the basics.
To get real power savings, we:
- blank the display
- spin down the hard drive
- put the CPU into an ACPI sleep state
To do the latter well, we need to make sure there's no DMA. It is
important that less or little DMA will not help. We need no DMA.
So we need to handle the commonest scenarios fully.
I dare say that the commonest scenario involving USB is a laptop with
an input device attached. Input devices are for practical purposes always
opened. A simple resume upon open and suspend upon close is useless.
Okay, but you can simply do autosuspend with remote wakeup completely
inside input driver. You do ot need it to be controlled from X... at
most you need one variable ('autosuspend_inactivity_timeout')
controlled from userland.
That's what we already do for hdd spindown... you simply tell disk to
aitospindown after X seconds of inactivity.
The firmware in the drive supplies this function. It's hardly by choice
that it is made available. The power management functions without
timeout are also exported. For other power control features like
cpu frequency considerable effort has been made to export them to
user space.
A simple timeout solution has drawbacks.
- there's no guarantee the user wants wakeup (think laptop on
crowded table)
If you do not want wakeups (= do not want any input from that
device), then close that device.
- you want to suspend immediately when you blank the screen (or switch to
a text console)
I kind-of understand when you blank, but I do not think this
mandatory. Why would you want to suspend when switching to text
console? Am I no longer allowed to use gpm?
- you want to consider all devices' activity. I am not pleased if my mouse
becomes less responsive just because I used only the keyboard for a
few minutes. Coordinating this inside the driver is hard as some input
devices might well be not usb (eg. bluetooth mouse, usb tablet)
Yep, that would be nice; but not at price of /sys/.../power/state like
monstrosity that never ever worked properly.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
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] Mitsumi USB FDD 061M: UNUSUAL_DEV multilun fix
On Sun, Oct 08, 2006 at 12:14:17PM -0700, Pete Zaitcev wrote: On Sun, 8 Oct 2006 21:03:49 +0200, Tobias Lorenz [EMAIL PROTECTED] wrote: this fixes multiple lun detection on the new Mitsumi USB Floppy drive. This looks good, but whatever has happened to making all devices with UFI-protocol to report 1 LUN? I checked 2.6.18, and that code doesn't seem to be present. In the absense of it, the patch looks good (only in the future please make it with -p1 nesting, Tobias) I think the code to support UFI's mechanism for indicating LUN not present is pending merge right now. I believe I saw it go into Greg's tree. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I need a computer? -- Customer User Friendly, 2/19/1998 pgpFIbLWLwQiG.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ 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] error to be returned while suspended
Hi! That is, the standard model is useless? I think you've made a few strange leaps of logic there ... care to fill in those gaps and explain just _why_ that standard model is useless??? Recall by the way that the autosuspend stuff kicked off with discussions about exactly how to make sure that Linux could get the power savings inherent in suspending USB root hubs, with remote wakeup enabling use of the mouse on that keyboard. (I remember Len Brown talking to me a few years back about how that was the last 2W per controller easily available to save power on Centrino laptops ... now we're almost ready to claim that savings.) The most obvious model for suspending keyboards or mice is an inactivity timeout (with the timeout limit set from userspace), but other policies certainly could be useful in specific circumstances. Considering that we have virtually no autosuspend capability now, taking the first few simple steps will be a big help. Just getting an infrastructure in place is a good start, even without a userspace API. Later on, when we have a better idea of what we want, bells and whistles can be added. AOLMee too/AOL Please, lets do few autosuspend things, and when we know how it looks, we can think about doing something more advanced. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] /sys/.../power/state Re: error to be returned while suspended
Hi! The power management functions without timeout are also exported. For other power control features like cpu frequency considerable effort has been made to export them to user space. Yes, and many of us use the much lighter weight kernel based control models by preference. Why waste hundreds of Kbytes of userspace for a daemon when a few hundred bytes of kernel code can implement a better and more reactive kernel policy for cpufreq? That's an important aspect. How about implementing autosuspend first and keeping the sysfs-based suspension for now? If autosuspend Current sysfs-based suspension allows people to do bad stuff to drivers, like confusing them, oopsing them, etc. It is so broken that it can not be fixed. (When I suspend my USB this way, I end up with dead USB. When I suspend my sound card, I get any soundcard users in unrecoverable D state.) Now... you can prove me wrong, but that likely means auditing all the drivers with suspend() and/or resume() methods. I'm not prepared to do that work... are you? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] error to be returned while suspended
Am Sonntag, 8. Oktober 2006 21:36 schrieb Pavel Machek: AOLMee too/AOL Please, lets do few autosuspend things, and when we know how it looks, we can think about doing something more advanced. Very well, which drivers do you want first? Regards Oliver - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] applying autosuspend patches
Hi Alan, I am getting rejects applying the autosuspend parts of Greg's tree. Could you post your version again? Regards Oliver - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] usbmon: control the max amount of captured data for eachurb
From: Paolo Abeni [EMAIL PROTECTED]
An ioctl method is added to each usbmon text files. The ioctl implements
two operation: retrieving the max size of data that usbmon is able to
capture for each URB, and changing this value.
Captured data is stored in buffers allocated from a slab cache; when the
max data value is changed, the old slab cache is destroyed, all captured
data is discarded and a new slab is created, with appropriate buffer
size. The size of the buffer used to format the data passed to user
space is changed accordingly.
This change is useful to get full content of exchanged URB. A recently
introduced libpcap patch make it possible to sniff from USB port via
usbmon, but the full USB packet contents is currently unavailable.
Signed-off-by: Paolo Abeni [EMAIL PROTECTED]
---
patch against linux 2.6.18
mon_text.c | 178
+++--
1 file changed, 161 insertions(+), 17 deletions(-)
--- linux-2.6.18-vanilla/drivers/usb/mon/mon_text.c
+++ linux-2.6.18-monioctl/drivers/usb/mon/mon_text.c
@@ -9,15 +9,17 @@
#include linux/usb.h
#include linux/time.h
#include linux/mutex.h
+#include linux/ioctl.h
#include asm/uaccess.h
#include usb_mon.h
/*
- * No, we do not want arbitrarily long data strings.
- * Use the binary interface if you want to capture bulk data!
+ * This limit can be changed using ioctl
*/
-#define DATA_MAX 32
+#define DATA_DFL 32
+#define DATA_MIN 16
+#define DATA_MAX 1024
/*
* Defined by USB 2.0 clause 9.3, table 9.2.
@@ -33,6 +35,15 @@
#define EVENT_MAX (2*PAGE_SIZE / sizeof(struct mon_event_text))
#define PRINTF_DFL 160
+#define PRINTF_MIN 120
+
+/* ioctl macros */
+#define MON_IOC_MAGIC 0xff
+
+#define MON_IOCS_DATA_MAX _IOW(MON_IOC_MAGIC, 1, int)
+#define MON_IOCG_DATA_MAX _IOR(MON_IOC_MAGIC, 2, int)
+
+#define MON_IOC_MAXNR 2
struct mon_event_text {
struct list_head e_link;
@@ -45,12 +56,13 @@ struct mon_event_text {
char setup_flag;
char data_flag;
unsigned char setup[SETUP_MAX];
- unsigned char data[DATA_MAX];
+ unsigned char* data;
};
#define SLAB_NAME_SZ 30
struct mon_reader_text {
kmem_cache_t *e_slab;
+ unsigned data_max;
int nevents;
struct list_head e_list;
struct mon_reader r;/* In C, parent class can be placed anywhere */
@@ -91,14 +103,14 @@ static inline char mon_text_get_setup(st
}
static inline char mon_text_get_data(struct mon_event_text *ep, struct urb
*urb,
-int len, char ev_type)
+int len, char ev_type, int data_max)
{
int pipe = urb-pipe;
if (len = 0)
return 'L';
- if (len = DATA_MAX)
- len = DATA_MAX;
+ if (len = data_max)
+ len = data_max;
if (usb_pipein(pipe)) {
if (ev_type == 'S')
@@ -138,6 +150,84 @@ static inline unsigned int mon_get_times
return stamp;
}
+/*
+ * [Re]allocate printf buffer and slab cache accoring to specified sizes.
+ * mon_lock must be hold due to mon_reader_add/remove
+ */
+static int mon_text_resize(struct mon_reader_text* rp, int printf_size,
+int data_max)
+{
+ unsigned long flags;
+ int ret=0, pos;
+ kmem_cache_t * new_e_slab;
+ char* new_printf_buf, id;
+ char new_name[SLAB_NAME_SZ];
+
+ /* remove this reader from list to avoid urb_submit accessing slab
+* cache*/
+ mutex_lock(mon_lock);
+ mon_reader_del(rp-r.m_bus, rp-r);
+ mutex_unlock(mon_lock);
+
+ /* try to allocate early all required buffer and preserve old values
+* in case of failure */
+ if (!(new_printf_buf = kmalloc(printf_size, GFP_KERNEL)))
+ {
+ ret = -1;
+ goto out;
+ }
+
+ /* avoid trying to create two slab with same name: it will fail
+* swap the last char from '0' to '1' and vice versa*/
+ strcpy(new_name, rp-slab_name);
+ pos = strlen(new_name) - 1;
+ id = new_name[pos];
+ new_name[pos] = (1 - (id - '0')) + '0';
+
+ if (!(new_e_slab = kmem_cache_create(new_name,
+ sizeof(struct mon_event_text)+data_max, sizeof(long), 0,
+ mon_text_ctor, NULL))) {
+ kfree(new_printf_buf);
+ ret = -1;
+ goto out;
+ }
+
+ /* hold printf lock to avoid read syscall accessing printf_buf/slab*/
+ mutex_lock(rp-printf_lock);
+ if (rp-e_slab)
+ kmem_cache_destroy(rp-e_slab);
+ rp-e_slab = new_e_slab;
+
+ /* event list must be flush because old entries have differnd size */
+ spin_lock_irqsave(rp-r.m_bus-lock, flags);
+ INIT_LIST_HEAD(rp-e_list);
+ rp-nevents = 0;
+ spin_unlock_irqrestore(rp-r.m_bus-lock, flags);
+ if (rp-printf_buf)
+ kfree(rp-printf_buf);
+ rp-printf_buf = new_printf_buf;
+ rp-printf_size = printf_size;
+
Re: [linux-usb-devel] [PATCH] usbmon: control the max amount of captured data for eachurb
On Sun, 08 Oct 2006 22:34:17 +0200, Paolo Abeni [EMAIL PROTECTED] wrote:
An ioctl method is added to each usbmon text files. The ioctl implements
two operation: retrieving the max size of data that usbmon is able to
capture for each URB, and changing this value.
[...]
This change is useful to get full content of exchanged URB. A recently
introduced libpcap patch make it possible to sniff from USB port via
usbmon, but the full USB packet contents is currently unavailable.
I wish whoever did the libpcap fixes designed a new, non-text API instead.
There is no reason to format URBs into text for that.
Is there no chance of that happening?
Also, the patch is a little dirty stylistically, not to mention full of
little, annoying buglets.
+/* ioctl macros */
+#define MON_IOC_MAGIC 0xff
Oh bah. Could you at least use something like 0x92 or whatever?
You are going to confuse strace and if you do this.
+#define MON_IOCS_DATA_MAX _IOW(MON_IOC_MAGIC, 1, int)
+#define MON_IOCG_DATA_MAX _IOR(MON_IOC_MAGIC, 2, int)
Is that right? You are passing pointers to int, so ioctl numbers get
wrong sizes. This is important on some platforms, and doubly so when
32-bit binaries run under 64-bit kernel.
+ int ret=0, pos;
This needs to be made prettier, on separate lines and with spaces.
+ /* try to allocate early all required buffer and preserve old values
+ * in case of failure */
+ if (!(new_printf_buf = kmalloc(printf_size, GFP_KERNEL)))
+ {
I'd appreciate if this looked like this:
/*
* Blah blah blah
*/
if ((new_prinf_buf = kmalloc(size, GFP)) == NULL) {
}
+ if (!(new_e_slab = kmem_cache_create(new_name,
+ sizeof(struct mon_event_text)+data_max, sizeof(long), 0,
+ mon_text_ctor, NULL))) {
+ kfree(new_printf_buf);
+ ret = -1;
+ goto out;
+ }
This is a highly dubious way to allocate, when we talk about data_max 1024.
+ /* event list must be flush because old entries have differnd size */
flushed, and different.
+static inline struct mon_event_text * mon_event_alloc(
+struct mon_reader_text *rp)
+{
+ struct mon_event_text *ep = kmem_cache_alloc(rp-e_slab, SLAB_ATOMIC);
+ if (!ep)
+ return 0;
+ ep-data = ((unsigned char*)ep) + sizeof(struct mon_event_text);
+ return ep;
+}
Aside from needlessly made inline, this is not bad. But you
obviously thought about out-of-line data, why stop here?
@@ -249,7 +340,7 @@ static int mon_text_open(struct inode *i
INIT_LIST_HEAD(rp-e_list);
init_waitqueue_head(rp-wait);
mutex_init(rp-printf_lock);
-
+
rp-printf_size = PRINTF_DFL;
Pointless whitespace addition. Don't.
+ int ret=0, new_data_max;
Same syntax as before.
+ u32 __user *argp = (u32 __user *)arg;
[.]
+ case MON_IOCS_DATA_MAX:
+ if (get_user(new_data_max, argp))
This obviously is not needed, because the new size would fit the ioctl
argument just fine.
+ default:
+ ret = -ENOTTY;
Good!
Anyway, maybe I should look into it closer. What do you use on top of
libpcap? Wireshark?
-- Pete
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
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] error to be returned while suspended
On Sun 2006-10-08 21:57:17, Oliver Neukum wrote: Am Sonntag, 8. Oktober 2006 21:36 schrieb Pavel Machek: AOLMee too/AOL Please, lets do few autosuspend things, and when we know how it looks, we can think about doing something more advanced. Very well, which drivers do you want first? USB mouse would be very nice first step. Way less usb keyboards are used, and that would be very nice second step. If you want to try something different, autosuspending SATA can save about 1W on my machine... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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 0/3] [RESEND] mcs7830 patch set
This is the same set of patches as posted last month, slightly adapted to apply on the current 2.6.19-rc kernel. Arnd -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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 1/3] driver for mcs7830 (aka DeLOCK) USB ethernet adapter
This driver adds support for the DeLOCK USB ethernet adapter
and potentially others based on the MosChip MCS7830 chip.
It is based on the usbnet and asix drivers as well as the
original device driver provided by MosChip, which in turn
was based on the usbnet driver.
It has been tested successfully on an OHCI, but interestingly
there seems to be a problem with the mcs7830 when connected to
the ICH6/EHCI in my thinkpad: it keeps receiving lots of
broken packets in the RX interrupt. The problem goes away when
I'm using an active USB hub, so I assume it's not related to
the device driver, but rather to the hardware.
Signed-off-by: David Brownell [EMAIL PROTECTED]
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
---
Index: linux-cg/drivers/usb/net/mcs7830.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-cg/drivers/usb/net/mcs7830.c 2006-10-09 00:01:54.0 +0200
@@ -0,0 +1,525 @@
+/*
+ * MosChips MCS7830 based USB 2.0 Ethernet Devices
+ *
+ * based on usbnet.c, asix.c and the vendor provided mcs7830 driver
+ *
+ * Copyright (C) 2006 Arnd Bergmann [EMAIL PROTECTED]
+ * Copyright (C) 2003-2005 David Hollis [EMAIL PROTECTED]
+ * Copyright (C) 2005 Phil Chang [EMAIL PROTECTED]
+ * Copyright (c) 2002-2003 TiVo Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/crc32.h
+#include linux/etherdevice.h
+#include linux/ethtool.h
+#include linux/init.h
+#include linux/mii.h
+#include linux/module.h
+#include linux/netdevice.h
+#include linux/usb.h
+
+#include usbnet.h
+
+/* requests */
+#define MCS7830_RD_BMREQ (USB_DIR_IN | USB_TYPE_VENDOR | \
+USB_RECIP_DEVICE)
+#define MCS7830_WR_BMREQ (USB_DIR_OUT | USB_TYPE_VENDOR | \
+USB_RECIP_DEVICE)
+#define MCS7830_RD_BREQ0x0E
+#define MCS7830_WR_BREQ0x0D
+
+#define MCS7830_CTRL_TIMEOUT 1000
+#define MCS7830_MAX_MCAST 64
+
+#define MCS7830_VENDOR_ID 0x9710
+#define MCS7830_PRODUCT_ID 0x7830
+
+#define MCS7830_MII_ADVERTISE (ADVERTISE_PAUSE_CAP | ADVERTISE_100FULL | \
+ADVERTISE_100HALF | ADVERTISE_10FULL | \
+ADVERTISE_10HALF | ADVERTISE_CSMA)
+
+/* HIF_REG_XX coressponding index value */
+enum {
+ HIF_REG_MULTICAST_HASH = 0x00,
+ HIF_REG_PACKET_GAP1 = 0x08,
+ HIF_REG_PACKET_GAP2 = 0x09,
+ HIF_REG_PHY_DATA= 0x0a,
+ HIF_REG_PHY_CMD1= 0x0c,
+ HIF_REG_PHY_CMD1_READ= 0x40,
+ HIF_REG_PHY_CMD1_WRITE = 0x20,
+ HIF_REG_PHY_CMD1_PHYADDR = 0x01,
+ HIF_REG_PHY_CMD2= 0x0d,
+ HIF_REG_PHY_CMD2_PEND_FLAG_BIT = 0x80,
+ HIF_REG_PHY_CMD2_READY_FLAG_BIT = 0x40,
+ HIF_REG_CONFIG = 0x0e,
+ HIF_REG_CONFIG_CFG = 0x80,
+ HIF_REG_CONFIG_SPEED100 = 0x40,
+ HIF_REG_CONFIG_FULLDUPLEX_ENABLE = 0x20,
+ HIF_REG_CONFIG_RXENABLE = 0x10,
+ HIF_REG_CONFIG_TXENABLE = 0x08,
+ HIF_REG_CONFIG_SLEEPMODE = 0x04,
+ HIF_REG_CONFIG_ALLMULTICAST = 0x02,
+ HIF_REG_CONFIG_PROMISCIOUS = 0x01,
+ HIF_REG_ETHERNET_ADDR = 0x0f,
+ HIF_REG_22 = 0x15,
+ HIF_REG_PAUSE_THRESHOLD = 0x16,
+ HIF_REG_PAUSE_THRESHOLD_DEFAULT = 0,
+};
+
+struct mcs7830_data {
+ u8 multi_filter[8];
+ u8 config;
+};
+
+static const char driver_name[] = MOSCHIP usb-ethernet driver;
+
+static int mcs7830_get_reg(struct usbnet *dev, u16 index, u16 size, void *data)
+{
+ struct usb_device *xdev = dev-udev;
+ int ret;
+
+ ret = usb_control_msg(xdev, usb_rcvctrlpipe(xdev, 0), MCS7830_RD_BREQ,
+ MCS7830_RD_BMREQ, 0x, index, data,
+ size, msecs_to_jiffies(MCS7830_CTRL_TIMEOUT));
+ return ret;
+}
+
+static int mcs7830_set_reg(struct usbnet *dev, u16 index, u16
[linux-usb-devel] [PATCH 2/3] usbnet: improve generic ethtool support
This adds generic support for the ethtool commands get_settings,
set_settings, get_link and nway_reset to usbnet. These are now
implemented using mii functions when a low-level driver supports
mdio_read/mdio_write and does not override the usbnet ethtool
commands with its own.
Currently, this applies to the asix and the mcs7830 drivers.
I have tested it on mcs7830.
Acked-by: David Hollis [EMAIL PROTECTED]
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
---
Index: linux-cg/drivers/usb/net/asix.c
===
--- linux-cg.orig/drivers/usb/net/asix.c2006-10-08 19:14:47.0
+0200
+++ linux-cg/drivers/usb/net/asix.c 2006-10-08 23:05:08.0 +0200
@@ -700,32 +700,6 @@
info-eedump_len = data-eeprom_len;
}
-static int asix_get_settings(struct net_device *net, struct ethtool_cmd *cmd)
-{
- struct usbnet *dev = netdev_priv(net);
-
- return mii_ethtool_gset(dev-mii,cmd);
-}
-
-static int asix_set_settings(struct net_device *net, struct ethtool_cmd *cmd)
-{
- struct usbnet *dev = netdev_priv(net);
- int res = mii_ethtool_sset(dev-mii,cmd);
-
- /* link speed/duplex might have changed */
- if (dev-driver_info-link_reset)
- dev-driver_info-link_reset(dev);
-
- return res;
-}
-
-static int asix_nway_reset(struct net_device *net)
-{
- struct usbnet *dev = netdev_priv(net);
-
- return mii_nway_restart(dev-mii);
-}
-
static u32 asix_get_link(struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
@@ -746,15 +720,15 @@
static struct ethtool_ops ax88172_ethtool_ops = {
.get_drvinfo= asix_get_drvinfo,
.get_link = asix_get_link,
- .nway_reset = asix_nway_reset,
.get_msglevel = usbnet_get_msglevel,
.set_msglevel = usbnet_set_msglevel,
.get_wol= asix_get_wol,
.set_wol= asix_set_wol,
.get_eeprom_len = asix_get_eeprom_len,
.get_eeprom = asix_get_eeprom,
- .get_settings = asix_get_settings,
- .set_settings = asix_set_settings,
+ .get_settings = usbnet_get_settings,
+ .set_settings = usbnet_set_settings,
+ .nway_reset = usbnet_nway_reset,
};
static void ax88172_set_multicast(struct net_device *net)
@@ -885,15 +859,15 @@
static struct ethtool_ops ax88772_ethtool_ops = {
.get_drvinfo= asix_get_drvinfo,
.get_link = asix_get_link,
- .nway_reset = asix_nway_reset,
.get_msglevel = usbnet_get_msglevel,
.set_msglevel = usbnet_set_msglevel,
.get_wol= asix_get_wol,
.set_wol= asix_set_wol,
.get_eeprom_len = asix_get_eeprom_len,
.get_eeprom = asix_get_eeprom,
- .get_settings = asix_get_settings,
- .set_settings = asix_set_settings,
+ .get_settings = usbnet_get_settings,
+ .set_settings = usbnet_set_settings,
+ .nway_reset = usbnet_nway_reset,
};
static int ax88772_link_reset(struct usbnet *dev)
@@ -1046,15 +1020,15 @@
static struct ethtool_ops ax88178_ethtool_ops = {
.get_drvinfo= asix_get_drvinfo,
.get_link = asix_get_link,
- .nway_reset = asix_nway_reset,
.get_msglevel = usbnet_get_msglevel,
.set_msglevel = usbnet_set_msglevel,
.get_wol= asix_get_wol,
.set_wol= asix_set_wol,
.get_eeprom_len = asix_get_eeprom_len,
.get_eeprom = asix_get_eeprom,
- .get_settings = asix_get_settings,
- .set_settings = asix_set_settings,
+ .get_settings = usbnet_get_settings,
+ .set_settings = usbnet_set_settings,
+ .nway_reset = usbnet_nway_reset,
};
static int marvell_phy_init(struct usbnet *dev)
Index: linux-cg/drivers/usb/net/mcs7830.c
===
--- linux-cg.orig/drivers/usb/net/mcs7830.c 2006-10-08 19:16:24.0
+0200
+++ linux-cg/drivers/usb/net/mcs7830.c 2006-10-08 23:02:26.0 +0200
@@ -430,8 +430,12 @@
.get_regs = mcs7830_get_regs,
/* common usbnet calls */
+ .get_link = usbnet_get_link,
.get_msglevel = usbnet_get_msglevel,
.set_msglevel = usbnet_set_msglevel,
+ .get_settings = usbnet_get_settings,
+ .set_settings = usbnet_set_settings,
+ .nway_reset = usbnet_nway_reset,
};
static int mcs7830_bind(struct usbnet *dev, struct usb_interface *udev)
Index:
[linux-usb-devel] [PATCH 3/3] usbnet: add a mutex around phy register access
When working on the mcs7830, I noticed the need for a mutex in its mdio_read/mdio_write functions. A related problem seems to be present in the asix driver in the respective functions. This introduces a mutex in the common usbnet driver and uses it from the two hardware specific drivers. Acked-by: David Hollis [EMAIL PROTECTED] Signed-off-by: Arnd Bergmann [EMAIL PROTECTED] --- Index: linux-cg/drivers/usb/net/asix.c === --- linux-cg.orig/drivers/usb/net/asix.c2006-10-08 19:18:31.0 +0200 +++ linux-cg/drivers/usb/net/asix.c 2006-10-08 19:22:22.0 +0200 @@ -569,10 +569,12 @@ struct usbnet *dev = netdev_priv(netdev); u16 res; + mutex_lock(dev-phy_mutex); asix_set_sw_mii(dev); asix_read_cmd(dev, AX_CMD_READ_MII_REG, phy_id, (__u16)loc, 2, (u16 *)res); asix_set_hw_mii(dev); + mutex_unlock(dev-phy_mutex); devdbg(dev, asix_mdio_read() phy_id=0x%02x, loc=0x%02x, returns=0x%04x, phy_id, loc, le16_to_cpu(res 0x)); @@ -586,10 +588,12 @@ u16 res = cpu_to_le16(val); devdbg(dev, asix_mdio_write() phy_id=0x%02x, loc=0x%02x, val=0x%04x, phy_id, loc, val); + mutex_lock(dev-phy_mutex); asix_set_sw_mii(dev); asix_write_cmd(dev, AX_CMD_WRITE_MII_REG, phy_id, (__u16)loc, 2, (u16 *)res); asix_set_hw_mii(dev); + mutex_unlock(dev-phy_mutex); } /* Get the PHY Identifier from the PHYSID1 PHYSID2 MII registers */ Index: linux-cg/drivers/usb/net/usbnet.c === --- linux-cg.orig/drivers/usb/net/usbnet.c 2006-10-08 19:19:33.0 +0200 +++ linux-cg/drivers/usb/net/usbnet.c 2006-10-08 19:21:33.0 +0200 @@ -1144,6 +1144,7 @@ dev-delay.function = usbnet_bh; dev-delay.data = (unsigned long) dev; init_timer (dev-delay); + mutex_init (dev-phy_mutex); SET_MODULE_OWNER (net); dev-net = net; Index: linux-cg/drivers/usb/net/usbnet.h === --- linux-cg.orig/drivers/usb/net/usbnet.h 2006-10-08 19:16:47.0 +0200 +++ linux-cg/drivers/usb/net/usbnet.h 2006-10-08 19:21:33.0 +0200 @@ -30,6 +30,7 @@ struct usb_device *udev; struct driver_info *driver_info; wait_queue_head_t *wait; + struct mutexphy_mutex; /* i/o info: pipes etc */ unsignedin, out; Index: linux-cg/drivers/usb/net/mcs7830.c === --- linux-cg.orig/drivers/usb/net/mcs7830.c 2006-10-08 19:16:47.0 +0200 +++ linux-cg/drivers/usb/net/mcs7830.c 2006-10-08 19:21:33.0 +0200 @@ -184,6 +184,7 @@ HIF_REG_PHY_CMD2_PEND_FLAG_BIT | index, }; + mutex_lock(dev-phy_mutex); /* write the MII command */ ret = mcs7830_set_reg(dev, HIF_REG_PHY_CMD1, 2, cmd); if (ret 0) @@ -208,6 +209,7 @@ dev_dbg(dev-udev-dev, read PHY reg %02x: %04x (%d tries)\n, index, val, i); out: + mutex_unlock(dev-phy_mutex); return ret; } @@ -222,6 +224,8 @@ HIF_REG_PHY_CMD2_PEND_FLAG_BIT | (index 0x1F), }; + mutex_lock(dev-phy_mutex); + /* write the new register contents */ le_val = cpu_to_le16(val); ret = mcs7830_set_reg(dev, HIF_REG_PHY_DATA, 2, le_val); @@ -248,6 +252,7 @@ dev_dbg(dev-udev-dev, write PHY reg %02x: %04x (%d tries)\n, index, val, i); out: + mutex_unlock(dev-phy_mutex); return ret; } -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] Mitsumi USB FDD 061M: UNUSUAL_DEV multilun fix
Hi, this fixes multiple lun detection on the new Mitsumi USB Floppy drive. I just understand, what the bcdDeviceMin, bcdDeviceMax parameters mean. It is of course easier to adjust the bcdDevice range of the already existing Mitsumi floppy record. Here is the patch (this time with -p1 :-). Bye, Toby --- drivers/usb/storage/unusual_devs.orig.h 2006-09-20 05:42:06.0 +0200 +++ drivers/usb/storage/unusual_devs.h 2006-10-08 23:21:02.0 +0200 @@ -55,7 +55,8 @@ US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_IGNORE_RESIDUE), -UNUSUAL_DEV( 0x03ee, 0x6901, 0x, 0x0100, +/* modified by Tobias Lorenz [EMAIL PROTECTED] */ +UNUSUAL_DEV( 0x03ee, 0x6901, 0x, 0x0200, Mitsumi, USB FDD, US_SC_DEVICE, US_PR_DEVICE, NULL, - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [2.6 patch] drivers/usb/misc/ftdi-elan.c: remove dead code
The Coverity checker spotted this obviously dead code.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
--- linux-2.6/drivers/usb/misc/ftdi-elan.c.old 2006-10-09 00:22:57.0
+0200
+++ linux-2.6/drivers/usb/misc/ftdi-elan.c 2006-10-09 00:24:39.0
+0200
@@ -513,8 +513,6 @@
ftdi-disconnected += 1;
} else if (retval == -ENODEV) {
ftdi-disconnected += 1;
-} else if (retval == -ENODEV) {
-ftdi-disconnected += 1;
} else if (retval == -EILSEQ) {
ftdi-disconnected += 1;
} else {
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
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] [RFC: 2.6 patch] drivers/usb/serial/mos7840.c: remove dead code
The Coverity checker spotted this dead code.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/usb/serial/mos7840.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
--- linux-2.6/drivers/usb/serial/mos7840.c.old 2006-10-09 00:31:41.0
+0200
+++ linux-2.6/drivers/usb/serial/mos7840.c 2006-10-09 00:32:12.0
+0200
@@ -1420,7 +1420,6 @@
int i;
int bytes_sent = 0;
int transfer_size;
- int from_user = 0;
struct moschip_port *mos7840_port;
struct usb_serial *serial;
@@ -1511,15 +1510,7 @@
}
transfer_size = min(count, URB_TRANSFER_BUFFER_SIZE);
- if (from_user) {
- if (copy_from_user
- (urb-transfer_buffer, current_position, transfer_size)) {
- bytes_sent = -EFAULT;
- goto exit;
- }
- } else {
- memcpy(urb-transfer_buffer, current_position, transfer_size);
- }
+ memcpy(urb-transfer_buffer, current_position, transfer_size);
/* fill urb with data and submit */
usb_fill_bulk_urb(urb,
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [2.6 patch] drivers/usb/serial/mos7840.c: fix a check-after-dereference
This patch fixes an obvious check-after-dereference spotted by the
Coverity checker.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
--- linux-2.6/drivers/usb/serial/mos7840.c.old 2006-10-09 00:35:49.0
+0200
+++ linux-2.6/drivers/usb/serial/mos7840.c 2006-10-09 00:36:28.0
+0200
@@ -2412,11 +2412,12 @@
}
mos7840_port = mos7840_get_port_private(port);
- tty = mos7840_port-port-tty;
if (mos7840_port == NULL)
return -1;
+ tty = mos7840_port-port-tty;
+
dbg(%s - port %d, cmd = 0x%x, __FUNCTION__, port-number, cmd);
switch (cmd) {
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
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 15/15] usbaudio retries EL2NSYNC
On 10/7/06, David Brownell [EMAIL PROTECTED] wrote: On Friday 06 October 2006 9:38 pm, Christopher Monty Montgomery wrote: What do I have or what do I want? I *want* 2-5ms from sample to playback. MacOSX can do it. Windows can do it. We can't, at least not yet. We can't ... why? Because IRQ latency is too high, or something else? Oh, Hell. I think I know why. Because low-latency is only ever one URB deep. There's no second URB waiting when the first completes. So the stream is shut down. I think I may need to stick to my guns on the 'release on last URB is broken' argument. Drat. I was ready to admit defeat and just let it go. Monty - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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 15/15] ehci-hcd: full-featured EHCI budgeter/scheduler
For example, let's say an URB is submitted for slot S, just as S's microframe is starting. ehci-hcd adds the URB into the hardware schedule; was it in time for the controller to see it? Right now, that attempt would be outright rejected. ehci-sched will not (and never would) schedule into the currently active frame. In fact, it would not schedule into any frame within 'SCHEDULE_SLOP' of the active frame. I did not change that behavior. No way to know until the microframe is finished. The only way ehci-hcd can make an accurate report in this case is to _always_ report that the slot was missed -- not even _try_ to add it into the hardware schedule -- even if it might have been possible for the slot to be filled. ...or check the uframe clock when the schedule is complete and if it still precedes the slot... [or are you worried about caching and propogation of changes?] Actually that's a good description of the case where that -EXDEV fault might reasonably be reported at completion. Yes, agreed, if we really can't reliably figure it out ahead of time. And I was wrong about EHCI (at least) reporting that ... since that's the initial value for each (micro)frame's transfer status, EHCI will report that when collecting an ITD that sitll has ITD_ACTIVE set. But, hmm bug!, not (yet) SITDs with SITD_ACTIVE. (Monty, that would seem to be something you might fix in one of your patchsets ... it's trivial, but I don't want to create needless problems for your patches!) Yes, good catch. I'll make that change. Monty - Dave - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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 15/15] ehci-hcd: full-featured EHCI budgeter/scheduler
On 10/8/06, Christopher Monty Montgomery [EMAIL PROTECTED] wrote: Right now, that attempt would be outright rejected. ehci-sched will not (and never would) schedule into the currently active frame. In fact, it would not schedule into any frame within 'SCHEDULE_SLOP' of the active frame. I did not change that behavior. Actually, I erred slightly above; the original ehci would not perform initial scheduling less than SCHEDULE_SLOP frames out, but if a schedule had already been planned, it would not do any checks before filling a slot. So it would try to schedule current frame, I believe. So, I did change the behavior and that's an error in my code; it should not be enforcing that were' *always* at least SCHEDULE_SLOP deep. Chalk up one more bug in the patchset. More importantly, this might explain why low latency never worked. There were always constant xruns that ALSA didn't detect. Please sanity check this thinking, but it explains what I observed (every submission had to reschedule)... When sample and playback are lockstep (read 64 samples, process, write them for playback, read next 64 samples, process, write them for playback), we will only ever be one URB deep. There will never be another URB waiting. So, every read and every write will complete the 'last' URB and shut the stream down. Not only does that force rescheduling, but it also means that due to the SLOP, it could not possibly be scheduled for the next slot. There would always be a gap. Is this a plausible explanation? I can put a little time in tomorrow demonstrating one way or the other with certainty if so... Monty No way to know until the microframe is finished. The only way ehci-hcd can make an accurate report in this case is to _always_ report that the slot was missed -- not even _try_ to add it into the hardware schedule -- even if it might have been possible for the slot to be filled. ...or check the uframe clock when the schedule is complete and if it still precedes the slot... [or are you worried about caching and propogation of changes?] Actually that's a good description of the case where that -EXDEV fault might reasonably be reported at completion. Yes, agreed, if we really can't reliably figure it out ahead of time. And I was wrong about EHCI (at least) reporting that ... since that's the initial value for each (micro)frame's transfer status, EHCI will report that when collecting an ITD that sitll has ITD_ACTIVE set. But, hmm bug!, not (yet) SITDs with SITD_ACTIVE. (Monty, that would seem to be something you might fix in one of your patchsets ... it's trivial, but I don't want to create needless problems for your patches!) Yes, good catch. I'll make that change. Monty - Dave - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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 15/15] usbaudio retries EL2NSYNC
On Sun, 8 Oct 2006, Christopher Monty Montgomery wrote: Oh, Hell. I think I know why. Because low-latency is only ever one URB deep. There's no second URB waiting when the first completes. So the stream is shut down. I don't know what this low-latency thing is you're referring to. But it sounds like it's trying to be _too_ low. Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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 15/15] ehci-hcd: full-featured EHCI budgeter/scheduler
On Sun, 8 Oct 2006, Christopher Monty Montgomery wrote: No way to know until the microframe is finished. The only way ehci-hcd can make an accurate report in this case is to _always_ report that the slot was missed -- not even _try_ to add it into the hardware schedule -- even if it might have been possible for the slot to be filled. ...or check the uframe clock when the schedule is complete and if it still precedes the slot... [or are you worried about caching and propogation of changes?] No, I'm just pointing out that it's not always possible to tell at submission time whether the submission was made early enough. Actually that's a good description of the case where that -EXDEV fault might reasonably be reported at completion. Yes, agreed, if we really can't reliably figure it out ahead of time. I don't like the idea of having two separate pathways for reporting the same kind of error. If one reporting technique is reliable and another isn't, why keep the unreliable one? Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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 15/15] usbaudio retries EL2NSYNC
On 10/8/06, Alan Stern [EMAIL PROTECTED] wrote: On Sun, 8 Oct 2006, Christopher Monty Montgomery wrote: Oh, Hell. I think I know why. Because low-latency is only ever one URB deep. There's no second URB waiting when the first completes. So the stream is shut down. I don't know what this low-latency thing is you're referring to. But it sounds like it's trying to be _too_ low. Professional audio applications generally specify 2-5ms turnaround. That's from sample to playback. More than about 5ms you can't do digital monitor, realtime effects or a host of other useful things sound engineers have come to expect. Monty - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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 15/15] ehci-hcd: full-featured EHCI budgeter/scheduler
On 10/8/06, Alan Stern [EMAIL PROTECTED] wrote: On Sun, 8 Oct 2006, Christopher Monty Montgomery wrote: [or are you worried about caching and propogation of changes?] No, I'm just pointing out that it's not always possible to tell at submission time whether the submission was made early enough. All xruns should be caught, no argument here. Actually that's a good description of the case where that -EXDEV fault might reasonably be reported at completion. Yes, agreed, if we really can't reliably figure it out ahead of time. I don't like the idea of having two separate pathways for reporting the same kind of error. If one reporting technique is reliable and another isn't, why keep the unreliable one? When one can say 'the underrun is happening now' and the other simply says 'an underrun happened some time ago, too late to do anything timely.' Monty - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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 15/15] ehci-hcd: full-featured EHCI budgeter/scheduler
On 10/8/06, Alan Stern [EMAIL PROTECTED] wrote: No, I'm just pointing out that it's not always possible to tell at submission time whether the submission was made early enough. Is that actually true? If the slot is filled, we look at the clock, and the clock says definitively that the filled slot would not have been processed yet... is it possible the newly filled slot would somehow be skipped? [serious question, that's why I'd asked if cache delays or some other mechanism could cause that to happen] Monty - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] applying autosuspend patches
On Sun, 8 Oct 2006, Oliver Neukum wrote: Hi Alan, I am getting rejects applying the autosuspend parts of Greg's tree. Could you post your version again? All of it is in 2.6.19-rc1 except for the last two patches. Search the linux-usb-devel archives for the most recent messages containing the strings as742 and as738; I posted new versions of them last Wednesday. as738 has a known bug (ehci-hcd's bus_resume method wakes up ports when it shouldn't), and my testing tonight has found another bug related to the interrupt-enable setting. At the moment I don't know if that second bug was introduced by the patch, was caused by some other recent changes in -rc1, or was present all along. (If you unload ehci-hcd then as742 by itself should work properly. You can use that for testing, assuming you don't mind running at full speed.) I'm going to do some more debugging tomorrow; I don't want to post the current version of the patch just yet. More on this later... Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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 15/15] usbaudio retries EL2NSYNC
On Sun, 8 Oct 2006, Christopher Monty Montgomery wrote: I don't know what this low-latency thing is you're referring to. But it sounds like it's trying to be _too_ low. Professional audio applications generally specify 2-5ms turnaround. That's from sample to playback. More than about 5ms you can't do digital monitor, realtime effects or a host of other useful things sound engineers have come to expect. Okay. Then there's nothing to stop you from putting 1 or 2 ms worth of data in each URB and keeping 2 URBs in the queue at all times. Except that you run a high risk of loss-of-sync owing to kernel latency. But that will always be true in a low-latency application. Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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 15/15] ehci-hcd: full-featured EHCI budgeter/scheduler
On Sun, 8 Oct 2006, Christopher Monty Montgomery wrote: I don't like the idea of having two separate pathways for reporting the same kind of error. If one reporting technique is reliable and another isn't, why keep the unreliable one? When one can say 'the underrun is happening now' and the other simply says 'an underrun happened some time ago, too late to do anything timely.' What difference does it make? What are you going to differently, knowing that an underrun is happening right now (and started in the very recent past) as opposed to knowing that an underrun started 2 ms ago (and may already have gotten caught back up)? And how much extra code -- and extra processing overhead -- do you want to add to your driver to handle the underrun is happening right now case? Surely in such a situation you want to _minimize_ work, not add extra processing to handle a new and unnecessary error-reporting path? Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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 15/15] ehci-hcd: full-featured EHCI budgeter/scheduler
On Sun, 8 Oct 2006, Christopher Monty Montgomery wrote: On 10/8/06, Alan Stern [EMAIL PROTECTED] wrote: No, I'm just pointing out that it's not always possible to tell at submission time whether the submission was made early enough. Is that actually true? If the slot is filled, we look at the clock, and the clock says definitively that the filled slot would not have been processed yet... is it possible the newly filled slot would somehow be skipped? In that case no, it's not possible for the newly filled slot to be skipped. But suppose you look at the clock and the clock isn't definitive one way or the other? Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb/hid: The HID Simple Driver Interface 0.3.2 (core)
Dmitry Torokhov wrote: Yes, I'd consider it a bug. Tearing down and re-creating input device generates proper hotplug notifications and userspace needs to respect them as capabilities may change even if ids stay the same. For example playing with atkbd's scroll attribute will regenerate an input device with[out] scroll capabilities but its input_id structure will stay the same. So many people said I have some wrongs here ;) it should be truth. I found our focus is howto or when send notification to userspace. Intuitional, to reload such device is rather ugly means, it should have one hotplug message for this case, and userspace handle it. If only look from design, I will agree with my argument, however, if also look from compatibility, I think I must agree your arguments. At last, you win! :D I am going to reload. PS: I found a behavior of usb subsystem, I can not sure whether it is normal. After I remove usbhid.ko, the uhci_hcd will reset device repeatly. usbcore: registered new driver usbhid /usr/src/redhat/BUILD/linux-2.6.18/drivers/usb/input/hid-core.c: v2.6:USB HID core driver usb 5-2: reset low speed USB device using uhci_hcd and address 3 usb 5-2: reset low speed USB device using uhci_hcd and address 3 usb 5-2: reset low speed USB device using uhci_hcd and address 3 usb 5-2: reset low speed USB device using uhci_hcd and address 3 usb 5-2: reset low speed USB device using uhci_hcd and address 3 Goodluck. -Liyu - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb/hid: The HID Simple Driver Interface 0.3.2 (core)
Dmitry Torokhov wrote: Yes, I'd consider it a bug. Tearing down and re-creating input device generates proper hotplug notifications and userspace needs to respect them as capabilities may change even if ids stay the same. For example playing with atkbd's scroll attribute will regenerate an input device with[out] scroll capabilities but its input_id structure will stay the same. So many people said I have some wrongs here ;) it should be truth. I found our focus is howto or when send notification to userspace. Intuitional, to reload such device is rather ugly means, it should have one hotplug message for this case, and userspace handle it. If only look from design, I will agree with my argument, however, if also look from compatibility, I think I must agree your arguments. At last, you win! :D I am going to reload. PS: I found a behavior of usb subsystem, I can not sure whether it is normal. After I remove usbhid.ko, the uhci_hcd will reset device repeatly. usbcore: registered new driver usbhid /usr/src/redhat/BUILD/linux-2.6.18/drivers/usb/input/hid-core.c: v2.6:USB HID core driver usb 5-2: reset low speed USB device using uhci_hcd and address 3 usb 5-2: reset low speed USB device using uhci_hcd and address 3 usb 5-2: reset low speed USB device using uhci_hcd and address 3 usb 5-2: reset low speed USB device using uhci_hcd and address 3 usb 5-2: reset low speed USB device using uhci_hcd and address 3 Goodluck. -Liyu - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] Mitsumi USB FDD 061M: UNUSUAL_DEV multilun fix
On Sun, 8 Oct 2006, Matthew Dharm wrote: On Sun, Oct 08, 2006 at 12:14:17PM -0700, Pete Zaitcev wrote: On Sun, 8 Oct 2006 21:03:49 +0200, Tobias Lorenz [EMAIL PROTECTED] wrote: this fixes multiple lun detection on the new Mitsumi USB Floppy drive. This looks good, but whatever has happened to making all devices with UFI-protocol to report 1 LUN? I checked 2.6.18, and that code doesn't seem to be present. In the absense of it, the patch looks good (only in the future please make it with -p1 nesting, Tobias) I think the code to support UFI's mechanism for indicating LUN not present is pending merge right now. I believe I saw it go into Greg's tree. That's right. It's in 2.6.19-rc1. Merging changes like that one is a little tricky, since the SCSI core has to updated first (which it was for 2.6.18) and then usb-storage updated after. On the other hand, I see nothing wrong with changing the bcdDevice max value for the existing unusual_devs entry. Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb/hid: The HID Simple Driver Interface 0.3.2 (core)
Anssi Hannula wrote: One possibility is to do that with symbol_request() and friends. That would not be pretty though, imho. DVB subsystem uses that currently to load frontend modules dynamically, see dvb_attach() and dvb_frontend_detach() in drivers/media/dvb/dvb-core/dvbdev.h and drivers/media/dvb/dvb-core/dvb_frontend.c. This means also can load module dynamically. In apparently, I think it have two weaknesses: 1. It require module have one exported symbol at least. 2. We must handle life cycle of module by myself. Is it right? Goodluck -Liyu - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb/hid: The HID S imple Driver Interface 0.3.2 (core)
On Sunday 08 October 2006 14:51, Anssi Hannula wrote: (I didn't get Dmitry's original mail, so replying here) [EMAIL PROTECTED] wrote: Dmitry Torokhov wrote: Then there is issue with automatic loading of these sub-drivers. How do they get loaded? Or we force everything to be built-in making HID module very fat (like psmouse got pretty fat, but with HID prtential for it to get very fat is much bigger). The better way would be to split hid-input into a library module that parses hid usages and reports and is shared between device-specific modules that are real drivers (usb-drivers, not hid-sub-drivers). One possibility is to do that with symbol_request() and friends. That would not be pretty though, imho. DVB subsystem uses that currently to load frontend modules dynamically, see dvb_attach() and dvb_frontend_detach() in drivers/media/dvb/dvb-core/dvbdev.h and drivers/media/dvb/dvb-core/dvb_frontend.c. Unfortunately this does not quite work when hid is built-in and the rest are modules :( -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] Mitsumi USB FDD 061M: UNUSUAL_DEV multilun fix
Tobias Lorenz wrote: Hi, this fixes multiple lun detection on the new Mitsumi USB Floppy drive. I just understand, what the bcdDeviceMin, bcdDeviceMax parameters mean. It is of course easier to adjust the bcdDevice range of the already existing Mitsumi floppy record. Here is the patch (this time with -p1 :-). -p1 in the wrong place, unfortunately. The change itself is good - so if you want to re-submit the patch with the right diff'ing, that's fine, if not, I'll re-diff it and send it up stream in the next day or two if I don't hear from you. Thanks, -- Phil Dibowitz [EMAIL PROTECTED] Freeware and Technical Pages Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind. - Dr. Seuss signature.asc Description: OpenPGP digital signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ 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] Your Cowon iAudio M5 kernel patch
Jim, There's a kernel patch that came from a report you provided about the Cowon Systems iAudio M5. It seems that this may no longer be needed, and I was wondering if you could try the attached patch and tell me if your iAudio m5 still works. Thanks, -- Phil Dibowitz [EMAIL PROTECTED] Freeware and Technical Pages Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind. - Dr. Seuss This patch removes the unusual_devs entry for the iAudio M5 which no longer appears to be needed. Signed-off-by: Phil Dibowitz [EMAIL PROTECTED] --- linux-2.6.17-dev-phil/drivers/usb/storage/unusual_devs.h |7 --- 1 file changed, 7 deletions(-) diff -puN drivers/usb/storage/unusual_devs.h~unusual_rm_iaudiom5 drivers/usb/storage/unusual_devs.h --- linux-2.6.17-dev/drivers/usb/storage/unusual_devs.h~unusual_rm_iaudiom5 2006-08-23 21:04:53.0 -0700 +++ linux-2.6.17-dev-phil/drivers/usb/storage/unusual_devs.h 2006-08-23 21:05:10.0 -0700 @@ -1135,13 +1135,6 @@ UNUSUAL_DEV( 0x0dda, 0x0301, 0x0012, 0x US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_IGNORE_RESIDUE ), -/* Reported by Jim McCloskey [EMAIL PROTECTED] */ -UNUSUAL_DEV( 0x0e21, 0x0520, 0x0100, 0x0100, - Cowon Systems, - iAUDIO M5, - US_SC_DEVICE, US_PR_BULK, NULL, - 0 ), - /* Submitted by Antoine Mairesse [EMAIL PROTECTED] */ UNUSUAL_DEV( 0x0ed1, 0x6660, 0x0100, 0x0300, USB, _ signature.asc Description: OpenPGP digital signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ 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] This device (0e21, 0520, 0100 S 06 P 50) has an unneeded Protocol entry in unusual_devs.h
Phil Dibowitz wrote: Michael Gohdes wrote: usb-storage: This device (0e21,0520,0100 S 06 P 50) has an unneeded Protocol entry in unusual_devs.h Please send a copy of this message to linux-usb-devel@lists.sourceforge.net scsi3 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning Vendor: TOSHIBA Model: MK2006GAL Rev: BY30 Type: Direct-Access ANSI SCSI revision: 00 SCSI device sdb: 39063024 512-byte hdwr sectors (2 MB) Michael, Would you be willing to give this patch a shot? Alan, Matthew, anyone else who follows unusual_devs... Since Michael never responded, I dropped an email to Jim - the original submitter of the entry... if I can't get a response from him, I'll submit to the patch to Greg - it appears the entry isn't needed anymore, but I was hoping for a second confirmation. See the email I just CC'd linux-usb-devel for details. -- Phil Dibowitz [EMAIL PROTECTED] Freeware and Technical Pages Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind. - Dr. Seuss signature.asc Description: OpenPGP digital signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ 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] Mitsumi USB FDD 061M: UNUSUAL_DEV multilun fix
Hi, -p1 in the wrong place, unfortunately. The change itself is good - so if you want to re-submit the patch with the right diff'ing, that's fine, if not, I'll re-diff it and send it up stream in the next day or two if I don't hear from you. if I compare my patch to others, it seems that not the -p1 is the problem, but the position of the original file. What do you think about the following patch? Bye, Toby diff -ruN linux-2.6.18.orig/drivers/usb/storage/unusual_devs.h linux-2.6.18/drivers/usb/storage/unusual_devs.h --- linux-2.6.18.orig/drivers/usb/storage/unusual_devs.h2006-09-20 05:42:06.0 +0200 +++ linux-2.6.18/drivers/usb/storage/unusual_devs.h 2006-10-08 23:21:02.0 +0200 @@ -55,7 +55,8 @@ US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_IGNORE_RESIDUE), -UNUSUAL_DEV( 0x03ee, 0x6901, 0x, 0x0100, +/* modified by Tobias Lorenz [EMAIL PROTECTED] */ +UNUSUAL_DEV( 0x03ee, 0x6901, 0x, 0x0200, Mitsumi, USB FDD, US_SC_DEVICE, US_PR_DEVICE, NULL, - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] Mitsumi USB FDD 061M: UNUSUAL_DEV multilun fix
Tobias Lorenz wrote: Hi, -p1 in the wrong place, unfortunately. The change itself is good - so if you want to re-submit the patch with the right diff'ing, that's fine, if not, I'll re-diff it and send it up stream in the next day or two if I don't hear from you. if I compare my patch to others, it seems that not the -p1 is the problem, but the position of the original file. What do you think about the following patch? Yeah - that's why I said in the wrong place. That patch looks good. Thanks. -- Phil Dibowitz [EMAIL PROTECTED] Freeware and Technical Pages Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind. - Dr. Seuss signature.asc Description: OpenPGP digital signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ 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] Mitsumi USB FDD 061M: UNUSUAL_DEV multilun fix
Tobias Lorenz wrote: Hi, -p1 in the wrong place, unfortunately. The change itself is good - so if you want to re-submit the patch with the right diff'ing, that's fine, if not, I'll re-diff it and send it up stream in the next day or two if I don't hear from you. if I compare my patch to others, it seems that not the -p1 is the problem, but the position of the original file. What do you think about the following patch? Greg - Go ahead and apply this. Signed-off-by: Phil Dibowitz [EMAIL PROTECTED] diff -ruN linux-2.6.18.orig/drivers/usb/storage/unusual_devs.h linux-2.6.18/drivers/usb/storage/unusual_devs.h --- linux-2.6.18.orig/drivers/usb/storage/unusual_devs.h2006-09-20 05:42:06.0 +0200 +++ linux-2.6.18/drivers/usb/storage/unusual_devs.h 2006-10-08 23:21:02.0 +0200 @@ -55,7 +55,8 @@ US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_IGNORE_RESIDUE), -UNUSUAL_DEV( 0x03ee, 0x6901, 0x, 0x0100, +/* modified by Tobias Lorenz [EMAIL PROTECTED] */ +UNUSUAL_DEV( 0x03ee, 0x6901, 0x, 0x0200, Mitsumi, USB FDD, US_SC_DEVICE, US_PR_DEVICE, NULL, -- Phil Dibowitz [EMAIL PROTECTED] Freeware and Technical Pages Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind. - Dr. Seuss signature.asc Description: OpenPGP digital signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
