Am Dienstag, 8. November 2005 01:56 schrieb Herbert Xu:
> Hi:
>
> The kaweth driver does not delete the TX URB in kaweth_close().
> As a result the TX URB may still be active in the USB subsystem.
> If kaweth_open() is called quickly afterwards, the networking
> layer could submit another packet b
usbcore should probably do the same thing.
This modifies the HCD builds to automatically "-DDEBUG" if CONFIG_USB_DEBUG
is selected. It's just a minor source code cleanup, guaranteeing consistency.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: g26/drivers/usb/host/Makefile
This is a workaround for a PM bug with the onetouch support;
something needs to kill that input urb.
- Dvae
The onetouch support doesn't suspend correctly (leaves an interrupt
URB posted, instead of unlinking it) so for now just disable it
when PM is in the air.
Signed-off-by: David Brownell <[EM
Masanari Iida <[EMAIL PROTECTED]> wrote:
>
> Hello,
> I updated my system's kernel from 2.6.13.2 to 2.6.14,
> then it oops when I connect my Digital Camera via USB connection
> as USB storage device.
> I went back to 2.6.14-rc1, still the same panic happen.
> 2.6.13.2 and before, the kernel has bee
Hi:
The kaweth driver kills the URBs in kaweth_disconnect() as well as
kaweth_close(). The former is unnecessary because as part of the
netdev deregistration dev_close() will be called if the interface
is up which ends up calling kaweth_close().
If the interface isn't up then no URBs should be a
On Monday August 1, [EMAIL PROTECTED] wrote:
> I'll double check what happens under windows, look through the trace
> data I'm collecting, and get back to you.
So... three months later.
I lost interest in this problem because I plugged the printer into an
old notebook and it seemed to work alm
Hi:
The kaweth driver does not delete the TX URB in kaweth_close().
As a result the TX URB may still be active in the USB subsystem.
If kaweth_open() is called quickly afterwards, the networking
layer could submit another packet before the existing TX URB has
completed.
This will cause kaweth_sta
> Right it works fine with the 2.6.14 Vanilla kernel.
>
> Thanks for the help, but do you know why it does not work proper with
> lesser versions.
No, but maybe "diff" will help you figure that out.
- Dave
---
SF.Net email is sponsored by:
T
On Mon, Nov 07, 2005 at 02:28:40PM -0800, Greg KH wrote:
> On Mon, Nov 07, 2005 at 05:26:10PM -0500, Alan Stern wrote:
> > On Mon, 7 Nov 2005, Greg KH wrote:
> >
> > > On Mon, Nov 07, 2005 at 10:10:28PM +0100, Adrian Bunk wrote:
> > > > On Sun, Nov 06, 2005 at 06:24:47PM -0800, Andrew Morton wrote
On Saturday 05 November 2005 17:47, Christian Iversen wrote:
Does nobody have a single idea what's wrong here?
> I'm having an El Cheapo usb keyboard+mouse usb device, and an Logitech
> MX700 usb mouse connected to a computer.
>
> Bus 003 Device 001: ID :
> Bus 002 Device 001: ID :00
Guys, I had to fix a clash between recent changes in this file and Alan's
rework of the tty buffering scheme. I'm not 100% confident in the result.
It would be appreciated if someone could pass an eye over
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14/2.6.14-mm1/broken-out
This does the honors for isp116x ... I see you've
got some cleanups to that driver in the queue,
I hope they don't clash with this simple patch!
- DaveThis makes the ISP116x HCD use the driver model wakeup flags for its
controller, not the flags in the HCD glue (which will be removed).
Signed-off
This just makes UHCI stop using the HCD glue
wakeup flags.
- DaveThis makes UHCI stop using the HCD glue wakeup flags to report whether
the controller can wake the system. The existing code was wrong anyway;
having a PCI PM capability doesn't imply it reports PME# is supported.
I skimmed Intel's
On Mon, 7 Nov 2005 22:10:28 +0100, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 06, 2005 at 06:24:47PM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.14-rc5-mm1:
> >...
> > +gregkh-usb-usb-libusual.patch
> >
> > USB tree updates
> >...
>
> IMHO, CONFIG_USB_LIBUSUAL shouldn't be
This makes the SL811 HCD use the driver model
wakeup flags.
- Dave
p.s. I'm not sending the OHCI or usbcore patches
quite yet ... need to test the OHCI stuff,
there's some non-obvious stuff there due to
the amd756 bug workarounds.This makes the SL811 HCD use the driver model wakeup flags
This is the first of several patches making HCDs
and usbcore stop using hcd wakeup flag, in favor
of using the new driver model ones.
- DaveThis teaches the EHCI driver to use the new driver model wakeup flags,
replacing the similar ones in the HCD glue. It also adds a workaround
for the current
This provides a better fix for the reinit bug
that shows up during resume ... one that cleans
up some ugly stuff, and also doesn't (for me!)
break init paths. That reinit bug came with
Matt's re-factoring of the PCI stuff into a
separate file; my initial fix didn't quite
solve the problem in some
This replaces a patch that got dropped; it's
basically whitespace cleanup requested by
Andrew. Again, please merge for 2.6.15.
- Dave
p.s. I'm hoping these patches don't get mangled.
This cleans up the recent updates to EHCI PCI support:
- Gets rid of checks for "is this a PCI device", they'r
Greg, please use the attached patch to replace
the usb-pm-09.patch currently in your tree.
It's basically the same patch, but without
moving the spinlock init. So it doesn't fix
the reinitialization bug that shows up in PM
resume, but likewise it shouldn't have the init
problem seen on some syste
matthieu castet wrote:
Hi,
here the corrected version of ueagle-atm.
The comments of Adrew Morton and Greg KH have been applied.
We also fix a bug in the check_dsp routine (reported on our mailling
list) and kill some unsued code.
Signed-off-by: Matthieu CASTET <[EMAIL PROTECTED]>
Could y
On Mon, Nov 07, 2005 at 05:26:10PM -0500, Alan Stern wrote:
> On Mon, 7 Nov 2005, Greg KH wrote:
>
> > On Mon, Nov 07, 2005 at 10:10:28PM +0100, Adrian Bunk wrote:
> > > On Sun, Nov 06, 2005 at 06:24:47PM -0800, Andrew Morton wrote:
> > > >...
> > > > Changes since 2.6.14-rc5-mm1:
> > > >...
> > >
Hi,
here the corrected version of ueagle-atm.
The comments of Adrew Morton and Greg KH have been applied.
We also fix a bug in the check_dsp routine (reported on our mailling
list) and kill some unsued code.
Signed-off-by: Matthieu CASTET <[EMAIL PROTECTED]>
diff -ruN -x '*.o*' -x '*.mod*' -
On Mon, 7 Nov 2005, Greg KH wrote:
> On Mon, Nov 07, 2005 at 10:10:28PM +0100, Adrian Bunk wrote:
> > On Sun, Nov 06, 2005 at 06:24:47PM -0800, Andrew Morton wrote:
> > >...
> > > Changes since 2.6.14-rc5-mm1:
> > >...
> > > +gregkh-usb-usb-libusual.patch
> > >
> > > USB tree updates
> > >...
>
On Mon, Nov 07, 2005 at 10:10:28PM +0100, Adrian Bunk wrote:
> On Sun, Nov 06, 2005 at 06:24:47PM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.14-rc5-mm1:
> >...
> > +gregkh-usb-usb-libusual.patch
> >
> > USB tree updates
> >...
>
> IMHO, CONFIG_USB_LIBUSUAL shouldn't be a user-visib
>Odd, I never got such messages. I suspect that if you enable DEBUG for
>that driver you'll notice that request_mem_region() failed, so you
should
>find out why it did that ... was some other driver grabbing BAR 0 on
that
>PCI device?
>Does it happen on 2.6.14?
David,
Right it works fine with
On Sun, Nov 06, 2005 at 06:24:47PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.14-rc5-mm1:
>...
> +gregkh-usb-usb-libusual.patch
>
> USB tree updates
>...
IMHO, CONFIG_USB_LIBUSUAL shouldn't be a user-visible variable but
should be automatically enabled when it makes sense.
cu
Adrian
Hi Greg,
Greg KH wrote:
Thanks, but does userspace will retry if it fails the first time ?
The device needs the firmware quickly and after 3-5 seconds without it,
it goes berserk.
That sounds like a pretty broken device :)
If it was only that (don't work in bulk mode with down rate > 3Mbps
On Wed, Nov 02, 2005 at 09:15:58PM +0100, matthieu castet wrote:
> Hi Greg,
>
> thanks for your review.
>
> Greg KH wrote:
> >On Sun, Oct 30, 2005 at 12:37:41AM +0200, matthieu castet wrote:
> >
> >>Please comment and consider for inclusion.
> >
> >
> >I need a "Signed-off-by:" line in order to b
On Sun, Nov 06, 2005 at 07:44:10PM +0100, matthieu castet wrote:
> - For the license stuff, all the dual bsd/gpl drivers I saw in the
> kernel tree have the complete bsd header.
That's fine.
> - For the header file I prefer a separate header file, but if Linux
> policy is to merge header and so
On Wed, Nov 02, 2005 at 10:18:13PM +0100, matthieu castet wrote:
> matthieu castet wrote:
> >Hi Greg,
> >>>+/*
> >>>+ * sometime hotplug don't have time to give the firmware the
> >>>+ * first time, retry it.
> >>>+ */
> >>>+static int sleepy_request_firmware(const struct firmware **fw,
> >>>+
Yes, i did, so what does that mean to me? Is it usable for me or not? Have i
to use libhid?
-Günther
Am Montag, 7. November 2005 15:06 schrieben Sie:
> Hi Gunther,
> Have you looked at javax.usb? (http://javax-usb.org/) That is a
> java JSR designed to allow java apps to talk directly to USB
Hi Gunther,
Have you looked at javax.usb? (http://javax-usb.org/) That is a
java JSR designed to allow java apps to talk directly to USB devices.
-Jeff
On 11/7/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hey, it's me again...
> I would like to use my HID device in Java and not C. I tes
Hey, it's me again...
I would like to use my HID device in Java and not C. I tested my device with
the test_libhid.c and it worked (I could send data to it). Now I want to use
it for java...is it possible to use libhid in java, or does exist a
test_libhid.java???
greetings!
--
Günther Obrist
33 matches
Mail list logo
