On Tue, 10 May 2005 07:07:13 -0700
David Brownell <[EMAIL PROTECTED]> wrote:
Hi David,
> Hmm, well nothing looks wrong at the OHCI level. It's possible that
> the data toggle got screwed up somehow; there are devices where the
> hardware doesn't reset it when it should. If that's the case, ther
On Wed, May 11, 2005 at 12:46:40PM +0530, [EMAIL PROTECTED] wrote:
>
> Hi Greg,
>
> I'm sending driver code and device info, so that you can get an idea of
> what is happening?
>
>
> Please find enclosed attachment of driver code and device info
Um, that is an old 2.4 version of the usb-serial
On Wed, 20 Apr 2005 11:28:39 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 20, 2005 at 08:26:29PM +0200, Oliver Neukum wrote:
> > /* shutdown our bulk reads and writes */
> > spin_lock_irqsave(&info->lock, flags);
> > list_for_each_safe(tmp, tmp2, &info->rx_urbs_submitted) {
>
Colin Leroy wrote:
I guess this zd1201_mac_reset() call is what "fixes" it.
One of the results of the mac reset is that the device reassociates with
the access point. You might just have lost your link with it and for
some reason automagic reassociation goes wrong or doesn't happen at all
From: Pete Zaitcev [mailto:[EMAIL PROTECTED]
> On Wed, 20 Apr 2005 11:28:39 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Wed, Apr 20, 2005 at 08:26:29PM +0200, Oliver Neukum wrote:
> > > /* shutdown our bulk reads and writes */
> > > spin_lock_irqsave(&info->lock, flags);
> > > list_for_
On Mer, 2005-05-11 at 14:34, Stuart MacDonald wrote:
> > > > This, from whiteheat.c, is wrong. Usb_kill_urb() with a spinlock
> > > > held is illegal.
>
> Curious, why is it illegal? **
It isn't. Its **invalid**. Illegal means prohibited by law
usb_kill_urb may end up recursively locking or sl
On Tuesday 10 May 2005 8:55 am, Alan Stern wrote:
> On Mon, 9 May 2005, David Brownell wrote:
> > > Won't it
> > > be enough to rely on the HCDs to reject submissions when they are unable
> > > to accept them? (Plus the fact that thanks to all the cleanups made in
> > > the last couple of years,
On Tuesday 10 May 2005 8:28 am, Alan Stern wrote:
> On Mon, 9 May 2005, David Brownell wrote:
> >
> > This patch does that conversion, and it also has the other tweak.
> > Worked for me ... you?
>
> Hmmm... There's a couple of problems with this. Not with the tweak; I
> won't have a chance to t
On Tuesday 10 May 2005 1:20 pm, Alan Stern wrote:
> On Mon, 9 May 2005, David Brownell wrote:
>
> ...
>
> Okay.
>
> > I've tested this only lightly since merging things from your patch,
> > and there are various "should not matter" things I removed from the
> > version I'd been working on, but t
Hi,
Our kernel can support usb disk very well. But
when my pc camera is attached, it can just run for a
while, then no interrupt will be triggered by the hc
following the uhci standard. In this case, the ACTIVE
bit of the td status has been cleared by the hc, and
the IOC bit equals to 1, the AC
On Wed, 11 May 2005, Marco Schramel wrote:
> Hi all,
>
> we use linux 2.4.25. Our device has 2 endpoint (bulk in/bulk out). I am
> writing a device driver which serves the bulk endpoints periodically.
> Exactly i start a timer. If this timer expires the timer service will send a
> write urb to
On Wed, 11 May 2005, Yi Liang wrote:
> Hi,
> Our kernel can support usb disk very well. But
> when my pc camera is attached, it can just run for a
> while, then no interrupt will be triggered by the hc
> following the uhci standard. In this case, the ACTIVE
> bit of the td status has been clea
On Wed, 11 May 2005, David Brownell wrote:
> > I haven't tried it out yet, but it looks good. One thing stuck out
> > though: Why did you remove the test that prevents new drivers from trying
> > to bind to suspended devices?
>
> It was superfluous; they'd get errors later, probe would still
> f
On Wednesday 11 May 2005 8:35 am, Alan Stern wrote:
> On Wed, 11 May 2005, David Brownell wrote:
>
> > > Also, I think that deadlock on dpm_sem in the PM core is now gone, so
> > > there shouldn't be any problem about unbinding drivers with no suspend
> > > method.
> >
> > I thought so too, b
On Wed, 11 May 2005, David Brownell wrote:
> > > Thing is there can be a window of around 10 msec there, unless this
> > > is the autosuspend case. During those 10 msec, something needs to
> > > prevent other code from using that device (e.g. on SMP). For now,
> > > that something is hcd->state.
Hello Marco,
On Wednesday 11 May 2005 08:35, Marco Schramel wrote:
> we use linux 2.4.25. Our device has 2 endpoint (bulk in/bulk out). I
> am writing a device driver which serves the bulk endpoints
> periodically. Exactly i start a timer. If this timer expires the
> timer service will send a writ
Hi ,
I tested the keyboard/mouse on linux-2.6.12-rc4. Still I have the same problem
. But this time it gives the message "input irq status -71 received".
But I could find out that if I use the usb boot protocol keyboard
driver, then the keyboard works fine. But since this dirver does not
support
Am Mittwoch, 11. Mai 2005 15:34 schrieb Stuart MacDonald:
> From: Pete Zaitcev [mailto:[EMAIL PROTECTED]
> > On Wed, 20 Apr 2005 11:28:39 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
> > > On Wed, Apr 20, 2005 at 08:26:29PM +0200, Oliver Neukum wrote:
> > > > /* shutdown our bulk reads and wr
A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I includ
--- Linux/drivers/usb/atm/speedtch.c.orig 2005-05-03 09:52:32.0 +0200
+++ Linux/drivers/usb/atm/speedtch.c 2005-05-11 17:04:38.0 +0200
@@ -5,6 +5,8 @@
* Copyright (C) 2003, Duncan Sands
* Copyright (C) 2004, David Woodhouse
*
+ * Based on "modem_run.c", copyright (C) 2001,
--- Linux/drivers/usb/atm/cxacru.c.orig 1970-01-01 01:00:00.0 +0100
+++ Linux/drivers/usb/atm/cxacru.c 2005-05-11 17:04:49.0 +0200
@@ -0,0 +1,878 @@
+/**
+ * cxacru.c - driver for USB ADSL modems based o
Otherwise known as Makefile and Kconfig updates.
--- Linux/drivers/usb/atm/Makefile.orig 2004-12-24 22:35:24.0 +0100
+++ Linux/drivers/usb/atm/Makefile 2005-05-11 17:04:24.0 +0200
@@ -1,7 +1,8 @@
#
-# Makefile for the rest of the USB drivers
-# (the ones that don't fit into any oth
--- Linux/drivers/usb/atm/xusbatm.c.orig 1970-01-01 01:00:00.0 +0100
+++ Linux/drivers/usb/atm/xusbatm.c 2005-05-11 17:04:52.0 +0200
@@ -0,0 +1,196 @@
+/**
+ * xusbatm.c - dumb usbatm-based driver for mode
Hi,
Is it possible to modify the usbkbd driver to support additional keys.
The problem I face is that my wireless RF keyboad/mouse dou gets
properly recognize with usbkbd driver but not with the usbhid driver.
The usbhid driver gives me error mesages. I posted the problem in this
mailing list ( Pr
On Wed, May 11, 2005 at 07:26:02PM +0200, Duncan Sands wrote:
> Hi Greg, the is the first of 5 patches that update the usbatm core and
> add two new drivers (for the Conexant AccessRunner chipset, and for
> generic USB DSL modems):
Hm, no Signed-off-by: lines :(
Also, can you put the patch descri
On Wed, 11 May 2005 13:29:15 +0900, Shiju Mathew <[EMAIL PROTECTED]> wrote:
> The usbhid driver gives me error mesages. I posted the problem in this
> mailing list ( Problem with duo USB keyboad/mouse - "input irq status
> -32 received") and also to the usb hid maintainer, but could not get
> much
Makefile and Kconfig entries for the new drivers.
Signed-off-by: Duncan Sands <[EMAIL PROTECTED]>
--- Linux/drivers/usb/atm/Makefile.orig 2004-12-24 22:35:24.0 +0100
+++ Linux/drivers/usb/atm/Makefile 2005-05-11 17:04:24.0 +0200
@@ -1,7 +1,8 @@
#
-# Makefile for the rest of the US
Doesn't do any firmware loading etc, just transmission and reception.
The user needs to take care of modem initialization, and load the
module with parameters giving the endpoints to use and so forth.
Signed-off-by: Duncan Sands <[EMAIL PROTECTED]>
--- Linux/drivers/usb/atm/xusbatm.c.orig 1970-01-
Driver for modems based on the Conexant AccessRunner chipset.
Original patch by Josep Comas, much reworked by Roman Kagan.
Signed-off-by: Duncan Sands <[EMAIL PROTECTED]>
--- Linux/drivers/usb/atm/cxacru.c.orig 1970-01-01 01:00:00.0 +0100
+++ Linux/drivers/usb/atm/cxacru.c 2005-05-11 17:04
Port the speedtch driver to the new usbatm core. The code is much
the same as before, just reorganized, though I threw in some minor
improvements (a new module parameter for choosing the altsetting,
more robust urb failure handling, ...) while I was there.
Signed-off-by: Duncan Sands <[EMAIL PROT
> Hm, no Signed-off-by: lines :(
>
> Also, can you put the patch descriptions in the individual emails? That
> way when they are applied it shows up properly.
Yeah, I'm out of practice. Let me try again...
D.
---
This SF.Net email is spons
On Wed, 11 May 2005, David Brownell wrote:
> > However the way you're using resume_root_hub doesn't
> > match what I had in mind when it was originally written.
>
> However it's what I had in mind when I agreed with you that such code
> would be useful, and it did pass the basic sysfs-induced te
Hi,
I've been testing around, and fund that my very own USB mouse (a
standard Packard Bell 5v 100mA, model IO-3UP)doesn't work when it's
expected or just doesn't work at all.
The problem is maybe the most strange thing I've ever seen. The device
is known to work (tested on other boxes, with diffe
Hi,
After some talk to gregkh, I've decided to send this message as it might
give some light regarding the breakage of the USB modules when usbcore
is built-in instead of compiled as module.
Modules that are breaking with CONFIG_USB=y :
- audio, bfusb, bcm203x, bpa10x, hci_usb, usblp, usb-midi,
On Wed, 11 May 2005, David Brownell wrote:
> > > There might be a way out though: adding a NOP shutdown method
> > > to the driver that usb_register() creates. (And maybe adding
> > > such an entry to struct usb_driver ... so the usbcore NOP method
> > > only gets used for drivers that don't pro
On Wed, May 11, 2005 at 09:10:46PM +0200, Lorenzo Hernandez Garcia-Hierro wrote:
> Hi,
>
> After some talk to gregkh, I've decided to send this message as it might
> give some light regarding the breakage of the USB modules when usbcore
> is built-in instead of compiled as module.
>
> Modules tha
On Wednesday 11 May 2005 11:57 am, Alan Stern wrote:
> On Wed, 11 May 2005, David Brownell wrote:
>
> > But ... if it doesn't work without USB_SUSPEND, then what would be
> > the point of such a routine?
>
> > See above ... I thought the whole point of that routine was to
> > help that resume-fro
On Wednesday 11 May 2005 12:10 pm, Lorenzo Hernandez Garcia-Hierro wrote:
>
> Modules that are breaking with CONFIG_USB=y :
>
> - audio, bfusb, bcm203x, bpa10x, hci_usb, usblp, usb-midi, cdc_acm,
>uhci-hcd, ohci-hcd, ehci-hcd, usb-storage...
>
> For those, the core API symbols that follow ar
> I'm sorry, but I don't see the specs for your device on how
> it works. Did you forget to attach them?
>
> thanks,
>
> greg k-h
Greg, I'm jumping in here with some information that I hope helps a bit. I
presently work with several different kernels (2.4.17, 2.4.19, 2.4.21 and a
recent 2.6 ke
On Wed, May 11, 2005 at 11:27:42PM +0200, Lorenzo Hernandez Garcia-Hierro wrote:
> El mi?, 11-05-2005 a las 13:12 -0700, Greg KH escribi?:
> > On Wed, May 11, 2005 at 09:10:46PM +0200, Lorenzo Hernandez Garcia-Hierro
> > wrote:
> > > Hi,
> > >
> > > After some talk to gregkh, I've decided to send
Hi,
I am trying to run the testusb.c
(http://www.linux-usb.org/usbtest/testusb.c) but the usbtest driver
not appear when I check with usbtree.
My procedure is,
1 compile the kernel with usb driver in built-in mode.
2 - # modprobe usbtest
3 - # lsmod usbtest – there is.
4 - # usbtree - and the
On Wed, 11 May 2005, David Brownell wrote:
> > > See above ... I thought the whole point of that routine was to
> > > help that resume-from-autosuspend case. At least I did when the
> > > idea originally came up ... in conjunction with the timer fixes,
> > > an autosuspended root hub could finall
> I looked into the possibility of having the PCI core disable interrupt
> generation and DMA on each new device as it is discovered. Unfortunately
> there is no dependable, universal way to do this for IRQs. (A notable gap
> in the original PCI specification, IMHO.)
PCI specification 2.3 onwa
On Wed, 11 May 2005, Vivek Goyal wrote:
> > I looked into the possibility of having the PCI core disable interrupt
> > generation and DMA on each new device as it is discovered. Unfortunately
> > there is no dependable, universal way to do this for IRQs. (A notable gap
> > in the original PCI sp
44 matches
Mail list logo
