t is
> adapted from a patch by Oliver Neukum. Autosuspend is allowed except
> during LUN scanning, resets, and command execution.
>
>
> my USB photo-camera gets automagically disconnected before I can do
> anything with it ;)
>
hi,
I need vendor:product. Please pro
Am Dienstag 14 August 2007 schrieb bizu:
> $> lsusb -v
> Bus 001 Device 002: ID 0bb4:0303 High Tech Computer Corp.
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 224 Wireless
> bDeviceSubClass 1 Radio Fre
Am Sonntag 05 August 2007 schrieb Tino Keitel:
> I tried again -rc1 without USB_DEBUG, and was able to reproduce the
> bug 2 times. At the second time, the kernel log shows this:
Hi Tino,
could you please test an _earlier_ kernel. We need to know which kernel
introduced this bug.
Regard
Am Montag 13 August 2007 schrieb Alan Cox:
> On Mon, 13 Aug 2007 15:48:40 +0200
> Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > Am Montag 13 August 2007 schrieb Alan Cox:
> > > +static int iuu_alloc_buf(struct iuu_private *priv)
> > > > +{
> >
Am Montag 13 August 2007 schrieb Alan Cox:
> +static int iuu_alloc_buf(struct iuu_private *priv)
> > +{
> > + priv->buf = kzalloc(256, GFP_KERNEL);
> > + priv->dbgbuf = kzalloc(256, GFP_KERNEL);
> > + priv->writebuf = kzalloc(256, GFP_KERNEL);
> > + if (!priv->buf || !priv->dbgbuf || !priv
Am Sonntag 12 August 2007 schrieb [EMAIL PROTECTED]:
> In this release, the driver use the interrupt context.
> So no more latency problem.
> I still kfree the buffers provided by the usb-serial framework.
>
> All comments/remarks are welcome
>
> This driver seems very stable ( tested with 5 read
Am Samstag 11 August 2007 schrieb Paulo da Silva:
> I would like to ask a question. Sorry if this is a silly question but I
> don't know kernel internals and what kind of info 't' produces.
It produces a trace of all tasks in the system.
> Is it safe to post that output here, considering this is
Am Sonntag 12 August 2007 schrieb Alan Stern:
> On Sun, 12 Aug 2007, Oliver Neukum wrote:
>
> > Am Donnerstag 09 August 2007 schrieb Alan Stern:
> > > Oliver and Pete:
> > >
> > > Is it possible to replace all those USB_QUIRK_NO_AUTOSUSPEND entries
>
Am Donnerstag 09 August 2007 schrieb Alan Stern:
> Oliver and Pete:
>
> Is it possible to replace all those USB_QUIRK_NO_AUTOSUSPEND entries
> for scanners with a single class-wide entry?
Which class? It would have to blanket all vendor specific devices.
This is a rather broad swipe.
> What abou
Am Freitag 03 August 2007 schrieb Matthew Garrett:
> > Which is why I didn't suggest doing that, of course. The only
> > one making that kind of straw man argument seems to be you.
>
> But however you phrase it, that's effectively what it is. "Does your
> device work?" just makes users wonder wh
Am Freitag 03 August 2007 schrieb Dave Jones:
> On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote:
>
> > Kernel developers are a diverser lot than you think ;-)
> > We don't enable autosuspend in drivers we can't test, except where
> > the lack o
Am Freitag 03 August 2007 schrieb Matthew Garrett:
> On Thu, Aug 02, 2007 at 11:01:08PM -0700, David Brownell wrote:
>
> > Seems to me it ought to be practical to organize a database that can
> > be consulted by an outcall from udev, disabling autosuspend on devices
> > which are known to be broke
Am Freitag 03 August 2007 schrieb gutian abei:
> Dear All:
> I am trying to develop a USB device driver in Linux platform.
> Our device has the ability of re-enumeration. That is when our device plug
> into host PC it reports a vid/pid, for example 0x/0x, after 10
> seconds it changes
Am Freitag 03 August 2007 schrieb Greg KH:
> On Mon, Jul 30, 2007 at 11:11:54AM -0700, David Brownell wrote:
> > On Monday 30 July 2007, Oliver Neukum wrote:
> > >
> > > > But -- never actually having had both a highspeed USB sniffer *AND*
> > > > ha
Am Freitag 03 August 2007 schrieb Matthew Garrett:
> > Also, we have udev rules for SANE that disables their autosuspend
> > settings, which handles the majority of the devices we have seen with
> > problems.
>
> Several printers seem to have the issue as well, and the blacklist seems
> to contai
Am Freitag 03 August 2007 schrieb David Brownell:
> On Wednesday 01 August 2007, Oliver Neukum wrote:
> > Am Dienstag 31 Juli 2007 schrieb Alan Stern:
> > > You assign dev->intf in both the usbnet framework driver and the
> > > subdriver. Could the subdriver's a
ve the attributes from the wrong interface. The
> left-over attributes can cause a crash later on, particularly if the driver
> module has been unloaded.
>
> Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
Acked-
Am Donnerstag 02 August 2007 schrieb Alan Stern:
> On Wed, 1 Aug 2007, Alan Stern wrote:
>
> > Okay, good work. Thanks to your careful experiments, plus the hints
> > from Oliver and Tejun, I figured out the problem. In short, the
> > attribute files were registered on the control interface but
Am Donnerstag 02 August 2007 schrieb Thaens Tim:
> I've compiled the usb_skeleton.c module and loaded this module.
> I've managed to open a USB-device, but that's it.
>
> How can I write a application that uses this module?
> Can I only use the file-operations like (owner, read, write, open and
>
Am Dienstag 31 Juli 2007 schrieb Alan Stern:
> You assign dev->intf in both the usbnet framework driver and the
> subdriver. Could the subdriver's assignment be removed?
Here we go again.
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
Am Dienstag 31 Juli 2007 schrieb Alan Stern:
> > > For whatever it's worth.I should point out that this problem
> > > only occurs when using the USB Abstract Control Model driver
> > > for USB modems (i.e. the cdc_acm module). When using my
> > > USB scanner or USB printer I can unload the uhci-hc
Am Dienstag 31 Juli 2007 schrieb Alan Stern:
> You assign dev->intf in both the usbnet framework driver and the
> subdriver. Could the subdriver's assignment be removed?
Yes, it is superfluous. I'll make a new patch.
Regards
Oliver
--
Am Dienstag 31 Juli 2007 schrieb A. Kalten:
> On Tue, 31 Jul 2007 13:00:38 -0400
> "A. Kalten" <[EMAIL PROTECTED]> wrote:
> >
> > But after compiling 2.6.23-rc1 and undergoing the same steps
> > with the usb modem as before, the problem remains. The only
> > difference is that the command "rmmod
Hi,
this implements autosuspend support for the asix subdriver of usbnet.
It works by autoresume when the device is opened and autosuspending when
it is closed. The logic is all put into the generic framework. All
the subdriver has to do is setting the flag.
To support this the suspend() method i
Am Dienstag 31 Juli 2007 schrieb Greg KH:
> > So I agree with the proposition of Oliver to add a buffer_size in the
> > usb_serial_driver structure.
> > This is very useful to prepare a buffer able to make bulk transfer.
>
> I don't think it is necessary to add as it has not been a problem yet
> f
Am Montag 30 Juli 2007 schrieb Paulo da Silva:
> Oliver Neukum escreveu:
> > ...
>
> > Please get a stack trace with the t variety of the alt-sysrq you use to
> > reboot
> > and post that.
> >
> >
>
>
> I read the sysrq.txt and saw that
Am Montag 30 Juli 2007 schrieb [EMAIL PROTECTED]:
> This is quite dangerous :-)
>
> You can't apply a user requested buffer_size to interrupt_buffer !
>
> The API should only apply the buffer size to bulk buffers...
Right you are. What about this? Or do you need split sizes
for input and output?
Am Samstag 28 Juli 2007 schrieb David Brownell:
> On Friday 27 July 2007, Alan Stern wrote:
> > In my experience this sort of thing tends to be caused by low-level
> > hardware communications errors. Noise in the USB data lines or a
> > missing handshake packet, stuff like that. Not much extra d
Am Montag 30 Juli 2007 schrieb [EMAIL PROTECTED]:
> Hi Greg,
>
> After a new complete reading of my code against usb-serial.c, I finally
> found ( I hope ) my problem.
> In usb-serial.c, when bulk_in/out buffers are initialized, each buffer size
> are the same as the wMaxPacketSize given by the e
Hi,
another quirky scanner.
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
---
--- a/drivers/usb/core/quirks.c 2007-07-30 12:04:44.0 +0200
+++ b/drivers/usb/core/quirks.c 2007-07-30 12:05:21.0 +0200
@@ -52,6 +52,8 @@ static const
Am Montag 30 Juli 2007 schrieb Paulo da Silva:
> With legacy driver rt2570 the keyboard also freezes! I can't even get a
> console (ctrl+alt+f1).
> Using ndiswrapper only the USB or part of it breaks.
> I tried, what I think - I had no feedback - ctrl+alt+prt sc+{s,u,s,b}
> and got a reboot. Unfort
Am Sonntag 29 Juli 2007 schrieb [EMAIL PROTECTED]:
> I have the same problem in my development..
>
> Somewhere in my code:
>
> unsigned char *data = urb->transfer_buffer ;
>
> if ( data == NULL )
> dbg("%s - data is NULL !!!",__FUNCTION__ );
>
>
Am Sonntag 29 Juli 2007 schrieb Jesper Juhl:
> On 29/07/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > On 7/29/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> > > Hello,
> > >
> > > This patch makes sure we don't dereference a NULL pointer in
> > > drivers/net/usb/pegasus.c::write_bulk_c
Hi,
stressing a flash disk I rapidly get this error:
Jul 27 12:35:00 oenone kernel: usb-storage: *** thread awakened.
Jul 27 12:35:00 oenone kernel: usb-storage: Command READ_10 (10 bytes)
Jul 27 12:35:00 oenone kernel: usb-storage: 28 00 00 00 25 f8 00 00 3c 00
Jul 27 12:35:00 oenone kernel: us
Am Donnerstag 26 Juli 2007 schrieb Greg KH:
> Alan and Oliver, was this caused by the autosuspend changes for
> usb-storage?
The oops itself looks like refcounting. What caused the initial io error
does not become clear from the log. It is possible that the device cannot
stand suspension. But ther
Am Mittwoch 25 Juli 2007 schrieb Tino Keitel:
> On Wed, Jul 25, 2007 at 10:24:36 +0200, Oliver Neukum wrote:
> > Am Mittwoch 25 Juli 2007 schrieb Tino Keitel:
> > > Hi,
> > >
> > > I just tried 2.6.23-rc1 and shortly after the boot my e
Am Mittwoch 25 Juli 2007 schrieb Tino Keitel:
> Hi,
>
> I just tried 2.6.23-rc1 and shortly after the boot my external USB hard
> disk went mad.
>
> I all started with these kernel messages:
>
> kern.info: usb 1-6: USB disconnect, address 5
> kern.info: sd 4:0:0:0: [sdb] Result: hostbyte=0x07 dr
Am Dienstag 24 Juli 2007 schrieb Andrew Morton:
> guys, there have been updates to this bug via the bugzilla UI,
> at http://bugzilla.kernel.org/show_bug.cgi?id=8104
>
Hi,
we need to know the oldest kernel that does not work.
Please try 2.6.18 and 2.6.19
Regards
Oliver
> Clearly there's a bug in
> drivers/usb/serial/usb-serial.c:usb_serial_put(). It shouldn't call
> kref_put() while holding a spinlock.
As I was reminded, I polluted the namespace. Here's a better
version. Does it fix your problem?
Regards
Oliv
Am Dienstag 24 Juli 2007 schrieb Ron Gage:
> Anyhow, the device appears to require a non-standard function code in
> the URB header, code 0019. SnoopyPro (yeah, on Windows) says this
> function code is "Vendor Endpoint". Obviously, there isn't any current
> way to send such a function code wit
> Clearly there's a bug in
> drivers/usb/serial/usb-serial.c:usb_serial_put(). It shouldn't call
> kref_put() while holding a spinlock.
Yes, these functions need to sleep.
Does this work?
Regards
Oliver
---
--- a/drivers/usb/serial/usb-serial.c 2007-07-23 08:47:35.0
he code it also doesn't seem to have been intended to always
> return 0.
Coverity is right. The check for NULL is wrongly done and the error
return is lost.
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
--
--- a/drivers/usb/serial/usb-s
Hi,
> +struct ks959_speedparams {
> + __le32 baudrate;/* baud rate, little endian */
> + unsigned int data_bits : 2; /* data bits - 5 (5..8) */
> + unsigned int : 1;
> + unsigned int stop_bits : 1;
> + unsigned int parity_enable : 1;
> + unsigned int par
The number of quirky devices seems to be large.
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
--
--- a/drivers/usb/core/quirks.c 2007-07-20 10:30:06.0 +0200
+++ b/drivers/usb/core/quirks.c 2007-07-20 11:29:55.0 +0200
@@ -30,10
Am Donnerstag 19 Juli 2007 schrieb Alain Degreffe:
> I have a newbie question :-)
>
> I would like to have to threads: 1 reading process and one writing
> process...
>
> For the moment as soon I write to device, I begin to read the answer but it
> is not very efficient because the iso7816 don't g
Am Donnerstag 19 Juli 2007 schrieb Jeremy Katz:
> On Thu, 2007-07-19 at 15:45 +0200, Oliver Neukum wrote:
> > Am Donnerstag 19 Juli 2007 schrieb Jeremy Katz:
> > > +/* Jeremy Katz <[EMAIL PROTECTED]>:
> > > + * The Blackberry Pearl can run in two modes; a usb-stora
Am Donnerstag 19 Juli 2007 schrieb Jeremy Katz:
> +/* Jeremy Katz <[EMAIL PROTECTED]>:
> + * The Blackberry Pearl can run in two modes; a usb-storage only mode
> + * and a mode that allows access via mass storage and to its database.
> + * The berry_charge module will set the device to dual mode an
Hi,
it seems to me that some drivers, in particular usbfs & cdc-acm
are unable to implement reset_resume() because they don't know
the device state. So what would be the correct response if the
system is put to sleep while any of these drivers is bound to a device
that has the RESET_RESUME quirk?
Am Donnerstag 19 Juli 2007 schrieb [EMAIL PROTECTED]:
> OOps ;-)
>
> 2 missing characters...
>
> Now it compile without warning or error
>
+ /* shutdown our urbs */
+ dbg("%s - shutting down urbs", __FUNCTION__);
+ result = usb_unlink_urb(port->write_ur
Hi,
our list of devices which cannot be suspended keeps growing.
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
--
--- greg26/drivers/usb/core/quirks.c~ 2007-07-19 08:55:26.0 +0200
+++ greg26/drivers/usb/core/quirks.c2007-07-19
Am Mittwoch 18 Juli 2007 schrieb Alain Degreffe:
+static int iuu_tiocmget(struct usb_serial_port *port, struct file *file)
+{
+ u8 *st;
+ int status ;
+ st = kmalloc(sizeof(u8), GFP_KERNEL);
+ if (!st)
+ return -ENOMEM ;
+ iuu_status(port, st);
+
+
Am Mittwoch 18 Juli 2007 schrieb eczema:
> + if ((set == 0) && priv->TIOSTATUS == TIOCM_RTS) {
> + dbg("%s TIOCMSET RESET called !!!", __FUNCTION__);
> + priv->TIOSTATUS = 0;
> + if (iuu_reset(port, 0x0C))
> + return -EIO;
> +
Am Mittwoch 18 Juli 2007 schrieb eczema:
> +struct iuu_buffers {
> + u8 buf[256];
> + u8 finalbuf[256];
> + u8 dbgbuf[512];
> + u8 len;
> +};
> +
Is that safe? Kmalloc will give out chunks of memory safe for DMA, but will
they be aligned?
Regards
Ol
Am Mittwoch 18 Juli 2007 schrieb Alan Stern:
> On Wed, 18 Jul 2007, Oliver Neukum wrote:
>
> > > Am Mittwoch 18 Juli 2007 schrieb Alan Stern:
> > > int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
> > > {
> > > - int pipe,
Am Mittwoch 18 Juli 2007 schrieb Alan Stern:
> int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
> {
> - int pipe, temp, max;
> - struct usb_device *dev;
> - int is_out;
> + int xfertype, max;
> +
Am Freitag 13 Juli 2007 schrieb Andrew Morton:
> > T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 7 Spd=12 MxCh= 0
> > D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
> > P: Vendor=12d1 ProdID=1003 Rev= 0.00
> > S: Manufacturer=HUAWEI Technologies
> > S: Product=HUAWEI Mobile
> >
Am Freitag 13 Juli 2007 schrieb Kevin Lloyd:
> +int sierra_probe(struct usb_interface *iface, const struct usb_device_id *id)
> +{
> + int result;
> + struct usb_device *udev;
> +
> + udev = usb_get_dev(interface_to_usbdev(iface));
> +
> + /* Check if in installer mode
Am Donnerstag, 12. Juli 2007 schrieb Marcel Meerstetter:
> Hello all,
>
> i need help with the USB HID driver. I am running kernel version 2.6.12.
> When I attach a USB keyboard, it is recognized
>
> # usb 1-1: new low speed USB device using s3c2410-ohci and address 2
> usb 1-1: Product: HP B
Am Donnerstag, 12. Juli 2007 schrieb Kevin Lloyd:
> From: Kevin Lloyd <[EMAIL PROTECTED]>
>
> This patch adds compatibility with Sierra Wireless' new TRU-Install feature.
> Future devices that use this feature will not work unless this patch has been
> applied.
Is this some type of CD-ROM simul
Am Mittwoch, 11. Juli 2007 schrieb Alan Stern:
> On Wed, 11 Jul 2007, Jiri Kosina wrote:
>
> > On Wed, 11 Jul 2007, Oliver Neukum wrote:
> >
> > > autosuspend for USB HID devices remains problematic as far as mice and
> > > keyboards are concerned. While I am
Am Mittwoch, 11. Juli 2007 schrieb Alan Stern:
> On Wed, 11 Jul 2007, Oliver Neukum wrote:
>
> > Hi,
> >
> > this implements autosuspend for cdc-acm devices.
>
> Do you mean it adds support for plain old suspend/resume? It
> definitely does not implement autos
Am Mittwoch, 11. Juli 2007 schrieb jidong xiao:
> On 7/11/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > Am Mittwoch, 11. Juli 2007 schrieb jidong xiao:
> > > I see there are two routines, usb_unlink_urb and usb_kill_urb,the
> > > latter one should be used for sy
Am Mittwoch, 11. Juli 2007 schrieb jidong xiao:
> I see there are two routines, usb_unlink_urb and usb_kill_urb,the
> latter one should be used for sync unlinking,this means it can go to
> sleep,it won't return until the completion handler have finished.And
> the former one could not go to sleep.Bu
Hi,
this implements autosuspend for cdc-acm devices.
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
--
--- a/drivers/usb/class/cdc-acm.c 2007-06-11 13:27:17.0 +0200
+++ b/drivers/usb/class/cdc-acm.c 2007-05-30 20:56:00.000
Am Mittwoch, 11. Juli 2007 schrieb Alain Degreffe:
> Mmmh, I don't think so because ,because in the debug, after the insmod, if I
> open the device, the debug is normal. The problem seems to be the flip buffer
> that don't work well.The flush function don't give any char to the userland...
Do yo
Am Mittwoch, 11. Juli 2007 schrieb Alain Degreffe:
> sequence, all is running well. I join the (hugly ?) code for a review. I'm a
1. you violate the kernel coding style (look into the Documentation directory)
2. you should use a .h file for your defines
3.:
static int
iuu_startup (struct usb_ser
Am Mittwoch, 11. Juli 2007 schrieb Alain Degreffe:
> Hi, I try to make a new driver for infinity unlimited usb. I use the
> usbserial layer to manage the lowlevel functions like probing or ttyUSBx
> creation/selection.
> The driver works but only after a first sequence "open and close" of the
> dev
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
--- a/drivers/hid/usbhid/hid-core.c 2007-07-11 10:02:44.0 +0200
+++ b/drivers/hid/usbhid/hid-core.c 2007-07-11 10:02:54.0 +0200
@@ -506,7 +506,16 @@ static int hid_get_class_descriptor(stru
Hi,
this adds some scanners reported to be crashed by autosuspend to
the quirk list.
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
--
--- a/drivers/usb/core/quirks.c 2007-07-10 12:55:56.0 +0200
+++ b/drivers/usb/core/quirks.c 2007-07-10
Am Montag, 9. Juli 2007 schrieb Alan Stern:
> On Mon, 9 Jul 2007, Oliver Neukum wrote:
>
> > Am Freitag, 6. Juli 2007 schrieb Alan Stern:
> > > This patch (as929) adds usb_autopm_get_interface_burst() to the
> > > autosuspend programming interface. It is intended
Am Freitag, 6. Juli 2007 schrieb Alan Stern:
> @@ -1028,6 +1039,7 @@ static int storage_probe(struct usb_inte
> * start it up. */
> scsi_host_get(us_to_host(us));
> atomic_inc(&total_threads);
> + usb_autopm_get_interface(intf); /* dropped in the scanning thread */
>
Am Freitag, 6. Juli 2007 schrieb Alan Stern:
> This patch (as929) adds usb_autopm_get_interface_burst() to the
> autosuspend programming interface. It is intended for situations
> where I/O events occur in bursts of activity; it reduces overhead by
> not cancelling the device's autosuspend timer.
Am Samstag, 7. Juli 2007 schrieb Alan Stern:
> > This brings me to an idea.
> > Is it possible to accept the next scsi request while the current request is
> > being executed? That way, when the first request finishes, the URBs
> > could be retained if they are needed right away and otherwise freed
Am Samstag, 7. Juli 2007 schrieb Alan Stern:
> On Sat, 7 Jul 2007, Oliver Neukum wrote:
>
> > > That's a real problem. During initial enumeration the usb_device
> > > hasn't been registered yet, so the ep_device hasn't been created.
> > >
>
Am Samstag, 7. Juli 2007 schrieb David Brownell:
> On Saturday 07 July 2007, Alan Stern wrote:
> > On Fri, 6 Jul 2007, David Brownell wrote:
> >
> > > > The total number of interrupts would depend on the HCD. Right now OHCI
> > > > is probably the worst case.
> > >
> > > Worst??? No, I'd say it
Am Freitag, 6. Juli 2007 schrieb Alan Stern:
> On Fri, 6 Jul 2007, Oliver Neukum wrote:
>
> > Hi,
> >
> > I tried switching our allocation APIs to:
> >
> > struct urb *usb_alloc_urb(struct usb_host_endpoint *ep, size_t
> > alloc_length, gfp_t mem
Hi,
I tried switching our allocation APIs to:
struct urb *usb_alloc_urb(struct usb_host_endpoint *ep, size_t alloc_length,
gfp_t mem_flags);
struct urb *usb_alloc_iso_urb(struct usb_host_endpoint *ep, unsigned int
iso_packets, gfp_t mem_flags);
Unfortunately during initialisation ep->ep_dev tu
Am Donnerstag, 5. Juli 2007 schrieb Matthew Dharm:
> On Mon, Jul 02, 2007 at 09:15:03AM +0200, Oliver Neukum wrote:
> > Am Montag, 2. Juli 2007 schrieb Alan Stern:
> > > If you look at usbmon logs of real usb-storage data transfers you'll
> > > see that mu
Am Mittwoch, 4. Juli 2007 schrieb Alan Stern:
> On Wed, 4 Jul 2007, Oliver Neukum wrote:
>
> > Hi,
> >
> > as requested, here's a patch that moves the iso frames into
> > their own allocation. That's a prerequisite to most modifications
> > of the A
USB: add new device id to option driver
device is Samsung X180 China cellphone
Signed-off-by: Andrey Arapov <[EMAIL PROTECTED]>
Acked-by: Oliver Neukum <[EMAIL PROTECTED]>
--- linux-2.6.21.i686.orig/drivers/usb/class/cdc-acm.c 2007-04-26 14:08:32.0 +1100
+++ linux-2.6.21.i686
Hi,
as you proposed that the APIs of host and gadget be made more similar,
I've got questions on the gadget API.
struct usb_request *(*alloc_request) (struct usb_ep *ep,
gfp_t gfp_flags);
void (*free_request) (struct usb_ep *ep, struct usb_request *req);
Why is ep
Am Dienstag, 3. Juli 2007 schrieb S.Çağlar Onur:
> Hmm i have NIKON D50 also and it works here without a problem with Linus's
> current git.
Please provide the full lsusb -v for your devices, both of you.
You might have different versions of the device.
Regards
Oliver
-
Am Dienstag, 3. Juli 2007 schrieb Jiri Kosina:
> OK, it seems that vendors of usb keyboards probably rely too much on fact
> that the keyboards could be quite slow and flaky without anyone
> complaining under normal load, and therefore implement the things very
> badly. Oliver, I currently think
Am Dienstag, 3. Juli 2007 schrieb Greg KH:
> > > Ok, so two drivers might need this, but not the whole usb core, right?
> >
> > If those two drivers need the extended allocator, why not use it where
> > it is beneficial, even if the benefit is small?
>
> What is the benefit? Speed isn't an issue
> It's more likely a usb-storage or scsi layer problem.
>
> The device reports as having 1984001 sectors and the kernel is reporting IO
> errors around the very end of the device. Presumably an IO is straddling
> end-of-device and we're not handling that correctly.
Can you try the work around s
Am Dienstag, 3. Juli 2007 schrieb Greg KH:
> On Mon, Jul 02, 2007 at 10:33:12PM -0700, Yinghai Lu wrote:
> > On 7/2/07, Greg KH <[EMAIL PROTECTED]> wrote:
> > > On Mon, Jul 02, 2007 at 03:36:37PM -0700, Yinghai Lu wrote:
> > > > [PATCH 3/4] usb: allocated usb releated dma buffer with kmalloc_node
Am Montag, 2. Juli 2007 schrieb Ondrej Zary:
> + * IRTOUCH Part
> + */
> +#ifdef CONFIG_TOUCHSCREEN_USB_IRTOUCH
> +static int irtouch_read_data(struct usbtouch_usb *dev, unsigned char *pkt)
> +{
> + dev->x = (pkt[3] << 8) | pkt[2];
> + dev->y = (pkt[5] << 8) | pkt[4];
> + dev->tou
Am Dienstag, 3. Juli 2007 schrieb Andrew Morton:
> > Some time ago(I really can't remember version of the kernel)
> > everything was Ok. I'll try to find out the workable version of the
> > kernel ... but I've already tried 2.6.20 - the same =(.
> > I'm not sure, but It's possible that I've had ATA
Am Montag, 2. Juli 2007 schrieb Alan Stern:
> On Mon, 2 Jul 2007, Oliver Neukum wrote:
>
> > > The number of interrupts is orthogonal to the question of whether HCD
> > > resources are bound to endpoints or to URBs.
> >
> > But if resources are bound to
Am Montag, 2. Juli 2007 schrieb Alan Stern:
> On Mon, 2 Jul 2007, Oliver Neukum wrote:
>
> > > I don't think so. For one thing, we'd be allocating fewer URBs. For
> > > another, the total number of submissions would be the same; they would
> > > j
Am Montag, 2. Juli 2007 schrieb Alan Stern:
> On Mon, 2 Jul 2007, Oliver Neukum wrote:
>
> > > Furthermore, if you do things this way then you could share an
> > > endpoint's resources among a bunch of URBs. For example, suppose you
> > > stream data to
Am Montag, 2. Juli 2007 schrieb David Brownell:
> On Monday 02 July 2007, Oliver Neukum wrote:
>
> > And please explain why we can operate efficiently with kmalloced
> > memory although we don't evaluate the controller's dma mask.
>
> In what way does that re
Am Montag, 2. Juli 2007 schrieb Alan Stern:
> On Mon, 2 Jul 2007, Oliver Neukum wrote:
>
> > Am Montag, 2. Juli 2007 schrieb Alan Stern:
> > > > As noted above, for full speed devices we could get similar throughput
> > > > with slightly more clever impleme
Am Montag, 2. Juli 2007 schrieb Alan Stern:
> On Mon, 2 Jul 2007, Oliver Neukum wrote:
>
> > Am Montag, 2. Juli 2007 schrieb Alan Stern:
> > > On Sun, 1 Jul 2007, Oliver Neukum wrote:
> >
> > > > It happens when the URB is destroyed.
> > >
Am Montag, 2. Juli 2007 schrieb Andrew Morton:
> On Sun, 1 Jul 2007 13:50:23 -0700 (PDT) [EMAIL PROTECTED] wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=8698
> >
> >Summary: linux kernel usb-serial problem
> >Product: Other
> >Version: 2.5
> > K
Am Montag, 2. Juli 2007 schrieb Alan Stern:
> > As noted above, for full speed devices we could get similar throughput
> > with slightly more clever implementation of scatterlist handling. If
> > the HCD has good hardware support for queueing, and the system has fair
> > IRQ latency, recycling as
Am Montag, 2. Juli 2007 schrieb Hans Petter Selasky:
> Hi Oliver!
>
> What you're trying to do is what the HPS USB stack for FreeBSD has been doing
> for a while. See for example:
>
> http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/ohci.c
>
> Look at the function:
>
> static
Hi,
this one fixes an oops with quirky ftdi_sio devices. As it fixes a
regression, I propose that it be included in 2.6.22
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
---
--- linux-2.6.22-rc3/drivers/usb/serial/ftdi_sio.c.alt 2007-06-04
Am Montag, 2. Juli 2007 schrieb David Brownell:
> On Saturday 30 June 2007, Oliver Neukum wrote:
>
> > So do we have consensus for this prototype:
> >
> > struct urb *usb_alloc_urb(struct usb_host_endpoint *ep,
> > unsigned int max_l
Am Montag, 2. Juli 2007 schrieb David Brownell:
> > Since each sg element refers to a page or more of data,
> > the maximum number of elements is restricted by the maximum allowed
> > transfer size (which is currently 512 KB or 128 pages on i386). The
> > default max transfer size set by usb-stor
1 - 100 of 2968 matches
Mail list logo
