Am Mittwoch, 10. Januar 2007 23:35 schrieb Alan Stern:
> > Apparently here: drivers/base/core.c:
> >
> > void device_del(struct device * dev)
> > {
> > struct device * parent = dev->parent;
> > struct class_interface *class_intf;
> >
> > if (parent)
> > klist_del(&
Hello,
I am the project lead for the Stakker project which is a project on sf to
handle the Imation Disc Stakka project. Our handling of the hardware works
thanks to the excellent libusb sw and the skills of one of our programmers
(not me).
But it seems I have to do a 'rmmod usbhid' before o
Hi!
> > The obvious change with this device is that usb_set_configuration() is never
> > called, but that should not matter.
>
> No, I think you're barking up the wrong tree.
>
> Pavel, did you have CONFIG_USB_MULTITHREAD_PROBE turned on? I bet you did
> -- there's no other way to generate the
On Wed, 10 Jan 2007, Oliver Neukum wrote:
> Am Mittwoch, 10. Januar 2007 18:31 schrieb Alan Stern:
> > > Regarding the bug this device uncovers, it seems to me that this in
> > > drivers/base/core.c
> > > if (parent)
> > > klist_add_tail(&dev->knode_parent, &parent->klist_chil
On Tuesday 09 January 2007 3:52 am, Phil Endecott wrote:
> Gadgetfs had a mode in which endpoint descriptors were written by
> the user program before connection. This mode had some bugs, and
> may never have been used. This patch removes that mode. The only
> mode of operation now is for the
On Monday 08 January 2007 10:23 am, Vivek Dharmadhikari wrote:
> > The HCD doesn't touch that register after initialization, and
> > the only thing that's always _known_ to be in the async ring
> > is a QH that never holds transactions and is marked as the
> > queue head. Even an "empty" ring
Am Mittwoch, 10. Januar 2007 18:31 schrieb Alan Stern:
> > Regarding the bug this device uncovers, it seems to me that this in
> > drivers/base/core.c
> > if (parent)
> > klist_add_tail(&dev->knode_parent, &parent->klist_children);
> > should make knode_parent a valid node unde
On 1/10/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Wed, 10 Jan 2007, Jon Smirl wrote:
>
> > I just rebooted and all of the drivers loaded automatically but the
> > device didn't work.
> > Doing a usbreset of the device fixed everything.
> >
> > My best guess is that the "usb 2-1: usb auto-resum
On Wednesday 10 January 2007 7:33 am, Meher wrote:
> I am actually interested in the Davinci USB core but when I look at
> the drivers in drivers/usb/musb/ I have seen comments in the code like
> it is not implemented in the kernel HCD framework and it has to change
> some day. So I wanted to know
On Wed, 10 Jan 2007, Jon Smirl wrote:
> I just rebooted and all of the drivers loaded automatically but the
> device didn't work.
> Doing a usbreset of the device fixed everything.
>
> My best guess is that the "usb 2-1: usb auto-resume" failed to enable
> power to the device.
The dmesg log for
On Wed, 10 Jan 2007 10:25:54 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> I have an issue related to the new usbmon binary API.
> AFAIK the header added from the kernel to each event is in host byte
> order, except for the setup header part, which is in little endian byte
> order. All the rema
I just rebooted and all of the drivers loaded automatically but the
device didn't work.
Doing a usbreset of the device fixed everything.
My best guess is that the "usb 2-1: usb auto-resume" failed to enable
power to the device.
Note that the failure only happens when the device is plugged into a
On Wed, 10 Jan 2007, Oliver Neukum wrote:
> Am Mittwoch, 10. Januar 2007 17:14 schrieb Alan Stern:
> > On Wed, 10 Jan 2007, Oliver Neukum wrote:
> >
> > > Am Mittwoch, 10. Januar 2007 11:49 schrieb Pavel Machek:
> > > > usb 2-1: new full speed USB device using uhci_hcd and address 68
> > > > usb
Hi Patrik,
> I'm writing an USB Video Class Driver (UVC) to use the DaVinci EVM
> (1.10) as a video class device (camera). The UVC driver is based on the
> gadget zero skeleton (USB Gadget API for Linux).
> I have configured an isochronous in-endpoint with a payload size of 642
> byte [1]. The Vid
On 1/10/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> There is no way to prevent a USB device without a driver from being
> suspended. Perhaps we need one. On the other hand, USB devices _are_
> supposed to be able to suspend and resume with no ill effects -- it's part
> of the spec.
>
> I still wo
Am Mittwoch, 10. Januar 2007 17:14 schrieb Alan Stern:
> On Wed, 10 Jan 2007, Oliver Neukum wrote:
>
> > Am Mittwoch, 10. Januar 2007 11:49 schrieb Pavel Machek:
> > > usb 2-1: new full speed USB device using uhci_hcd and address 68
> > > usb 2-1: USB disconnect, address 68
> > > usb 2-1: unable t
Hi David,
Thanks a lot for your detailed answer!
David Brownell wrote:
> On Tuesday 09 January 2007 8:27 am, Patrik Nagel wrote:
>
>> Hi,
>>
>> I'm writing an USB Video Class Driver (UVC) to use the DaVinci EVM
>> (1.10) as a video class device (camera). The UVC driver is based on the
>> gad
On Wed, 10 Jan 2007, Oliver Neukum wrote:
> Am Mittwoch, 10. Januar 2007 11:49 schrieb Pavel Machek:
> > usb 2-1: new full speed USB device using uhci_hcd and address 68
> > usb 2-1: USB disconnect, address 68
> > usb 2-1: unable to read config index 0 descriptor/start
> > usb 2-1: chopping to 0 c
On Wed, 10 Jan 2007, xiaoxin liu wrote:
> > You can still keep the endpoint queue full, but the procedure isn't quite
> > as reliable. All you have to do is submit enough URBs in advance so that
> > the queue never gets empty, even given the normal overhead and latency of
> > running user program
On Tue, 9 Jan 2007, Florin Iucha wrote:
> I will try and bisect Saturday and Sunday morning.
>
> The Keyboard is a Kinesis Advantage USB. As reported earlier the USB
> IDs are:
>
> Bus 002 Device 003: ID 05f3:0007 PI Engineering, Inc. Kinesis Advantage
> PRO MPC/USB Keyboard
> Bus
Brief summary: After being suspended and resumed, Jon's USB sound device
remains in a useless powered-off state (the LEDs don't turn back on).
Clemens, if you have any ideas that might be relevant, please let us know.
On Tue, 9 Jan 2007, Jon Smirl wrote:
> Something has a refcount set into snd
Am Mittwoch, 10. Januar 2007 11:49 schrieb Pavel Machek:
> usb 2-1: new full speed USB device using uhci_hcd and address 68
> usb 2-1: USB disconnect, address 68
> usb 2-1: unable to read config index 0 descriptor/start
> usb 2-1: chopping to 0 config(s)
Does anybody know a legitimate reasons a de
On 1/9/07, David Brownell <[EMAIL PROTECTED]> wrote:
> On Tuesday 09 January 2007 2:41 pm, Meher wrote:
> > Hi,
> > I started going through the ohci-omap.c file and trying to make
> > sense of the interfaces. I am stuck at the point where the interrupt
> > handler is hooked with request_irq i
On Tue, 9 Jan 2007, Jon Smirl wrote:
> I tried to unbind/bind with the device in the not working state:
> snd-usb-audio 2-1:1.0: usb_probe_interface
> snd-usb-audio 2-1:1.0: usb_probe_interface - got id
> USB device is in the shutdown state, cannot create a card instance
> snd-usb-audio: probe of
hello,
I have an issue related to the new usbmon binary API.
AFAIK the header added from the kernel to each event is in host byte
order, except for the setup header part, which is in little endian byte
order. All the remaining data is little endian, too.
Shouldn't be reasonable to update the cod
25 matches
Mail list logo
