On Wed, Jan 15, 2003 at 01:54:22AM +, oliverthered wrote:
>
>
> On Wed, 2003-01-15 at 01:33, Greg KH wrote:
> > On Tue, Jan 14, 2003 at 11:58:04PM +, oliverthered wrote:
> > >
> > > Any comments?
> >
> > Your patch is line wrapped, mind fixing your mailer and trying again?
> see attache
On Tue, Jan 14, 2003 at 05:51:31PM -0800, David Brownell wrote:
> Kari Hameenaho wrote:
>
> >This seems to have started in 2.5.57, finding the devices at boot used to
> >work in 2.5.56.
>
> I was wonder if the probing logic (driver core) got something
> wrong ... I just saw a situation where mod
Hi
I working also with a SL811HS on a embeded system (based on MPC860)
I've add the isochronous mode but there is the hard limit of 240bytes
for packets. If we use two channels then there 240/2 then 120 bytes
for isochron. Then I haven't managed second channel.
Sylvain
[EMAIL PROTECTED] wrote:
>
On Mon, Jan 13, 2003 at 02:06:26PM -0500, warlock wrote:
>
> So could somebody perhaps confirm or deny that this is a problem?
Yes, it is a problem, and should be fixed. I thought we had gotten all
of the hub.c fixes :(
> Since if it is, it's a fairly widespread one.
Well, hopefully not that w
At 20:24 14/01/2003 -0500, [EMAIL PROTECTED] wrote:
I don't think it would be appropriate for usb-uhci nor uhci to re-try in
-ENXIO cases, but your driver could do that. However retrying doesn't
really solve the problem.
I think I can backport the control queueing into the 2.4 uhci driver;
I'm
thanks but why 6MIPS and 48MIPS how are those number derived?
i assumed for 12Mbps full speed??? that is about 1.5MByteps how
does it need 48Mips???
thanks if you can elaborate how you come up with those number??? thanks
Michael Hetherington wrote:
>
> You do not have to keep
>
> thanks but why 6MIPS and 48MIPS how are those number derived?
>
> i assumed for 12Mbps full speed??? that is about 1.5MByteps how
> does it need 48Mips???
>
> thanks if you can elaborate how you come up with those number??? thanks
>
>
http://www.sxlist.com/techref/ubicom/lib/io/d
On Wed, 2003-01-15 at 08:58, Greg KH wrote:
> On Wed, Jan 15, 2003 at 01:54:22AM +, oliverthered wrote:
> >
> >
> > On Wed, 2003-01-15 at 01:33, Greg KH wrote:
> > > On Tue, Jan 14, 2003 at 11:58:04PM +, oliverthered wrote:
> > > >
> > > > Any comments?
> > >
> > > Your patch is line wr
speedtouch: make more functions static.
speedtouch.c | 39 +++
1 files changed, 19 insertions(+), 20 deletions(-)
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/usb/misc/speedtouch.c Wed Jan 15 16:16:20 2003
+
speedtouch: use SpeedTouch everywhere (was sometimes Speed Touch).
speedtouch.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/usb/misc/speedtouch.c Wed Jan 15 16:24:53 2003
+++ b/drive
On the face of it, this looks like it might be a problem in ext3 or the
memory management code.
On Wed, 15 Jan 2003, Stephen Harker wrote:
> OK here is a newly generated oops and ksymoops output on kernel
> 2.4.21-pre3-ac1.
>
> This is created by simply copying a large file from the USB hard-d
I agree with Oliver on this. Although the existing API provides enough
mechanism for drivers to make sure that all their urbs are unlinked and
all completion handlers are through, it's not easy to do correctly. Since
practically every driver has to deal with this problem during unloading,
the fun
On Wed, 15 Jan 2003, oliverthered wrote:
>Changes to usb_epnum_to_ep and usb_epnum_to_ep will break drivers that
>require an alt_setting other than 0 but fail to call setinterface.
drivers that attempt to use inactive alternate settings are broken; so
hopefully there aren't any.
--
Dan Stree
speedtouch: kill receive queue tasklet on shutdown (race pointed
out by Oliver Neukum).
speedtouch.c |2 ++
1 files changed, 2 insertions(+)
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/usb/misc/speedtouch.c Wed Jan 15 16:15:14 2003
+++ b/
As far as performance goes, there are two things you have to consider:
1) The SL811HS is a bit-banger. The driver receives an USB transfer Done
interrupt on each USB transaction. In each USB Frame, there can be multiple
USB transactions. I remember that in a USB mass storage device, there can
Hi,
The current version of SL811HS driver does not support the B channel.
Pei
-Original Message-
From: Sylvain Meunier <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
<[EMAIL PROTECTED]>
Date: Wednesday, January 15, 2003 2:19 AM
Subject: [linux-usb-devel] Re: SL811 driver
>Hi
>I working als
thanks... i recognize the name as the author of the SL811 cypress
driver
if you are the author... may i ask whether it utilizes the A/B feature
of the chip? from looking at it.. it does not seem to do so
Pei Liu wrote:
>
> As far as performance goes, there are two things you have to consid
+ if(!(ep_desc = usb_epnum_to_ep_desc(ps->dev, uurb.endpoint)))
+ return -ENOENT;
+ interval = ep_desc->bInterval;
+
Shouldn't it be "interval = 1 << (ep_desc->bInterval -1);" instead?
For iso, bInterval is always a log2 encoding.
---
Greg KH wrote:
I was wonder if the probing logic (driver core) got something
wrong ... I just saw a situation where modprobing the driver
wouldn't make it bind to devices that were already present.
It had to be the other way around: driver first, then device.
Yes, something changed there. He
On Wed, 2003-01-15 at 17:42, David Brownell wrote:
> > + if(!(ep_desc = usb_epnum_to_ep_desc(ps->dev, uurb.endpoint)))
> > + return -ENOENT;
> > + interval = ep_desc->bInterval;
> > +
>
> Shouldn't it be "interval = 1 << (ep_desc->bInterval -1);" in
Am Mittwoch, 15. Januar 2003 17:04 schrieb Alan Stern:
> I agree with Oliver on this. Although the existing API provides enough
> mechanism for drivers to make sure that all their urbs are unlinked and
> all completion handlers are through, it's not easy to do correctly. Since
> practically every
oliverthered wrote:
On Wed, 2003-01-15 at 17:42, David Brownell wrote:
+ if(!(ep_desc = usb_epnum_to_ep_desc(ps->dev, uurb.endpoint)))
+ return -ENOENT;
+ interval = ep_desc->bInterval;
+
Shouldn't it be "interval = 1 << (ep_desc->bInterval -1);" instead?
For iso, bInterval is always a l
On Wed, 2003-01-15 at 19:38, David Brownell wrote:
> oliverthered wrote:
> > On Wed, 2003-01-15 at 17:42, David Brownell wrote:
> >
> >>>+ if(!(ep_desc = usb_epnum_to_ep_desc(ps->dev, uurb.endpoint)))
> >>>+ return -ENOENT;
> >>>+ interval = ep_desc->bInterval;
>
On Wed, 2003-01-15 at 19:38, David Brownell wrote:
> oliverthered wrote:
> > On Wed, 2003-01-15 at 17:42, David Brownell wrote:
> >
> >>>+ if(!(ep_desc = usb_epnum_to_ep_desc(ps->dev, uurb.endpoint)))
> >>>+ return -ENOENT;
> >>>+ interval = ep_desc->bInterval;
>
On Wed, 15 Jan 2003, David Brownell wrote:
>oliverthered wrote:
>> On Wed, 2003-01-15 at 17:42, David Brownell wrote:
>>
+ if(!(ep_desc = usb_epnum_to_ep_desc(ps->dev, uurb.endpoint)))
+ return -ENOENT;
+ interval = ep_desc->bInterval;
+
On Wed, 15 Jan 2003, oliverthered wrote:
>Oh what fun..
yes, hurray for the usb spec writers... ;-)
>I'll make a patch to fit the specification.
let's agree on where to put it first; if it goes into the core (either
generic hcd, or uhci/ohci/ehci) then the conversion only has to be done
On Wed, 2003-01-15 at 20:38, Dan Streetman wrote:
> On Wed, 15 Jan 2003, oliverthered wrote:
>
> >Oh what fun..
>
> yes, hurray for the usb spec writers... ;-)
>
> >I'll make a patch to fit the specification.
>
> let's agree on where to put it first; if it goes into the core (either
> gene
On Wed, 15 Jan 2003, Oliver Neukum wrote:
> Am Mittwoch, 15. Januar 2003 17:04 schrieb Alan Stern:
> > resubmitted urbs. Second (and more subtle), there are differences between
> > resubmitting an urb from the handler as opposed to submitting it again
> > after the handler is done. For example,
On Mon, Jan 13, 2003 at 11:00:08AM +0100, Henning Meier-Geinitz wrote:
>
> With this patch, information about user-supplied ids is printed only
> once at startup instead of everytime any USB device is plugged in.
>
> The patch is on top of the new ids patch.
Applied, thanks.
greg k-h
On Mon, Jan 13, 2003 at 10:58:02AM +0100, Henning Meier-Geinitz wrote:
>
> This patch adds vendor/product ids for two Visioneer scanners.
Applied, thanks.
greg k-h
---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate
is e
On Mon, Jan 13, 2003 at 11:04:18AM +0100, Henning Meier-Geinitz wrote:
>
> This patch makes endpoint detection more generic. Basically, only one
> bulk-in endpoint is required, everything else is optional.
>
> The patch is on top of the PV8630 removal patch.
Applied, thanks.
greg k-h
On Mon, Jan 13, 2003 at 11:02:14AM +0100, Henning Meier-Geinitz wrote:
>
> This patch removes the inofficial ioctls that were used to support the
> PV8630 USB-over-Parport chipset. They were already ifdefed out.
> Instead of them, the more generic (and official) SCANNER_IOCTL_CTRLMSG
> should be u
Alan Stern wrote:
This is where my lack of knowledge of the details underlying the usb core
shows through. Okay, looking at hcd.c I see where urb_unlink() is called
and how it releases the bandwidth. I'm surprised; is it really supposed
to work this way?
At this point, only "uhci-hcd" relies
Hmm, so should the conversion from bInterval to ms-interval happen in the
driver, or in the core? It seems to me that it would be better to handle
that conversion in the core...?
We had that discussion last summer, and the resolution
was that fill_int_urb() does it ... ISO drivers don't
have
On Wed, Jan 15, 2003 at 04:26:13PM +0100, Duncan Sands wrote:
> speedtouch: make more functions static.
Applied, thanks.
greg k-h
---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate
is essential in establishing user co
On Wed, Jan 15, 2003 at 04:20:21PM +0100, Duncan Sands wrote:
> speedtouch: kill receive queue tasklet on shutdown (race pointed
> out by Oliver Neukum).
Applied, thanks.
greg k-h
---
This SF.NET email is sponsored by: A Thawte Code Signi
On Wed, Jan 15, 2003 at 04:28:40PM +0100, Duncan Sands wrote:
> speedtouch: use SpeedTouch everywhere (was sometimes Speed Touch).
Applied, thanks.
greg k-h
---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate
is essent
Hello Oliver,
On Wednesday 15 January 2003 00:46, Oliver Neukum wrote:
[stop resubmitting in the completion function]
> Not good. If the drivers need to implement additional logic, then the
> existing API is insufficient. The point is not that the job can be done
> with the API. It's undoubtedly
Hello David,
On Wednesday 15 January 2003 00:12, David Brownell wrote:
> > Good. Now eliminate the unsuccessfull synchronous unlinks. Nobody wants
> > them. What should a device driver do if there is an error in
> > usb_unlink_urb()?
>
> Getting back to one of my first responses on this thread.
Am Mittwoch, 15. Januar 2003 21:54 schrieb Alan Stern:
> On Wed, 15 Jan 2003, Oliver Neukum wrote:
> > Am Mittwoch, 15. Januar 2003 17:04 schrieb Alan Stern:
> > > resubmitted urbs. Second (and more subtle), there are differences
> > > between resubmitting an urb from the handler as opposed to sub
On Wed, 15 Jan 2003 01:03:46 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 14, 2003 at 05:51:31PM -0800, David Brownell wrote:
> > Kari Hameenaho wrote:
> >
> > >This seems to have started in 2.5.57, finding the devices at boot used to
> > >work in 2.5.56.
> >
> > I was wonder if the p
On Wed, 15 Jan 2003, David Brownell wrote:
>
>> Hmm, so should the conversion from bInterval to ms-interval happen in the
>> driver, or in the core? It seems to me that it would be better to handle
>> that conversion in the core...?
>
>We had that discussion last summer, and the resolution
>was
> Now that I know that giveback_urb cannot be called reentrantly, I see
> there's no need to worry about double locking. That routine is
> the only place that needs to acquire handler_lock while there is a
> possibility of holding another spinlock, so the issue doesn't arise.
>
> If you feel that
Original Message
Subject: Re: [linux-usb-devel] Lacie USB2.0 Hard disk bug report
Date: Thu, 16 Jan 2003 11:13:52 +1300
From: Stephen Harker <[EMAIL PROTECTED]>
To: Alan Stern <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Alan Stern wrote:
> On the face of it, this looks
> But I have a problem with usb_unlink_urb() and resubmitting, as you
> suggests.
>
> First of all, usb_unlink_urb() comes in two flavours, asynchronous and
> synchronous. If I use asychronous unlink, it may well be the aim of the
> device driver writer to do a resubmit in the completion function
Alan Stern wrote:
On the face of it, this looks like it might be a problem in ext3 or the
memory management code.
On Wed, 15 Jan 2003, Stephen Harker wrote:
OK here is a newly generated oops and ksymoops output on kernel
2.4.21-pre3-ac1.
This is created by simply copying a large file from th
ChangeSet 1.942, 2003/01/15 14:50:56-08:00, [EMAIL PROTECTED]
USB: added .owner for USB drivers that have a struct tty_driver
diff -Nru a/drivers/usb/class/bluetty.c b/drivers/usb/class/bluetty.c
--- a/drivers/usb/class/bluetty.c Wed Jan 15 14:57:45 2003
+++ b/drivers/usb/class/bluetty.c
ChangeSet 1.879.84.6, 2003/01/15 13:23:22-08:00, [EMAIL PROTECTED]
[PATCH] USB: make more speedtouch functions static
speedtouch: make more functions static.
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/usb/misc/speedtouch.c Wed Jan 15 14:58:21 2
ChangeSet 1.879.84.5, 2003/01/15 13:22:47-08:00, [EMAIL PROTECTED]
[PATCH] USB: kill speedtouch tasklet when shutdown
speedtouch: kill receive queue tasklet on shutdown (race pointed
out by Oliver Neukum).
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers
ChangeSet 1.879.84.7, 2003/01/15 13:23:54-08:00, [EMAIL PROTECTED]
[PATCH] USB: SpeedTouch not Speed Touch
speedtouch: use SpeedTouch everywhere (was sometimes Speed Touch).
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/usb/misc/speedtouch.c Wed J
ChangeSet 1.879.76.1, 2003/01/13 17:25:34-08:00, [EMAIL PROTECTED]
[PATCH] USB storage sysfs fix
It looks like there is a missing scsi_set_device() call in scsiglue.c,
(similiar to what happens if we handled NULL dev pointer in scis_add_host)
so all the usb scsi devices end up under /sysfs/device
ChangeSet 1.879.84.4, 2003/01/15 13:22:21-08:00, [EMAIL PROTECTED]
[PATCH] maintain hcd_dev queue in FIFO order
Current uses of the urb_list have all been to make
sure we have some list of pending urbs, so we can
clean them all up after HCs die, and avoid trying
to unlink something that's not act
ChangeSet 1.879.76.2, 2003/01/13 17:31:46-08:00, [EMAIL PROTECTED]
[PATCH] USB: put the usb storage's SCSI device in the proper place in sysfs.
Also makes usb_ifnum_to_if() a public function
diff -Nru a/drivers/usb/core/hcd.h b/drivers/usb/core/hcd.h
--- a/drivers/usb/core/hcd.hWed Jan 15 1
ChangeSet 1.879.84.3, 2003/01/15 12:48:26-08:00, [EMAIL PROTECTED]
[PATCH] Change maintainership of USB scanner driver
diff -Nru a/MAINTAINERS b/MAINTAINERS
--- a/MAINTAINERS Wed Jan 15 14:59:16 2003
+++ b/MAINTAINERS Wed Jan 15 14:59:16 2003
@@ -1901,11 +1901,11 @@
S: Maintaine
ChangeSet 1.879.84.2, 2003/01/14 17:49:55-08:00, [EMAIL PROTECTED]
[PATCH] USB: add dev attribute for usb-serial devices in sysfs
diff -Nru a/drivers/usb/serial/bus.c b/drivers/usb/serial/bus.c
--- a/drivers/usb/serial/bus.c Wed Jan 15 14:59:34 2003
+++ b/drivers/usb/serial/bus.c Wed Jan 15 14
Hi,
I'd like to propose a small further patch.
I want to bind URBs to usb_devices at allocation.
usb_alloc_urb (int i, int mem_flags) ->
usb_alloc_urb (struct usb_device *dev, int i, int mem_flags)
and usb_fill_* loose the struct usb_device references.
Explanation:
The HCDs allocate and dealloc
> >>Trace; c013f258
> >>Trace; c0133a67
> >>Trace; c0133c95
> >>Trace; c0133d03
> >>Trace; c0134c10
> >>Trace; c0134e89 <__alloc_pages+d9/170>
> >>Trace; c012fcde
> >>Trace; d080ec81 <[jbd].text.lock.journal+5ea5/14284>
> >>Trace; c013b314
> >>Trace; c0108f03
> >
> > If you suspect the pro
On Thu, Jan 16, 2003 at 12:34:36AM +0100, Oliver Neukum wrote:
> Hi,
>
> I'd like to propose a small further patch.
>
> I want to bind URBs to usb_devices at allocation.
> usb_alloc_urb (int i, int mem_flags) ->
> usb_alloc_urb (struct usb_device *dev, int i, int mem_flags)
> and usb_fill_* loos
On Thu, Jan 16, 2003 at 12:50:28AM +0100, Oliver Neukum wrote:
> srb->host_scribble = (unsigned char *)us;
> if (!srb)
> printk("srb NULL.\n");
Um, that check will not help anything :)
thanks,
greg k-h
---
This SF.NE
Am Donnerstag, 16. Januar 2003 01:06 schrieb Greg KH:
> On Thu, Jan 16, 2003 at 12:50:28AM +0100, Oliver Neukum wrote:
> > srb->host_scribble = (unsigned char *)us;
> > if (!srb)
> > printk("srb NULL.\n");
>
> Um, that check will not help anything :)
Oh yes, it's too late here.
Oliver Neukum wrote:
usb_alloc_urb (int i, int mem_flags) ->
usb_alloc_urb (struct usb_device *dev, int i, int mem_flags)
Explanation:
The HCDs allocate and deallocate data structures during every submission.
This change doesn't get away from that though ... there are two
classes of allocation,
Am Donnerstag, 16. Januar 2003 01:05 schrieb Greg KH:
> On Thu, Jan 16, 2003 at 12:34:36AM +0100, Oliver Neukum wrote:
> > Hi,
> >
> > I'd like to propose a small further patch.
> >
> > I want to bind URBs to usb_devices at allocation.
> > usb_alloc_urb (int i, int mem_flags) ->
> > usb_alloc_urb (
On Wednesday 15 Jan 2003 10:12 pm, Dan Streetman wrote:
> On Wed, 15 Jan 2003, David Brownell wrote:
> >> Hmm, so should the conversion from bInterval to ms-interval happen in
> >> the driver, or in the core? It seems to me that it would be better to
> >> handle that conversion in the core...?
> >
Wouldn't it make sense to have a conversion function in usb.c,
something like:
It hasn't been necessary so far, which is why I didn't bother
defining one last summer when this came up. There aren't many
ISO devices/driver; and ones using interrupt transfers can
just as easily call usb_fill_int_u
Oliver Neukum wrote:
In addition there are strategic thoughts. Doing this change allows (although
I think that it's 2.7 stuff) us to handle more of disconnect in usbcore.
We can under these condition link all URBs of a device and walk the list
if we detect a disconnect. If a driver allocates all
Am Donnerstag, 16. Januar 2003 01:30 schrieb David Brownell:
> Oliver Neukum wrote:
> > usb_alloc_urb (int i, int mem_flags) ->
> > usb_alloc_urb (struct usb_device *dev, int i, int mem_flags)
> >
> > Explanation:
> > The HCDs allocate and deallocate data structures during every submission.
>
> Thi
Am Donnerstag, 16. Januar 2003 01:43 schrieb David Brownell:
> Oliver Neukum wrote:
> > In addition there are strategic thoughts. Doing this change allows
> > (although I think that it's 2.7 stuff) us to handle more of disconnect in
> > usbcore. We can under these condition link all URBs of a devic
- 1..N TDs ... dependant on the specific buffer passed later,
except (usually) for ISO (where i == n)
What prevents you from allocating a reasonable number in the general case
and as many as you may need in the iso case?
What, and have _two_ code paths to debug/stabilize in the
hairy hard
On Thu, Jan 16, 2003 at 01:18:06AM +0100, Oliver Neukum wrote:
>
> No. Does that mean you are volunteering to get me a USB2.0 storage device?
Sign up to get one through the USB Slashdot Beanie fund, that's how I
got mine. Remember, let's not try to optimize something that hasn't
been proven to b
Am Donnerstag, 16. Januar 2003 01:52 schrieb David Brownell:
> >> - 1..N TDs ... dependant on the specific buffer passed later,
> >>except (usually) for ISO (where i == n)
> >
> > What prevents you from allocating a reasonable number in the general case
> > and as many as you may need in the i
Oliver Neukum wrote:
Am Donnerstag, 16. Januar 2003 01:52 schrieb David Brownell:
- 1..N TDs ... dependant on the specific buffer passed later,
except (usually) for ISO (where i == n)
What prevents you from allocating a reasonable number in the general case
and as many as you may need in the
Hi,
I was just looking at the TODO list and it seemed to me that a list somewhat
more specific and focused on usbcore might be useful.
So here's the list of things related to the core I remember so we can look
at the issues and see which need attention before 2.6.0
- reseting during probe will d
Please pull from: bk://linuxusb.bkbits.net/linus-2.5
thanks,
greg k-h
MAINTAINERS |6 ++---
drivers/usb/class/bluetty.c |7 --
drivers/usb/class/cdc-acm.c |4 ---
drivers/usb/core/hcd.c |2 -
drivers/usb/core/hcd.h |3 --
d
73 matches
Mail list logo
