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
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
+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)
+ {
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.
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
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
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
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
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.
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
(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
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:
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
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
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
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
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.
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
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
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
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
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?
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
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
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
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.
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 :-).
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 @@
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
+++
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
53 matches
Mail list logo
