> -Original Message-
> From: Alan Stern [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 08, 2004 22:10
> To: Mark Richards
> Cc: [EMAIL PROTECTED]
> Subject: Re: [linux-usb-devel] USB compile errors
>
>
> On Thu, 8 Jan 2004, Mark Richards wrote:
>
> > Hello everyone.
> >
> > I a
> > -Original Message-
> > From: Alan Stern [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, January 08, 2004 22:10
> > To: Mark Richards
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [linux-usb-devel] USB compile errors
> >
> >
> > On Thu, 8 Jan 2004, Mark Richards wrote:
> >
> > > Hello ever
On Thu, 8 Jan 2004, David Brownell wrote:
> Oliver Neukum wrote:
> >
> > Yes, that is true. But, maybe I am dense, but why can't this be done
> > by making state atomic or protect it by a spinlock?
>
> Not dense ... but you do seem to have overlooked the (earlier) part
> of that note which said:
On Thu, 8 Jan 2004, Mark Richards wrote:
> Hello everyone.
>
> I am compiling a custom kernel using mandrake's build 2.4.22-21. I've had
> some success with it so far, but am trying to get a good compile/link.
>
> I hit a snag today in the usb section and am not certain who to contact
> about i
> Hello!
>
> When I develop the usb to serial device driver under linux, I get a
> problem about the probe function.
>
> My chip is TUSB3410 ( TI ), and the endpoint number of bootloader is one.
>
> During startup routine, I download firmware and confirm the firmware
> running.
>
> I think wh
Martin MOKREJ© wrote:
Hi,
I found this patch causes troubles on 2.4.25-pre4 and also 2.4.24-rc2.
Here is the resolved stack trace in "cr.res" file. :(
Some details. The usb0 had assigned an IP address and was up(not sure if
that matters). In "dmesg" I saw several times:
usb0: rxqlen 0 --> 1
NETDEV
Oliver Neukum wrote:
I'd describe it a bit differently: it ensures that the first phase of
disconnection (preventing new URB submissions) completes, for any/all
devices, before anything needs to block for the second or third phases
(which can take an arbitrarily long time because they need dev->se
This patch fixes the non-READ/WRITE paths of the jumpshot driver to be
compatible with s-g requests. In the process, it also simplifies the
logic.
Greg, please apply.
Matt
- Forwarded message from Alan Stern <[EMAIL PROTECTED]> -
Date: Tue, 9 Dec 2003 12:10:26 -0500 (EST)
From: Alan St
Duncan Sands wrote:
Thanks a lot. This is extremely problematic then: in usb_set_configuration,
an interface's device structure will not be completely initialized until we do
device_add (&intf->dev);
...
What to do?
Hmm, good catch! Looks to me like usb_driver_claim_interface() will
need
This patch fixes up the non-READ/WRITE paths in the Datafab driver to be
fully compliant with the requirments of s-g. The logic got a lot clearer
in the process.
Greg, please apply.
Matt
- Forwarded message from Alan Stern <[EMAIL PROTECTED]> -
Date: Tue, 9 Dec 2003 12:09:33 -0500 (EST
> Well, the device's kobject's name is set in
> drivers/base/core.c:device_add() by this line of code:
>
> kobject_set_name(&dev->kobj,dev->bus_id);
>
> device_add(), in turn, is called by usb_set_configuration (or maybe in
> your version of the code it's device_register(), which calls
> devi
Hello everyone.
I am compiling a custom kernel using mandrake's build 2.4.22-21. I've had
some success with it so far, but am trying to get a good compile/link.
I hit a snag today in the usb section and am not certain who to contact
about it. I'm new to linux (win32 for years, tho). I checked
This patch cleans up quite a few code paths by optimizing for the
scatter-gather case. Experiments reveal that a mount/read/write/umount
cycle will use thousands of s-g requests and less than 10 non-sg requests,
so this is a legitimate trade off for performance.
Greg, please apply.
As noted, thi
Hi Vojtech, hi list,
could someone tell me why hid accepts devices with usage page 0xc as input
devices in this check from hid.h:
#define IS_INPUT_APPLICATION(a) (((a >= 0x0001) && (a <= 0x00010008)) || (a ==
0x00010080) || ( a == 0x000c0001))
TIA
Oliver
--
Hi,
I found this patch causes troubles on 2.4.25-pre4 and also 2.4.24-rc2.
Here is the resolved stack trace in "cr.res" file. :(
Some details. The usb0 had assigned an IP address and was up(not sure if
that matters). In "dmesg" I saw several times:
usb0: rxqlen 0 --> 1
NETDEV WATCHDOG: usb0: trans
> > see, is that it would let drivers know ASAP when a device had been
> > disconnected and it would tell the core to stop accepting URBs for that
> > device. Is that sufficient justification?
>
> I'd describe it a bit differently: it ensures that the first phase of
> disconnection (preventing
Is there any way from user space to determine which /dev/ttyUSBn file is
currently being used by a given device? I'm able to locate the correct
/proc/bus/usb/bbb/ddd file. Can it be used to determine the mapping, e.g. via
an ioctl?
--
Dave Mielke | 2213 Fox Crescent | I believe that the
Alan Stern wrote:
On Thu, 8 Jan 2004, David Brownell wrote:
Why shouldn't it be possible for the hub code to sort that stuff
directly? Logically it's just setting a flag. Maybe dev->state
should be protected by some lock, but certainly it's easy to have
a bit that can record the disconnect even
On Thu, 8 Jan 2004, Duncan Sands wrote:
> Any idea where the usb interface's device's kobject's name is setup?
> I'm talking about kobject_name(&intf->dev->kobj).
Well, the device's kobject's name is set in
drivers/base/core.c:device_add() by this line of code:
kobject_set_name(&dev->ko
Nolan Orwan wrote:
On advice from Thomas Schorpp on the usb-users list, I reinstalled the
USB 2.0 card from the last PCI slot to the first one. After that,
everything worked fine.
That'd seem to suggest some sort of hardware or IRQ routing problem,
nothing related to USB (except that it's the h
Duncan Sands wrote:
That'd work too ... but it assumes that long term we'd want
to keep both versions. Do we really need to do that?
Well, for me the point was to have __usb_set_configuration
declared in usb.h, so devio can use it.
I don't think that function should be generally available;
why n
On Thu, 8 Jan 2004, David Brownell wrote:
> >>Why shouldn't it be possible for the hub code to sort that stuff
> >>directly? Logically it's just setting a flag. Maybe dev->state
> >>should be protected by some lock, but certainly it's easy to have
> >>a bit that can record the disconnect even if
Any idea where the usb interface's device's kobject's name is setup?
I'm talking about kobject_name(&intf->dev->kobj).
Thanks,
Duncan.
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Manage
> That'd work too ... but it assumes that long term we'd want
> to keep both versions. Do we really need to do that?
Well, for me the point was to have __usb_set_configuration
declared in usb.h, so devio can use it.
Duncan.
---
This SF.net em
I added a USB 2.0 interface card (ADS Technologies USB Turbo 2.0) to my
AMD Athlon box running Red Hat 9 and its stock 2.4.20-8 kernel. I also
thought it would be nice to have an external USB 2.0 hard drive for
backups and what have you and purchased some gear for that purpose as
well (ADS Tec
On Thu, 8 Jan 2004, David Brownell wrote:
> That'd work too ... but it assumes that long term we'd want
> to keep both versions. Do we really need to do that?
>
> Seems to me there's no reason any device driver should use
> either one of those calls. (They have usb_reset_config for
> the typica
Duncan Sands wrote:
How about this one instead?
Introduce unlocked version of usb_set_configuration: __usb_set_configuration.
That'd work too ... but it assumes that long term we'd want
to keep both versions. Do we really need to do that?
Seems to me there's no reason any device driver should u
Eric Lussard wrote:
Applied the diagnostic patch to 2.6.1-rc1 _without_ the recommended
workaround from Alan. Is the attached log what you expected to see?
Yes, see below. Exactly the sort of failure seen before;
looks like a problem in the device.
It'd be good if someone who can reproduce this wo
How about this one instead?
Introduce unlocked version of usb_set_configuration: __usb_set_configuration.
drivers/usb/core/message.c | 40 -
include/linux/usb.h| 48 -
2 files changed, 48 insertions(+)
> It's still not right though ... the "registering..."
> messages are all emitted before the first registration
> gets done by device_add. That would definitely be
> noticed ... the probe() messages will seem to appear
> out of sequence!
OK - I will fix that. By the way, the Oops this change
fix
Alan Stern wrote:
I'm recombining the different parts of this thread, since things seem to
be winding down.
On Wed, 7 Jan 2004, David Brownell wrote:
Why shouldn't it be possible for the hub code to sort that stuff
directly? Logically it's just setting a flag. Maybe dev->state
should be prote
Duncan Sands wrote:
Hi Dave, I had another look at this bit:
Also I'd revert the change to create the driverfs interface files
after all the probes succeed;
my patch doesn't create the driverfs interface files after all probes
succeeds, it creates each one after the associated probe has succeed
> I'll give this a whirl; drivers/usb/class/{audio,cdc-acm}.c also
> need changes, but this is a good start.
Yes, I forgot about them.
Ciao,
Duncan.
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Confi
Am Donnerstag, 8. Januar 2004 16:47 schrieb Alan Stern:
> I'm recombining the different parts of this thread, since things seem to
> be winding down.
>
>
> On Wed, 7 Jan 2004, David Brownell wrote:
>
> > Why shouldn't it be possible for the hub code to sort that stuff
> > directly? Logically i
I'm recombining the different parts of this thread, since things seem to
be winding down.
On Wed, 7 Jan 2004, David Brownell wrote:
> Why shouldn't it be possible for the hub code to sort that stuff
> directly? Logically it's just setting a flag. Maybe dev->state
> should be protected by some
Hi,
Here is a patch against 2.6.1-rc1 for hid force feedback devices.
hid-core.c:
- Use INT out urbs instead of bulk out urbs. That's the way it should be.
hid-ff.c:
- Email address update.
- Added ids of Logitech MOMO force wheel.
hid-lgff.c:
- Fixes an obvious list handling issue.
- The first v
Applied, thanks.
Petko
On Wed, 7 Jan 2004, Csillag Kristof wrote:
> [PATCH] USB: pegasus driver update
>
> [Please CC to me, I'm not subscribed to linux-usb-devel]
>
> Hi there!
>
> After some research (actually, from studying the INF files which I
> extracted from the downloa
Alan Stern wrote:
On Wed, 7 Jan 2004, Stavros Markou wrote:
Hi,
Thanks for your quick and accurate answer. It worked !!!
Are you gonna include this change to the upcoming 2.6.1 kernel ?
I am going to include it, along with other changes to
__usb_reset_device(), but I don't know if it wil
38 matches
Mail list logo
